3 ms·

Consider a codebase where all variables are consistently named with single letters and all values are string-typed for consistency. Somebody comes along and cr

Consider 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 ago
Yes, 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 ago
I 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 ago
I 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?
- JonChesterfield 3y ago
  Functions that return types wrapping int instead of raw ints are a good thing. Error codes in particular really should be something enum like and not 32 bits of best of luck. In contrast, having some containers call it size and others call it length is indeed moderately unhelpful.
  - Timon3 3y ago
    > Functions that return types wrapping int instead of raw ints are a good thing. Error codes in particular really should be something enum like and not 32 bits of best of luck. That's not what I described. I was talking about numbers without special meaning, and with types which require manual implementation of any conversion. One function might return a container whose length() function returns a wrapped integer, and a different container with the same function name returns a different wrapper. You can't combine those wrappers without explicitly defining a conversion. That's what inconsistency in return types means. > In contrast, having some containers call it size and others call it length is indeed moderately unhelpful. And now imagine it's not just two options, but literally every container returned by every function being special. That's what it means to be inconsistent. But as you can see in your example - even small bits of inconsistency (1 bit, if you want) are annoying and unhelpful.

FeepingCreature 3y ago

Yes, 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 ago

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

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

JonChesterfield 3y ago
Functions that return types wrapping int instead of raw ints are a good thing. Error codes in particular really should be something enum like and not 32 bits of best of luck. In contrast, having some containers call it size and others call it length is indeed moderately unhelpful.
- Timon3 3y ago
  > Functions that return types wrapping int instead of raw ints are a good thing. Error codes in particular really should be something enum like and not 32 bits of best of luck. That's not what I described. I was talking about numbers without special meaning, and with types which require manual implementation of any conversion. One function might return a container whose length() function returns a wrapped integer, and a different container with the same function name returns a different wrapper. You can't combine those wrappers without explicitly defining a conversion. That's what inconsistency in return types means. > In contrast, having some containers call it size and others call it length is indeed moderately unhelpful. And now imagine it's not just two options, but literally every container returned by every function being special. That's what it means to be inconsistent. But as you can see in your example - even small bits of inconsistency (1 bit, if you want) are annoying and unhelpful.