|
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.
|
|
|
|
|
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.
|
|
|
|