3 ms·
What is the max lines in a single file for a developer "to get fired" at your company?
by A2017U1 8y ago
What is the max lines in a single file for a developer "to get fired" at your company?
- nprateem 8y ago573
- Zhyl 8y agoThe company has a shell script running in Cron. If it finds a source file with more than 1000 lines it deletes the author from the payroll.
- nercury 8y agoSadly this cron has fired the shell script author, and no one dares to touch it.
- fmoralesc 8y agoNo, it is written in APL for extra conciseness. When they wrote it in shell it deleted the authors from the payroll.
- GoblinSlayer 8y agoThe author is entire team.
- megous 8y agoIt's a ridiculous metric.
- Insanity 8y agoI do have to say, 2k lines for a single file is scary sounding to me. It would probably make me consider splitting it up. 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.
- twic 8y agoDepends a lot on tooling as well. If you have tools that give you effective jump-to-definition, find-usages, etc, then the file structure sort of fades away, because you jump from fragment to fragment without really worrying about what files they are in.
- Insanity 8y agoEver had the pleasure of opening a 20k+ line file in IntelliJ? (Not 2k, but 20k!). That happened one time, it wasn't a fun experience. 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!
- saberience 8y agoSmall note here: it's obviously not it's an "absolute" rule that X lines of codes = fired. But for me, it's just a major code smell when people are writing very large single files with generalized names like "server.rs" or "processor.java." 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.