The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
I was recently given a Windows form application to work on. It was done as a single form with over 24,000 lines in the code behind file. I was taught that no file should be over 1,000 lines. Maybe 2,000 if a lot of repetition was required. What do others feel about the maximum size of a single file?
Not also the single form had nested tab containers with over 600 controls on this singe form. They went as much as 5 deep. It was an abuse of the Window Forms framework in many aspects. My question is only about code file size.
So many years of programming I have forgotten more languages than I know.
I was taught that no file should be over 1,000 lines. Maybe 2,000 if a lot of repetition was required. What do others feel about the maximum size of a single file?
By who?? Anytime you put a limit on th enumber of lines, you're asking for trouble. What if the limit's 1000 lines and you need to insert 3 more lines to fix something?
The size of the code file is irrelevant. You can have a large file, well written and maintained, that works fine. You could also have a small file with 20 lines that's crap and needs to be thrown away.
From a UI perspective, it does sound too busy. From that angle, I'd consider redesigning it.
This whole thing smells of an old, legacy code app that can't/won't be refactored from some reason.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
Single responsibility principle.
A class should do a single thing, meaning it has one reason to change (or something like that).
I find that my classes are rarely larger than a few 100 lines.
I recently wrote one of about 600 lines and it felt like an absolute beast to me.
I can't really put an upper limit on lines per file, but 24,000 in a single class is WAY TOO MUCH. Period.
That's just unmanageable.
The tab containers, for example, should've been in their own files.
You look at the solution and you see OrderForm.cs, TabControl.cs, MyTextBox.cs, OrderRepository.cs, etc. and you know what kind of work you can expect.
Looking at a solution and seeing only OrderForm.cs, but with 24,000 lines tells you nothing of what is going on or where to find it.
File length may be some sort of measure that is weakly correlated to how much of a mess the code is, but if it is used a target then it loses its value as a measure.
If turning a long code file into several short ones just means introducing unnatural/forced "file breaks" (kind of like a line break but more dramatic, indeed this same principle applies to a line length limit) at random points, nothing has been gained by doing it. Cutting up a mess just results in a cut-up mess, cutting up a non-mess creates a mess.
Long files are a bit annoying to navigate, but so is "lots of files in a project".
Having closely related things spread of different files is more annoying to keep straight and navigate between and choose where to add new stuff. Having some incidental not-quite-so-closely-related things in the same file isn't really a problem but more like something that will trigger some people's compulsive need to organize.
If a form has hundreds of controls, which I'm not saying is great to have, but if it has, then it's going to have a long code-behind file automatically, just to put the event handlers and basic control-related logic there. 24k lines sounds like there's a bunch of other stuff in there too that maybe could reasonably be somewhere else, maybe. But I don't know.
I don't have any hard guidelines but I like to stay under about 20KB when possible. Sometimes it just isn't and I don't start splitting things up if I get close to that.
I feel your pain though. We have a code module here that is over 2MB long and almost 90K lines. It is full of ifdefs and several large functions have three or four implementations in it with only subtle differences. We hold this up as an example of how not to do things ever and a justification for why we are trying to rewrite everything it was involved in. It is truly horrendous.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
Very recently, a single-file that contained ... a guess we can call it a "data layer", with no less than 270 class-global OracleCommand definitions to start with, followed by almost 200 DataAdapters, 200 DataSets, a few Data Readers. With the useless comments that went with them, that's just the first 1,000 lines of this 16,000-line horror show.
...and that's just the "data layer". Even though data is all this one file handles, I really wouldn't call it a "data layer". It's more an amalgam of data, UI validation methods, and business rules.
Fortunately, you've supplied the fun by talking about a file that will just fit into a 16bit seg.
I tried to save my file one day and pow no-go. I'd also hit the 64k limit and now had to transition to some other text editor since my syntax-highlighting one could no longer chew on what I fed it. CRAP! Bloody Notepad it is then for this x86 assembly.
Thank Ghu for WPF where user controls are the norm and it is trivial to use a different UC for each tab. I have not had more than a couple of hundred lines of code (and even that seems really big) in a single file for years.
Never underestimate the power of human stupidity -
I'm old. I know stuff - JSOP
Hard limits don't quite make sense. It all depends on the circumstances. Huge methods or huge units are generally a code smell, but they may make sense. That's true for pretty much every one-liner. DRY is a great principle all right, but I've had cases where repeating myself (with some changes) was better for the code base than to pipe everything through that one function. Heck, even "goto is evil", the universal truth of structured programming can be wrong in some cases.
My verdict would be, while your case is likely badly maintained code, it may be, by a tiny off-chance, actually the way to go. And hard line limits shouldn't be relied upon in any circumstances.
I don't place a "lines limit" on files - heck, I don't count lines or use line numbers anyway - but I do modularize code as much as possible: For a complex form, that means using UserControls instead of "raw controls" to group together related items and separate concerns; using TabPages to simplify displays (and each page generally contains just a Usercontrol); that kinda thing.
That reduces the complexity of each individual system, adds reusability, and improves maintenance.
A single large form is generally a mistake: it leads to spaghetti, and to overwhelmed users - too much data in a single place makes code very hard to use.
Sent from my Amstrad PC 1640 Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
On really busy/complex forms, I make heavy use of partial classes, separating constructors, event handlers, and helper methods. On objects, I do the same thing when something complex is a viably separate concern. I try to keep line counts to less that 1000 where practical.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
Last Visit: 10-Apr-20 0:01 Last Update: 10-Apr-20 0:01