Fighting a monster
-
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
Original Pascal had no module concept. All code had to go in a single file. Open source is not as new as Linux people will make us believe! The Pascal P4 compiler was always freely available. I picked it up as a university freshman and studied on my own alongside working on the '101 Introduction to Programming' hand-in exercises. I'll say that it gave me a head start in programming ... The compiler source was between 30,000 and 35,000 lines. For quite a few years following, I was really bothered by the upcoming C source file common practice of creating a separate file for every single function: How can you find anything at all in the source when you have to open hundreds of files for searching? Tools for searching across an entire directory tree wasn't very developed then - not until the C practice had become more widespread. Today we have the tools. We also have FOSS. Even today I am appalled when I have to handle a zillion files, each containing 70-100 lines of open source license/copyleft blurb, followed by a five line function. In every single one of a zillion files!
-
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 *wish* C++14 and above had partial classes
To err is human. Fortune favors the monsters.
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.
-
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
Thank you all for replying to my question. I understood that: a) I'm a wimp for complaining about size. b) Almost everyone thinks "my (source code) is bigger than yours" - honi soit qui mal y pense :)
Mircea
-
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.
-
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
Around 10 years back, I joined my first company, where I was introduced to a codebase which was in Java/XML, kind of an Android Application. I saw files having 12k lines. It was a nightmare situation for me to even navigate the code and to follow up on a bug we were supposed to fix! As we progressed through the years, we found lower lines per file, saw IDE limiters on number of lines in a File(Max 1000), saw Coding Architectures like MVX(MVP, MVVM, MVI, etc.) asking us to break up code blocks into smaller more testable modules, saw Testing Tooling and other advice from many asking us to test a smallest unit. Overall, the experience is a very rewarding, at each step we learnt the mistake we did previously, made amends and then made some more mistakes :laugh: and then fixed them in the coming months.
-
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
Hello World is about 10 000 lines of code in C++
Nothing succeeds like a budgie without teeth. To err is human, to arr is pirate.
-
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 ;)
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
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
I don't know the largest file I've ever worked with, but I currently have a project with about a 4k lines file. It's a VB.NET WinForms file. The form draws lines and squares onto a picture. Imagine a plot of farm land on the picture, and the form's functionality drawing the plot's outer edges and separating them into x strips. That's what it does and all the logic is in that single form. Unfortunately, there is no clear naming convention, so a variable can be named "square" in one function and a "box" in another. The form has over 90 fields, which I all have to take into account whenever I change something. I know the original developer, and he had a lot of trouble writing this, probably because he's very bad at dividing a problem into smaller sub-problems. Or maybe because he's a real shitty developer. Luckily, it works most of the time, but if it doesn't work it stresses me out and I propose a rewrite. I think this is the only code in my entire career I dare not touch :sigh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
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' :-)
Guess the fix might have been just directly manipulating the binary executable. Have had to do that a few times. Other than that, the places I worked were usually quite good at keeping up-to-date hard copy listings. But then this was before VDUs. We also, of course, had the card decks, and they were all carefully maintained and filed. We even had a card printer that would read a punched card and type the contents along the top. Useful, as though most of the punching was done by the girls (and only girls) in the punchroom - whose machines printed the text on the cards - we also had access to a punch machine for doing the occasional edit, and that one didn't print. So looking through a deck you'd come to a revision but didn't know what the code was. (Well, you could just hold it up to the light and read it - became second nature after a while!)
Telegraph marker posts ... nothing to do with IT Phasmid email discussion group ... also nothing to do with IT Beekeeping and honey site ... still nothing to do with IT
-
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
I'm working on a 17,000 line Python script now and it doesn't feel particularly unwieldy.
-
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
Mircea Neacsu wrote:
Got me wondering: what's the largest single source file you ever met?
12 thousands line of C code, without any indentation at all and scant comments.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
Around 10 years back, I joined my first company, where I was introduced to a codebase which was in Java/XML, kind of an Android Application. I saw files having 12k lines. It was a nightmare situation for me to even navigate the code and to follow up on a bug we were supposed to fix! As we progressed through the years, we found lower lines per file, saw IDE limiters on number of lines in a File(Max 1000), saw Coding Architectures like MVX(MVP, MVVM, MVI, etc.) asking us to break up code blocks into smaller more testable modules, saw Testing Tooling and other advice from many asking us to test a smallest unit. Overall, the experience is a very rewarding, at each step we learnt the mistake we did previously, made amends and then made some more mistakes :laugh: and then fixed them in the coming months.
Sri Krishna wrote:
at each step we learnt the mistake we did previously, made amends and then made some more mistakes :laugh: and then fixed them in the coming months.
Life experience is exactly the same. Nobody know everything from the beginning.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
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' :-)
Your and Derek’s stories remind me of a life lesson from the same era. As a young uni student, I was fighting with an assembly language program and the assembler was giving all kind of strange error messages. Showing the problem to the TA I was working with, he didn’t figure it out either and sent me to author of the assembler, a guy just a few years older than me. He looked at the problem and went: “yes, I see what’s going on, come back in the afternoon for a solution”. In the afternoon, he gave me a single punched card to add to the deck of punched cards that was the assembler program - in those days you loaded the assembler from punch cards - and that indeed solved my strange error. For me the whole thing was almost like magic. Some time later I figured the error had to do with the evaluation to different values of a symbol during different assembler passes and what the guy did was to make a binary patch that fixed the problem. Why I say it was a life lesson for me? When I saw that guy figuring out quickly a problem that had both me and the TA stumped, and giving such an elegant solution (a single punched card), the young, cocky me realized there are people much smarter than me in the world and some humility is always in order.
Mircea
-
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
I think the opposite situation is even worse. You get some abstraction/interface monkey at the keyboard and you may find yourself jumping through a dozen different 5 line files to get to the actual code that adds X + Y. Tons and tons of code written to handle the unlikely event that your boss is going to walk into your office one day and say, "Hey, let switch from Oracle to SQL". I understand some vended products feel the need to support that, but they don't.
-
I think the opposite situation is even worse. You get some abstraction/interface monkey at the keyboard and you may find yourself jumping through a dozen different 5 line files to get to the actual code that adds X + Y. Tons and tons of code written to handle the unlikely event that your boss is going to walk into your office one day and say, "Hey, let switch from Oracle to SQL". I understand some vended products feel the need to support that, but they don't.
MadGerbil wrote:
You get some abstraction/interface monkey at the keyboard
Yes. I have a former coworker who was Mr. Object. He took three or more abstraction layers to do just about anything, no function was more than 8 or 10 lines, and it was difficult to follow. Fortunately Intellisense in later versions of Visual Studio (this is C++) works well enough that navigation isn't limited to "Find-in-files, edit, rinse, repeat."
Software Zen:
delete this; -
I think the opposite situation is even worse. You get some abstraction/interface monkey at the keyboard and you may find yourself jumping through a dozen different 5 line files to get to the actual code that adds X + Y. Tons and tons of code written to handle the unlikely event that your boss is going to walk into your office one day and say, "Hey, let switch from Oracle to SQL". I understand some vended products feel the need to support that, but they don't.
"Abstraction monkey" I like that! Can I use it? :laugh:
Mircea
-
"Abstraction monkey" I like that! Can I use it? :laugh:
Mircea
-
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
many years ago. I was hired on to take over an outsourced application. The devs for the outsourced app had never heard of libraries or headers or includes etc.. So therefore they had replicated all the various functions and other things that the program relied on into the the top of every file in the entire project. and they only wrote code in Notepad. Not notepad++ or something decent. Windows notepad. They also command line compiled the whole thing. (not c or C++) it was this weird complex development of C# and VB.net. And yes you can command line compile and open the thing in NotePad. But why would you. So I spent my first 6 months just rewritting the entire thing and creating includes and dll's etc.. and putting the whole thing into Visual Studio so it could be compiled. Oh and did I mention Source Control. Yep implemented that as well. Largest file was well over 9k lines. When done. I don't think anything was over 100. I don't miss that job.
To err is human to really elephant it up you need a computer
-
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' :-)
