|
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
|
|
|
|
|
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;
|
|
|
|
|
"Abstraction monkey" I like that! Can I use it? 
Mircea
|
|
|
|
|
Wouldn't IMonkey be better?
Just to be safe.
|
|
|
|
|
IUnknownMonkey
At least that way you can query it for standard interfaces that are supported as well as the monkey business interfaces.
|
|
|
|
|
I once had to dabble in a Fortran project with over 5000 files. It was mind boggling.
|
|
|
|
|
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.
|
|
|
|
|
MadGerbil wrote: "Hey, let switch from Oracle to SQL".
To be fair that actually happened to me. But from SQL Server to Oracle. It took me, by myself, a bit less than two weeks and had no impact at all on any other developer. Customer mandated it. The boss that just delivered the news was rather skeptical about what impact it would have.
There was a very specific DB API although without a lot of layers.
Contrast with the more recent job where the required change from SQL Server to MySQL is closing in on 2 years now. And still not done. That didn't have a DB API layer. It has a mismash of various idioms and misuses of various APIs over years.
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
In the COBOL days 20K lines per source was not uncommon. But then, that was COBOL.
|
|
|
|
|
One "Hacker's dictionary" listed "Cobol Fingers" as "Fingers worn down to a single joint". 
|
|
|
|
|
Still... a well written COBOL program is elegant AND I can open any damn pickle jar I encounter.
|
|
|
|
|
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 sure like the ending of that story! (The Old New Thing is always worth reading!)
|
|
|
|
|
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.
|
|
|
|
|
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 
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
não é reddit, mas r/suddenlycaralho !
Que vai querer no print, meu bom companheiro Dev BR, sofredor com cálculo de IPI/PIS/COFINS?
|
|
|
|
|
12k lines in Program.cs for a console/batch processing application running at a government authority where I used to work. It was for validating and processing Financial Transactions (MiFID II)
The original developer was on extended maternity leave+vacation (1.5 year). No one wanted to give maintenance to it (neither the original dev, when she came back 8 months after I was hired) because it was too unwieldy to do anything there. I was hired specifically to deal with it. Took around two months to have it on my mind to actually start breaking it down.
Since no one was interested in working on the beast, I kinda grew fond of the project because it was important, and no one bothered/pressured me when I told them that improving things would take time. Also, I was free to perform any needed refactorings to the thing.
I managed to improve its performance by several times first (to remove processing bottlenecks), and then started refactoring it, bit by bit.
It was a pity I had to leave that project behind and go back to my home country. Since I was a contractor, and it was before the pandemic started, so people were not very fond of offering me to work remotely.
|
|
|
|
|
I was tasked with "tidying up" a killer demo hacked up by a data scientist on our team during his holidays.
After looking at the single 15k line Javascript file he produced, I suggested we rewrite the demo frontend from scratch since it was going to be difficult to work on (even though it looked really polished).
That suggestion was shot down as unnecessary engineering, but when I looked closer it became clear that he'd "borrowed" a complete demo published by another company -- a single minified Javascript file -- and swapped out of a few pieces so it called his own prototype backend running on a laptop (that bit at least was entirely his own work).
At that point I suggested this might be a good reason for us to proceed with the frontend rewrite, and that I wouldn't be comfortable putting my name on another company's pilfered and tweaked demo. The DS seemed relieved and immediately agreed. He was a good guy, but probably crumpling under delivery pressure from management, and he never really intended for an internal proof-of-concept to suddenly become a user-facing feature of the site, but by then it was hard to backpedal until I forced the issue.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
