|
Well, she turned me into a newt[^]! 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I'm with Sander: mess with his cat, and you'll face us both.
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!
|
|
|
|
|
slow down a bit,
depends on what sort of fruit will be in the basket.
... if it's ambrosia I say turn em both into baskets.
|
|
|
|
|
No, I just haven't been coding lately so I haven't been here.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
honey the codewitch wrote: No, I just haven't been coding lately so I haven't been here.
Easy. We are usually here more when we don't code. 
|
|
|
|
|
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.
|
|
|
|
|
michaelbarb wrote: 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.
|
|
|
|
|
These were rules of thumb and not intended to be hard fast limits. More like best practice rules where there are all kinds of reasons to break them but better if you do not.
It was only written a year ago.
So many years of programming I have forgotten more languages than I know.
|
|
|
|
|
As small as possible, and no smaller.
Maybe the project began with .net v1 when partial classes weren't supported?
|
|
|
|
|
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.
|
|
|
|
|
I have several thoughts.
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.
|
|
|
|
|
|
I'd hoped to read a tale that resembled mine.
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.
|
|
|
|
|
Actually, now that I think about it, that 64k limit was for a proc/function.
This really only equated to about 1400 lines of code. Sorry for the confusion.
"Go forth into the source" - Neal Morse
|
|
|
|
|
Th combination of jumbo file size and gazillion controls suggests to me a programmer strategy called "lifetime employment insurance."
cheers, Bill
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
I vote this the best comment in the whole thread.
So many years of programming I have forgotten more languages than I know.
|
|
|
|
|
I will second michaelbarb's Motion.
A perfect comment and gets my vote for the best.
"Rock journalism is people who can't write interviewing people who can't talk for people who can't read." Frank Zappa 1980
|
|
|
|
|
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 -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
19K+ .asp file. Not .aspx, and poorly written, bad cut and paste, no comments, no documentation.
I survived.
I think it was around 200-300 lines of .aspx when I was done. A lot of cut and paste.
"Time flies like an arrow. Fruit flies like a banana."
|
|
|
|
|
I have seen legacy code with a C++ function (within a much bigger C++ code file) having about 2000 lines of code.
Surprise - the first 1999 lines of this function were commented out, and the only working statement in this function was
return true;
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
