Largest Code File?
-
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 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.
-
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.
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.
-
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
switchstatement. 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, 2013how many cases within the switch?
-
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 -
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.
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.
-
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'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.
-
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.
Asday wrote:
Repetition is never required.
You can say that again.
-
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.
:thumbsup:
«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
-
Asday wrote:
Repetition is never required.
You can say that again.
-
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 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 agree with the "size is arbitrary" view. My beef is that large files tend to collect multiple sets of application work. On a project with multiple developers, it becomes difficult to manage everyone pounding on the same source code. True, today's version control systems make it easier to merge, but my preference is break up the processing logically (into separate files) which aids in tracking changes through the system.
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
