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' :-)
-
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 :-)
-
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
Here in Brazil sales taxes are Lovecraftian levels of nightmarish. We have a form in a shared Windows Forms library that we use in several of our "of the shelf" products that deals with invoicing and taxes of product sales that is 17K lines in and of itself, no counting helpers and specialized components and dialogs. Most of that code it to manage the interacion between the UI and the rules and calculations for taxes. You sometimes see people complaining about doing income tax declarations, they have no idea how it is like to sell a simple piece of candy in Brazil.
-
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
fine for what you describe. But I am talking about full blown enterprise application for handling the entire companies book of business for orders etc... It was freakin huge. and should not have been command line and should have been inside Visual Studio and in a Source Control repo.
To err is human to really elephant it up you need a computer
-
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
-
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
Fixes to that OS was distributed as binary patches to the executable! A few areas was set off in the executable for code that wouldn't fit in the original place (requiring more instructions that the old code), so a jump could be inserted in the buggy location to the code in that spare area, and then jump back. You wouldn't leave such tasks to interns :-)
-
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.
-
The company was called Norsk Data (when established: "Norsk Data-Elektronikk", "Norwegian Computer Electronics". The machines were named Nord-1, Nord-5 (the 32 bit ones), then Nord-10 and Nord-50. At the time of the story I told, they were ND-100 and ND-500. Later came an ND-5000, but I don't think there ever was any ND-1000. The fun thing about octal for the ND-100 is that it really didn't fit the instruction format at all: Most instructions was built from 4 fields, each 4 bits. In the same period, the MC68K was about to enter the market: With 8 registers, 8 addressing modes, always the low bits, only uppermost opcode field was of 4 bits. Yet binary MC68K instructions was always presented in hexadecimal format (unless, of course, the bit pattern was shown - which often was the case).
-
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
-
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.
My rule-of-thumb for creating functions (/methods/procedures/...): If it represents another level of abstraction, then create it. If it doesn't, write it as inline code. It really is obvious. Yet, I often see code where the programmer obviously went "Ooops! Max line count reached! I'll have to put the lines above this point into a function, and create another function for the remaining lines." Functions representing nothing but some sequence of statements with no common purpose or meaning of life. Of course this is more prominent with junior programmers. But a fair share of programmers never grow up.
-
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.