3 ms·

You're not wrong. "Consistency" is a poorly defined principle and basically used to justify "what I'm doing is good (consistent). What you're doing is bad (inco

You're not wrong. "Consistency" is a poorly defined principle and basically used to justify "what I'm doing is good (consistent). What you're doing is bad (inconsistent)" And it was called Uniformity back in the day, not "architecture". A better name for "consistency" is "following project conventions" which IS well defined.

tharkun__ 5y ago
I agree that consistency is good in general. I don't think "project conventions" is well defined. In most places project conventions are either not actually defined anywhere or if they are defined in writing, they're usually either very very old and outdated vs. the actual conventions that everyone is currently using or it's just one guy updating the text and hitting everyone else over the head with the document to push his opinion through. I personally like to be 'locally consistent'. I don't care how old and crusty the code base is. If the file that I have to change or add to calls everything a "giraffe", I will call my stuff "giraffe" as well, even if it really is a "gorilla". If I start calling it a gorilla, nobody will understand that the gorilla is the same as the giraffe if they don't have the same background knowledge I have. Unless I do a refactoring and I am changing the giraffes to gorillas. Which might either be a first PR to "clean up" or a follow up PR. Unfortunately I see so many people not doing that and it wreaks havoc with the code base. Especially if we're now outside of the place that defines the giraffes and gorillas. It's really hard for the caller to figure out that they're one and the same thing.
- jackblemming 5y ago
  >In most places project conventions are either not actually defined anywhere or if they are defined in writing, they're usually either very very old and outdated vs. the actual conventions that everyone is currently using or it's just one guy updating the text and hitting everyone else over the head with the document to push his opinion through. So either admit your project doesn't have conventions, in which case, don't nit people who don't follow whatever convention exists in your head but isn't documented, or document the project conventions. You cannot have your cake and eat it too. That "one guy updating the text" is at least explicitly documenting expectations. Per your "local consistency" comment, if "giraffe" is called "gorilla" in every other file (aka "global consistency"), it sounds like you're just setting up more work for some developer to take care of. Consider leaving a comment and start using the globally consistent name, rather than propagating more inconsistency (technical debt). Perhaps more aptly put, what you call "local consistency" sounds like "global inconsistency" to me.
  - tharkun__ 5y ago
    Oh I absolutely agree with that statement. If you have someone in your place that is actually just documenting what everyone is doing and what everyone is doing is consistent, that's awesome! More power to them. At my current place we do a lot through linters and automatic code formatting for example and we collectively agree on when and how to change the configs for that. Eliminates a whole class of "arguments" (X spaces vs. tabs anyone?) and it's relatively easy to "convert" new hires to it as well. They can either adapt to it, make a really good argument for changing the configs via a widely circulated PR or they aren't a cultural fit to us. My point is that this guy usually isn't. In the vast majority of places I've been or seen it's the other version of him. I.e. the equivalent of the guy at the regulars table that edits Wikipedia to prove his point in a discussion.

tharkun__ 5y ago

I agree that consistency is good in general. I don't think "project conventions" is well defined. In most places project conventions are either not actually defined anywhere or if they are defined in writing, they're usually either very very old and outdated vs. the actual conventions that everyone is currently using or it's just one guy updating the text and hitting everyone else over the head with the document to push his opinion through. I personally like to be 'locally consistent'. I don't care how old and crusty the code base is. If the file that I have to change or add to calls everything a "giraffe", I will call my stuff "giraffe" as well, even if it really is a "gorilla". If I start calling it a gorilla, nobody will understand that the gorilla is the same as the giraffe if they don't have the same background knowledge I have. Unless I do a refactoring and I am changing the giraffes to gorillas. Which might either be a first PR to "clean up" or a follow up PR. Unfortunately I see so many people not doing that and it wreaks havoc with the code base. Especially if we're now outside of the place that defines the giraffes and gorillas. It's really hard for the caller to figure out that they're one and the same thing.

jackblemming 5y ago
>In most places project conventions are either not actually defined anywhere or if they are defined in writing, they're usually either very very old and outdated vs. the actual conventions that everyone is currently using or it's just one guy updating the text and hitting everyone else over the head with the document to push his opinion through. So either admit your project doesn't have conventions, in which case, don't nit people who don't follow whatever convention exists in your head but isn't documented, or document the project conventions. You cannot have your cake and eat it too. That "one guy updating the text" is at least explicitly documenting expectations. Per your "local consistency" comment, if "giraffe" is called "gorilla" in every other file (aka "global consistency"), it sounds like you're just setting up more work for some developer to take care of. Consider leaving a comment and start using the globally consistent name, rather than propagating more inconsistency (technical debt). Perhaps more aptly put, what you call "local consistency" sounds like "global inconsistency" to me.
- tharkun__ 5y ago
  Oh I absolutely agree with that statement. If you have someone in your place that is actually just documenting what everyone is doing and what everyone is doing is consistent, that's awesome! More power to them. At my current place we do a lot through linters and automatic code formatting for example and we collectively agree on when and how to change the configs for that. Eliminates a whole class of "arguments" (X spaces vs. tabs anyone?) and it's relatively easy to "convert" new hires to it as well. They can either adapt to it, make a really good argument for changing the configs via a widely circulated PR or they aren't a cultural fit to us. My point is that this guy usually isn't. In the vast majority of places I've been or seen it's the other version of him. I.e. the equivalent of the guy at the regulars table that edits Wikipedia to prove his point in a discussion.