Fighting a monster
-
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' :-)
-
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
A project I inherited had a 1200-line function, duplicated 7 times, each with slightly different input parameters and doing something slightly different. Very subtle differences, which were easy to miss. I spent weeks trying to refactor it and deduplicate as much code as I could. I think in the end I had a single function, 700 lines long, that took in a few more input params than the 7 original functions, and branched off on those as appropriate in the code. I was still not satisfied with it, and frankly I'd still rather not even think about it. It was written by one of the company founders, who should never have been allowed anywhere near a compiler. [going on a tangent, you got me started] :-) I spent an awful lot of time trying to convince him something he had in mind couldn't be done, unless he intended to have someone dedicated full-time to keeping that code up to date, as the data it needed to gather came from different software companies that didn't talk to each other or standardize on anything and could change on a whim. The data was never intended to be read by third-parties, so they could change format as often as they wanted (and they did). He wasn't happy with my justification, so he then decided to take it upon himself to "write it in a weekend"...come Monday morning, he had something that worked, which he showed to other people (who didn't know any better) who complimented him on the work and decided to commit to it, and why couldn't I have come up with that since it only took the other guy two days to do it. His code was only compatible with the data produced by one version of the third-party software he was working with. Nothing else. And within a week it was broken because the data format had changed.
-
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
-
A project I inherited had a 1200-line function, duplicated 7 times, each with slightly different input parameters and doing something slightly different. Very subtle differences, which were easy to miss. I spent weeks trying to refactor it and deduplicate as much code as I could. I think in the end I had a single function, 700 lines long, that took in a few more input params than the 7 original functions, and branched off on those as appropriate in the code. I was still not satisfied with it, and frankly I'd still rather not even think about it. It was written by one of the company founders, who should never have been allowed anywhere near a compiler. [going on a tangent, you got me started] :-) I spent an awful lot of time trying to convince him something he had in mind couldn't be done, unless he intended to have someone dedicated full-time to keeping that code up to date, as the data it needed to gather came from different software companies that didn't talk to each other or standardize on anything and could change on a whim. The data was never intended to be read by third-parties, so they could change format as often as they wanted (and they did). He wasn't happy with my justification, so he then decided to take it upon himself to "write it in a weekend"...come Monday morning, he had something that worked, which he showed to other people (who didn't know any better) who complimented him on the work and decided to commit to it, and why couldn't I have come up with that since it only took the other guy two days to do it. His code was only compatible with the data produced by one version of the third-party software he was working with. Nothing else. And within a week it was broken because the data format had changed.
dandy72 wrote:
decided to take it upon himself to "write it in a weekend"
Hey, I heard of another CEO who wrote FAT on an airplane, for heaven's sake[^] :laugh:
Mircea
-
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' :-)
-
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 recall the longest file, but it was definitly many thousands of lines long. The last application I worked on had quite a few of these, even individual functions that long. Ugh. Those functions tried to do everything and I'm sure they cost the company more than they were worth to maintain. I'm the same as you; around 1000 lines I start to get uncomfortable. 500 is the sweet spot. It gets really annoying to have to use tools to hunt for your spot in the file every single time, rather than just paging there. Good monitors have made a little extra length easier to tolerate, but not that much. It's generally a bad smell. Some files just get that way because of neglect, which is its own source of problems. If you see this symptom, expect others. Careful, incremental refactoring over a period of years can help, but you still have a job to do, so there are limits. Good luck with your new codebase. It's a chore, but hopefully you'll find lots of gems, too. - Owen -
-
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
I have some of that using csc.exe. Before VS Code and Community VS, there was free csc.exe. It was hard to justify a license that cost of hundreds to thousands of dollars for a few utilities. I had one utility I developed this way that could triple deploy: Debug/Dev: run as a console app that would spin a WCF service IIS: WCF module Windows Service with installer: WCF module for deployed systems that did not have IIS
-
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
27928 lines. It's an order form with many tab sheets and sub-tab sheets. Surprisingly, most of the business logic is not in this form. It's mostly UI handling stuff. This does not include the designer file, which is 36270 lines.
Bond Keep all things as simple as possible, but no simpler. -said someone, somewhere
-
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
The biggest file in one of the 20-year developed repository that I have seen before contains 13189 rows and its history begins not a long ago, in 2006 :-( Only nine files in the repository are longer than 10000 rows, but there are 65 (sixty-five!) files longer than 5000 rows. Try to live with this without regrets and remorse :-)