|
I can't wait to buy them here on the left side of the pond.
ed
|
|
|
|
|
I started to dive in a new (for me) very large code base. One of the files is 9500 lines. Got me wondering: what's the largest single source file you ever met? I'm not talking about automatically generated source files, but those written by humans.
On the same note, when do you think it's time to break a file in smaller pieces? For me, it is somewhere around 1000 lines.
Mircea
|
|
|
|
|
Line count is not a default metric for me.
If all the code is concise and organized well and has purpose, who cares about line count...I don't.
|
|
|
|
|
Slacker007 wrote: If all the code is concise and organized well and has purpose Which is almost never the case in a 9k lines file
|
|
|
|
|
Probably has five recursive functions buried in the middle of the file, which calls all of the other functions. Each recursion is controlled by a different combination of global variables defined and controlled in other units.
|
|
|
|
|
A frightening large fraction of modern programmers believe that putting each method/function into its own individual file, headed by a 90 line open-source license statement, magically solves those problems.
|
|
|
|
|
Those guys are posers.
I put every word in a separate file.
I use a build script that concats all necessary files so it becomes a compilable script again.
That way, I never write a single word twice, so it's completely DRY!
Let the build server handle the complexities.
Also, when a function is compiled it becomes its own service, because a service should do one thing only.
Naturally, I'm using Kubernetes to deploy all my services.
It's completely SOLID I tell you
|
|
|
|
|
Well, one of the worst I ever saw had a single method that had over 25K lines. It was so convoluted, it blew up the Cyclomatic Complexity calculations.
|
|
|
|
|
Oil and gas FORTRAN programs would typically run that long. No comments. 8 letter names. Engineers.
My source gets split when it's description gets too cumbersome (indicating code smell): e.g. "the charge, pursuit, retreat adapter".
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
A couple of weeks ago, I told the story about the Fortran compiler that had to be extended (actually, replaced by a completely new one) to handle one customer's Fortran function, having more than the old compiler's limit of 99 arguments.
I have no information about the number of lines in the function. Even partial classes won't allow a single function / method to be spread over several files.
|
|
|
|
|
I suspect that author was afraid of arrays. Any layman thinking of arrays would probably think solar panels.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
What language?
C# should never have been released to the wild without partial classes.
For me, it's not directly about the size. I wouldn't break up a file simply because it's larger than X units.
The point is that being "too big" can make things hard to find, and "too hard to find" is what matters more than simply "size".
Similarly, having two pieces of code in separate files makes it easier to have them open in two windows beside each other for whatever reason you may need to do that.
Splitting the code for an application into several files makes version control easier and reduces change conflicts when multiple developers are working on the same code base.
And code sharing between unrelated applications is easier when the applications share a minimum of code and don't share code they don't actually rely on.
The lower and more common the code is, the more granular it should be.
My library code is in single-method (possibly a family of overloaded methods) files, and each application can include only the parts it requires.
Higher level -- application-specific -- code should probably be separated more by functional area; frontend, backend, configuration, administration, etc.
Multi-file projects just make everything better for a team of developers.
Size itself doesn't matter.
|
|
|
|
|
I *wish* C++14 and above had partial classes
To err is human. Fortune favors the monsters.
|
|
|
|
|
You can't split a class into multiple files in C++ to be compiled together into one executable? I'm pretty sure you can, but I only ever dabbled in C++ back in the day.
Or are you saying that you want to have different parts of a class compiled into separate executables (DLLs)?
|
|
|
|
|
No, it would be nice to be able to declare a class twice in two different files and have it compiled into the same binary.
C++ does not let you do that, at least not to my knowledge, unless they added it after C++17.
For example, I have a draw class that handles all the drawing operations in my graphics library.
It would be nice to segregate the different drawing primitives into different files, but the only way to do that is to delegate and forward or to use multiple C++ implementation files for a single class, but you still wind up with all the method definitions for all the drawing primitives in the same header.
You can hack around it using the preprocessor, by #include ing class fragments, but that's techy.
Edit: You can use inheritance to approximate it, but that still runs you into visibility issues.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Hmm, odd, I was sure I had done that back in the 80s or 90s. I must be mistaken.
PIEBALD goes spelunking and finds some old C++ code...
Ah, you are correct (of course), I was mistaken for the most part.
I see by my code that the class has to be defined in one place, but that the implementations of the members can be separated out into other files -- and I'm using #include to combine the code together.
When C# 1 was first released, a class had to be fully defined and implemented in one file -- which was horrible -- but C# 2 added partial classes (and interfaces), with which a class definition and implementation can be spread across multiple files.
I do see that something similar could probably be accomplished with C++ (and maybe C# 1) by using the C-preprocessor, but that wouldn't be as clean.
|
|
|
|
|
Yes, you can. Class definition has to stay in one file but implementation can go in any number of files.
Mircea
|
|
|
|
|
But with C# (2 and newer), the definition can also be spread across files; not just the implementation.
C# combines the definition and implementation together (other than abstract members).
|
|
|
|
|
I know, but my monster is C/C++
Mircea
|
|
|
|
|
If it ain't broke, don't break it.
|
|
|
|
|
You certainly can declare a class in a single .h file and have the implementation spread over multiple .cpp files. That has been possible since ARM C++.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Sure, but you wind up with an .h file with all the declarations for the class in it, regardless.
To err is human. Fortune favors the monsters.
|
|
|
|
|
No idea of the lines count, but almost certainly assembler code: maybe 1/2MB or thereabouts?
The assembler we were using only supported single files: no includes, no relocatable blocks, no linker. For a 32KB ROM, that's only 16 chars per line so it's probably about right - maybe a little conservative.
Since the ROM was full, and most common instructions one byte long, maybe 28K lines or so?
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Well, it was a long time ago but back in pre-history when I was writing COBOL (no longer on cards thank God) the main program in an overnight suite I supported was (I think) 21,000 lines of code (well, code + blank space). We did everything we could to avoid printing the thing (360 pages), so the listing was frequently annotated by hand. Of course that didn't really help when the actual code had typos that still allowed it to compile.
As overnight on-call support, I'd frequently get bleeped (by pager) and have to hook up the 600baud teletype to my landline, and get the relevant bits of memory dump. (Most issues were S0C7 faults). Yes, for some reason data was never properly validated; actual code bugs were rare, but get a non-numeric character in a character column in data and the whole shooting match failed.
|
|
|
|
|
DerekT-P wrote: the listing was frequently annotated by hand Wasn't that common practice in the 1970s-80s?
In my student days, I was an intern in a company making 16bit minis and 32bit superminis, running their own OS (in those days, 'Unix' was hardly known at all outside universities). I managed to isolate a bug in the OS, and went to the responsible guy. For quite a while, he flipped back and forth in his huge OS source printout, before exclaiming a "There!", dug out his ballpoint pen and wrote the code fix into the listing.
What makes me remember it better than I would otherwise: This OS was written in a language about midway between assembler and K&R C. He didn't write his fix in that language. He didn't write the assembler instructions. He wrote down the numeric instruction codes, in octal format.
I guess that this qualifies for being an 'oldtimer'
|
|
|
|