pull down to refresh
637 sats \ 0 replies \ @jimmysong 27 Sep 2023 \ on: Inheriting Shit Code. What Makes a Codebase shit? tech
Your list so far is good and I agree with those. But here are some additional things that particularly irk me.
- Code that's too clever. Yea, you can munge some data structure to do something in one line, but it's going to take me 20 minutes to figure out what that line does and it often has subtle bugs in there because it doesn't do any error checking. Bonus points if there's no documentation saying what it does.
- Bad variable names. This is really an art and good code makes obvious what the variables are doing and how to change them. Bad code makes this a complete guess because they're named something like "data" or "element" or even worse "x". There are exceptions, of course, but it really hampers readability or changes down the line when variable names are vague, or even worse, deceiving.
- Too much abstraction. This is particularly egregious with Java programmers, who seem to want classes for everything. Now you have to open 13 different files to find out where the actual implemented function is and it's not at all obvious where you have to make changes to fix the bug.
- Uberfunctions. A method or function that's 3 pages long and does 30 different things is just asking for trouble. I've seen so many of these that the programmer was too lazy to separate. The problem is that a function that's really long is very hard to conceptually keep in your mind when you're fixing something. And it's really easy to break. I can almost guarantee that these functions also lack unit tests, making changes to them very difficult.
These are some of the things that really annoy me, though there's probably a lot more. It just smells bad.