What makes you say so? Can you give examples?
Poor code reuse, same bits of code copy and pasted all over instead of being refactored out into their own methods. Methods which are doing too much different crap. The single responsibility principle is broken everywhere.
Imagine trying to write unit tests for "Perform for EditPost", this method is doing far too much and would be a pain in the ass to fully test. If you're making a method called "EditPost" it should only be doing the actual post editing, not making connections, or user validation or checking for a ban. These should happen in a method which only handles connections, or a method which is called "ValidateUser" which is properly re-used.
Generally speaking, the structure as a whole isn't very readable, poor names, methods and files which are doing too much. The project wouldn't scale well with a bigger team or if it grew in terms of codebase size.
The server.rs looks like an implementation of RPC over websockets. So a refactoring might be to model the interface using something like https://grpc.io/ or any other IDL then code generate Rust server stubs and Typescript client stubs.
Cargo has a mechanism for this. https://doc.rust-lang.org/cargo/reference/build-scripts.html
The other area where there is some boiler plate is the Diesel ORM. Diesel does generate some code ie. schema.rs but you are left to write the structs that implement these as well as Form structs for passing data to Diesel.
BUT, sometimes things to just logically belong together and having one file to find them is just easier.
It's a rediculous metric to use.
I consider IJ and most jetbrains products to be top-notch but that was a crippling experience. And I can't really say I blame them :)
EDIT: I agree with you by the way* just saying that even good tools can fail when the sizes get crazy!
It tends to mean that someone isn't following the single responsibility principle and the code is harder to understand and less maintainable. Obviously these aren't hard and fast rules but are combined with many other code smells and metrics.
For example, I really really dislike long methods with generic names. Usually this means there are too many things happening in a single method. The method name, it's input and output parameters should give the reader a fairly exact idea of what's happening in the method.
So if I wrote a method with this signature: public List<bool> ProcessData(List<string> input)
If you tried to predict what this might contain in the body, you would have zero idea.
Now this method:
public List<bool> ValidateVipCodes(List<string> input)
Just seeing this signature, you could easily imagine what the body would look like without much thought at all.
Great code should be structured in such a way that someone can view the project, ONLY LOOKING at file names and method names and have a good idea about what is going on and how it might work.
I'd love to hear a justification for this idea.