I see people do this all the time with terraform and it's madness.
Terraform is declarative, so it's much easier to refactor.
A project with a single 11,000-line code file
271–280 of 346 posts
Re: A project with a single 11,000-line code file
#272I learned that not all text editors go to the effort of loading the file data very carefully with careful underlying data structures when I tried to open a 67K LOC COBOL file on a 32bit system, a while back. (Sidenote: COBOL has a 999,999 LOC hard limit in the compiler spec.) So very many editors just couldn't open it. Some would use so much memory that the system would either freeze, or the OS would kill them. Some…
Emacs is actually quite poor at opening large files, at least comparatively—depending on the machine, 65K lines may be enough. However, there's an addon, i.e. a ‘mode’, that implements editing of large files somehow.
Vim, on the other hand, does it splendidly: it keeps only a chunk of the text in memory, and iirc the ‘swap file’ that it creates for every opened file, keeps the changes in some kind of a sparse structure, so they can be tracked at various places in the original file. This ‘swap file’ also serves as a savepoint of the editing session, so the changes can still be recovered even if the machine crashes while the user never saves.
Alas, editors still tend to deal badly with very long lines (just in the low thousands characters). IIRC both Emacs and Vim drop into a big think if the user attempts to put the cursor further down that line.
Re: A project with a single 11,000-line code file
#273Earlier quoted context omitted.
The only readability issue I have with that is the functions expected arguments. Add some types and I’d be very happy to work on it. I believe Facebook uses a single directory of files now as best practice? With the file names including namespaces. That was an HN comment from ages ago so could be wrong or misinterpreted.
pg's new lisp, Bel, has something close to typed arguments: (def add1 (x|int) (+ x 1)) http://www.paulgraham.com/bel.html I've been implementing it for a couple years now, though not seriously till the past couple months. There are some interesting (and overlooked) ideas in Bel. Bel is sort of the limit case of generality. For example, you might expect the "type" above to be a separate kind of object, the way that ty…
That doesn't really allow for type checking which is a major purpose of types. It's more of just some nice sugar for runtime assertions
Re: A project with a single 11,000-line code file
#274Earlier quoted context omitted.
I've sadly come to realize (after witnessing on many projects) that there's a pattern that goes like this: * Team A writes code quickly. Not bad code, really, but they take shortcuts everywhere they can. They don't have the strongest tests, they don't generalize for all the known use cases, etc. Their code goes to beta and gets users and makes progress. * Team B deliberates and deliberates. They try to avoid taking s…
+1 I had a lot of trouble trying to explain this to juniors. The most important things is to have code that is easy to refactor when you know what you're doing (i.e. everything is working properly). Juniors I worked with had a nasty definition of a pretty code being split into a hundred files, each no longer than a screen, and each function no longer than 5 lines. The onboarding of new devs to such code was way worse…
This depends a lot on the development environment. In Smalltalk years ago, we were encouraged to limit each method to few lines at the most. This makes sense within Smalltalk and the code browsing inherent in the system.
It makes debugging in Java or C# an exercise in face shredding frustration. Where each class is in a file, it's better to structure the class consistently with other classes in the project, and things like naming conventions become a lot more important.
You could argue that the C/C++/Java/C# languages are fundamentally broken because they don't encourage the succinct, small class methods that Smalltalk did, but you could also argue that those small methods don't necessarily work very well in a different class of languages from Smalltalk and neither approach is really more productive than the other, with the caveat that Smalltalk is largely dead and irrelevent to modern programmers other than a curio.
Re: A project with a single 11,000-line code file
#275Had one like that, too. The previous programmer didn't believe in constants and the code was interpreting a binary protocol. Globals all over the place, too - I refactored a variable once and got a message that production is down; it was, the database was busy deleting customer history on all its connection pool threads. To this day I don't know how that refactor could've caused it. Fun times.
Re: A project with a single 11,000-line code file
#276Back in the days at Zynga, there was this ritual that new members of the STG (Shared Tech Group, which developed the game engine stack) had to try to refactor the road logic code. Suffice it to say, it's a 28k LOC file that was so bad, it could even hold up in court as evidence that a South American company stole the code of Zynga's -ville games. We could reproduce each and every single bug and its effects 1:1 in the…
To be fair, the first step towards refactoring is understanding the existing code -- ideally, knowing everywhere it is used, all of its behaviors, and importantly, its history, so that you don't break anything, and so that you don't reintroduce bugs that have already been fixed over the years. Or, in lieu of all that, a robust automated test suite. This cannot be done with a file containing 28k lines of code. That is…
> Was it just hazing, or was the thought that someone might actually be able to accomplish this?
Actually no. Most devs that just got started familarizing themselves with the codebase wanted to refactor the file and came up with the idea themselves. Usually they thought this is a crappy file and this must be an easy task to do because they saw all the nested if/elseif/else statements in the code.
The problem, architecture-wise, was that the road logic was the glue code that integrated a lot of different parts, layers, and NPC behaviours from the rest of the codebase as it was changing the surrounding game world.
If there was a hospital placed with a non-squared ground tile next to it, if it was placed with a 1 offset (roads were 3x3 tiles), if it was placed with a 2 offset next to another road... It went as far as influencing the path heatmap that was necessary for the A* guessing algorithm to make the NPCs walk correctly on the sidewalks. The permutations of possible sidewalks alone were enough complexity on their own...
So in a lot of ways necessary features that historically had no place in the Entity/Component based engine at some point made it in there.
The next best thing (and also spaghetti code) was the Cursor Entity, which had to have line tracing algorithms to be able to select things that are visible under a donut-like shape when the user was hovering the hole, or say, a tree in the game world. Convex and Concave shapes were integrated, and lots of edge cases in there, too, which are actually huge mathematical problems in terms of available performance once you dig more into it, so we ended up with binary height map sprites that helped both the slicing and the cursor at some point.
The important lessons learned from the road logic were very valueable for newbies, as it was teaching the practical problems of isometric game worlds.
So afterwards everyone was able to grasp why the complexity was added, and what was necessary to remove it (in the sprints in the future).
At some point we decided a couple of things because of the road logic and cursor entity for new iterations of the engine, like:
- always use a 1x1 road tile
- always use square based tiles for all objects
- dont make sidewalks, use just road tiles
- dont make trees with holes in their leaves
- dont make trees higher than the buildings
- no artist can ever request crosswalks. Never ever.
...etc
Re: A project with a single 11,000-line code file
#277TypeScript's checker.ts is a 2.65 MB file containing 44,932 lines at the moment. https://github.com/microsoft/TypeScript/blob/main/src/compil... Does anyone know why and how they maintain it?
const anon = "(anonymous)" as __String & string;
What does that even mean? It seems that typescript uses an alias for string as __String in the source but then a bitwise operator with string?
Re: A project with a single 11,000-line code file
#278So afraid to write bad, spaghetti code, I ended up writing no code at all. This thread made me realize that it's better to have a working profitable project with bad code, than a perfect unfinished project, with meticulously chosen design patterns. Afraid of being judged for bad code, I could not start until I had the right architecture. I'm glad I read this. This is developers therapy.
Restaurant industry version: I was so afraid to cook in a dirty kitchen, I ended up not cooking at all. This thread made me realize that's better to sell food prepared on dirty surfaces with unrefrigerated ingredientes half-eaten by rodents and roaches that makes people sick, than fresh food prepared on clean surfaces with clean utensils. I'm glad I read this. This is a restaurant worker story. Construction industry…
I think your examples are unfair. Getting stuck on needing the perfect architecture is closer to scrapping a building plan because it wouldn't hold up to a 2km asteroid strike than it is building something that will ultimately kill people.
Also all of your examples have wildly different impacts than a dev "portfolio project". They all cause physical harm to people, which a poorly coded website/cli tool/etc almost certainly won't. Unless this person's hobby is writing code for MRI machines, in which case, go ahead and make everything is perfect, but that doesn't seem to be the case here.
Re: A project with a single 11,000-line code file
#279I remember many years ago coming across a reimplementation of the server side for a popular MMORPG of the time, reverse-engineered from the client (which was Flash) by what was likely a teenager --- it was over 100k lines in a single file, written in Visual Basic. Global variables everywhere, short names, and not even indentation. All the account data was stored in flat files, there was no actual DB. No "best practic…
Funnily enough, I have recently had great success by reversing the "best practices" on a distributed "micro services" architecture application into a single big Java file. Best practices were the usual suspects DRY, IOC, SQL + NoSQL, separation of concerns, config files over code, composition over inheritance, unexplainable overlapping annotations, dozens of oversimplified components doing their own thing, and some $…
This application must be really really simple ;), so no database?
Re: A project with a single 11,000-line code file
#280Earlier quoted context omitted.
Restaurant industry version: I was so afraid to cook in a dirty kitchen, I ended up not cooking at all. This thread made me realize that's better to sell food prepared on dirty surfaces with unrefrigerated ingredientes half-eaten by rodents and roaches that makes people sick, than fresh food prepared on clean surfaces with clean utensils. I'm glad I read this. This is a restaurant worker story. Construction industry…
I think your examples are unfair. Getting stuck on needing the perfect architecture is closer to scrapping a building plan because it wouldn't hold up to a 2km asteroid strike than it is building something that will ultimately kill people. Also all of your examples have wildly different impacts than a dev "portfolio project". They all cause physical harm to people, which a poorly coded website/cli tool/etc almost cer…
Basic hygiene when cooking is not perfectionism, and is not only done at elite restaurants.
Dismissing basic development good practices as "perfectionism" is just gaslighting people into believing that any form of thinking is overengineering.