3 ms·
Code unambiguously defines 'what' it's doing, so I'm not sure what value technical consistency provides. If anything, consistency hurts the capacity for develo
by Splizard 3y ago
Code unambiguously defines 'what' it's doing, so I'm not sure what value technical consistency provides.
If anything, consistency hurts the capacity for developers to generalise their understanding of a system. Differences in representation ie. multiple perspectives, help people to develop their understanding of the underlying concepts of the system.
This is important because code doesn't effectively record concepts, intents and oughts. These are things recorded within the context of the system. So the more context, usage and interactions available, the more opportunity for learning.
I think consistency is one of those things that sounds appealing and offers the illusion of making development 'easier' but boils down to someone deciding by fiat that their poorly communicated representation of the system is correct and nobody else should add their own representations of the system to build up a useful level of context and understanding.
- edoloughlin 3y ago> Code unambiguously defines 'what' it's doing, so I'm not sure what value technical consistency provides Unless it’s really convoluted, most of the time I’m reading code, I’m concerned with why it’s doing something. Technical consistency helps understand the intent by removing distractions and the need to switch paradigms.
- tester756 3y agoConsistent code base makes it easier to read to onboard new people to review if you have e.g 3 different ways to handle error handling then it is a mess. one time you expect exceptions, other time monads, other time int values.
- physicles 3y agoIt also makes it faster to write code. If the code base has a strong culture around doing X, then whenever you do X, you don’t have to spend time thinking about the best way to do it.
- Timon3 3y agoHard disagree. Inconsistency increases the amount of time needed for any feature and increases the likelihood of bugs. There is no upside in having to understand each individual piece of functionality from the ground up, because a lot of functionality is simply repeated in slightly different ways. What you call "hurting the capacity for developers to generalise their understanding of a system" is what I would call "building the capacity for developers to generalise their understanding of a system" - consistency is what allows for generalization.
- Splizard 3y agoConsider a codebase where all variables are consistently named with single letters and all values are string-typed for consistency. Somebody comes along and creates a new, isolated piece of functionality using words for variable names and using the languages type system for numeric values and structures. It works well. It certainly looks like this inconsistency would make it easier to work with this code in the future. Any conversion functions introduced that deal with the consistent string types and the new inconsistent types will help new developers understand both types of code.
- FeepingCreature 3y agoYes, but- note that the new code imposes a cost in understanding, at first, because it doesn't work the way the old code does. Then it makes up for that cost by just being so much better that it's on net easier to understand anyways. That doesn't mean the cost isn't there.
- williamdclt 3y agoI don’t think anybody is arguing that consistency is _the only thing_ that matters. The argument is that « consistent and reasonable patterns » is preferable to « inconsistent yet just-as reasonable patterns » by most criteria
- Timon3 3y agoI don't think that is in any way a realistic example. But let's turn it around: consider a codebase where every type is aliases for every use. Any function that returns an int has it packed in its own type, and if you want to use that type somewhere else, you have to add a new method to turn it into that other type. Every function returns multiple values, but in slightly different containers. Each container is unpacked slightly differently, has a slightly different memory layout. Why would the above be easier than a codebase that always uses int and returns tuples?