|
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
|
|
|
|
|
#realJSOP wrote: 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.
«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
|
|
|
|
|
Been there, done that, I feel your pain.
|
|
|
|
|
If I am paid per file I create, then 1 line per file.
If I am paid by size of file, everything in one file with a novel about my life in comments.
If I am paid to write a decent piece of code, then whatever makes logical sense.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
First place I worked at had a huge codebase, where files between 100k-200k lines were the rule, rather than the exception. And no, that's not a typo, I'm talking six figures line count - and with pretty much no comments that could take up space.
This was code that, before my time there, went through at least two translations from different programming languages, done by automated tools and only touched up where it broke after that.
I don't know if it was a direct consequence, but there were also a lot of constructs like
function a(x, y)
{
return b(x, y);
}
function b(x, y)
{
return c(x, y);
}
function c(x, y)
{
return d(x, y);
}
function d(x, y)
{
return mysteriousStuff;
}
which added some, but not all of the length.
There's a *lot* more there I could rant about, but I'll stick to unnecessary length. Suffice it to say, there's a reason that a) I went somewhere else and b) the company apparently doesn't exist anymore.
|
|
|
|
|
The largest file I've ever encountered was 32,000 lines. The true horror was that it was a partial class extension with nothing but ONE method that implemented a giant switch statement. Yes, a 32,000 line switch statement. 32,000 lines!
".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
|
|
|
|
|
how many cases within the switch?
|
|
|
|
|
It was years ago, and I never counted, but "hundreds" comes to mind. There were a handful with 300-500 lines.
".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
|
|
|
|
|
Same issue faced me mine win-forms cs file has 33k lines of code. It is a nightmare to work on it, anything here and there whole form breaks down.
|
|
|
|
|
I converted the government CCDA XML spec into a C# class. Over a quarter million lines of C# code with classes of classes of classes...yet I did figure it out and VS could actually handle it.
|
|
|
|
|
Arbitrary rules are arbitrary. There is no maximum file size. If "huge" it what it takes to get the job done, then huge it is--as long as everything logically goes together.
That's really what the notion of "some max file size" is trying to encapsulate--if you have huge files, it's likely that you've crossed some logical boundaries.
By breaking things into a bunch of smaller files, you have systematic complexity which needs to be managed.
There is no hard-and-fast rule. It's really around trying to define functional areas (tiers), and trying to ensure that code in each tier 'fits' there.
That being said, from your description, it sounds as if refactoring is in order to separate the concerns a bit.
For example, each tab might be represented by a control. Simplify the main form just to be a controller of each sub-control, showing/hiding the right thing(s) based on selected tab.
Then, you might want to add a data-access tier, etc, etc.
I imagine your co-workers will then complain about "how hard it is to follow", having to talk to some factory-type method to execute SQL instead of directly querying/executing. Sigh.
|
|
|
|
|
A function should never be taller than my screen (~100 lines). Other than that, there's no real need to set these arbitrary numbers. SLOC can be indicative of an issue, but it's not an issue in and of itself.
if a lot of repetition was required
Repetition is never required.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
