| Reading and untangling code is the best part of coding in my opinion. It’s like solving a fun puzzle and trying to incrementally evolve a system. What I hate is inconsistency. Inconsistency is what makes code intolerable to work with, because changing it becomes so much harder. Consistency, in the way I mean it, does not mean DRY or over-abstraction. What I mean is, pick a mindset or design philosophy and stick to it. Don’t randomly switch between exceptions and returning errors. Don’t over-abstract some areas early on and then spaghetti code other areas. Have some consistency in how you do this. For example, have a rough standard for when something is X or Y. Either accept spaghetti code for areas and keep things uncoupled as much as possible (my preferred), or have some concept of abstraction you apply to new layers. Just rough examples. If it turns out you did it wrong, which is likely, then it is relatively easy to reason about a change. But as soon as you lose the consistency then it becomes a nightmare. Don’t have special snowflakes in your code. The last thing I’ll write is.. sometimes the over-generalization this article makes is used as a weapon to justify sunk cost fallacy. Sometimes throwing away a part of your codebase and starting from scratch is the best thing to do. But you should work with it for a bit to understand the code before doing so. |