|
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  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 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.
|
|
|
|
|
Sri Krishna wrote: at each step we learnt the mistake we did previously, made amends and then made some more mistakes
Experience is the ability to recognize a mistake when you repeat it.
|
|
|
|
|
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.
|
|
|
|
|
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 sh*tty 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 
|
|
|
|
|
I'm working on a 17,000 line Python script now and it doesn't feel particularly unwieldy.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
