this post was submitted on 23 Mar 2025
54 points (100.0% liked)
Programming
19246 readers
44 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Consistency is NOT the most important thing. Correctness is. This guy has been in the trenches flinging shit too long. I work with vendors and do my best to use the subset of their product that actually works correctly. I don't want new features to work like shit just because the old ones did too.
What point do you think you're making? I mean, do you think anyone looks at a PR and says "this PR is clearly wrong, but it's so consistent that I must approve it." That's obviously not the point, is it?
I've definitely seen "this is more correct, but all the other code does it like this so can you change it?"
I can't say I entirely disagree with it either - usually the "more correct" is not "the existing code doesn't work at all", and keeping it consistent makes it easier to fix all of the code later, because you're only fixing one style instead of two (or more).
I found the title of that section slightly triggering too, but the argument they lay down actually makes sense. Consistency helps you to achieve correctness in large codebases, because it means you don’t have to reinvent what is correct over and over in separate pockets of the codebase. Such pockets also make incremental improvements to the codebase harder and harder, so they do come back to bite you.
Your example of vendors doesn’t relate to that, because you don’t control your vendor’s code. But you do control your organisation’s.
Consistency as a means to correctness still means correctness is the more important aspect. Far too many projects and people that go hard on some methodologies and practices lose sight of their main goal and start focusing on the methods instead. Even to the point were the methods are no longer working toward the goal they originally set out to accomplish.
Always have the goal in mind, once your practices start to interfere with that goal then it is time to rethink them.
I’m not arguing against that. Merely providing some counterweight to the idea that the author was “flinging shit in the trenches” 😅
From a maintainability point of view consistency is important. I’d rather work with an consistent but incorrect code, than correct bit inconsistent code. With a consistent code base it’s easier to do something about the incorrectness, especially if it’s consistently incorrect. It’s also easier to delegate the work.
Code is rarely correct forever. Sooner or later, requirements will change. What once was thought to be correct is no longer correct. It’s difficult to do anything about it if the code is inconsistent as well. It requires a lot of mental effort to understand the thought process behind some code.
I agree that correctness is the goal, but consistency is one of the best ways to ensure this goal.