A project with a single 11,000-line code file

Post by gridspy » Sun, Apr 03, 2022, 9:46 PM UTC

jokethrowaway wrote: post #119

gridspy wrote: post #101

Earlier quoted context omitted.

Be Team C. Team C works like team A. However every time a feature ships, someone who knows that feature well immediately refactors the relevant code to remove the prototype scaffolding. When code becomes static, an expert adds good quality comments. When a bug is found, it is recreated in a regression test prior to being fixed for good.

The sad reality of tech companies is that there is little incentive or bonuses for improving the situation. You won't get a bonus for cleaning up the code or for rewriting rotten code. Hack at the code for 4 years, collect your options and leave the mess to someone else. To be honest, a hacky codebase written fast is not the worst codebase to deal with. The worst type is when someone had the time to overarchitect and…

Post by formerly_proven » Sun, Apr 03, 2022, 9:49 PM UTC

userbinator wrote: post #102

I 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…

Post by rc_mob » Sun, Apr 03, 2022, 9:53 PM UTC

briantkelley wrote: post #87

I worked on Word for years. Office has thousands of files over 10,000 lines with, uh, various degrees of test coverage and comprehensibility. After some time and experience, your mental model of the architecture ends up being way more important than simple metrics on source code organization. IMO, organizing source code in files seems archaic. E.g. tracing the history of a function moved across files can be tedious e…

Post by thedanbob » Sun, Apr 03, 2022, 9:58 PM UTC

lucb1e wrote: post #126

thedanbob wrote: post #8

I once inherited a mission-critical PHP project which had no version control, no tests, and no development environment (all edits were made directly on the server). It used a custom framework of the original author’s own devising which made extensive use of global variables and iframes and mostly lived in several enormous PHP files. I was able to clean it up somewhat, but there was one particularly important file tha…

My first thought when reading this description was that step one is to make a local copy, get a development environment setup where you can toy around, see how things fit together. The 'stupid'er the setup (like using plain old files instead of a database), the easier that actually gets (apt install apache2 php; rsync da:files /var/www). Wouldn't that have helped solve this particularly important but untouchable file…

Post by farmin » Sun, Apr 03, 2022, 10:04 PM UTC

khazhoux wrote: post #80

kbrannigan wrote: post #39

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

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…