4 ms·

Holy crap, is >gives cryptic names for variables, or at best not self-explanatory sure a big one. It's part of a category of small decisions that dramatically

by koboll 8y ago

Holy crap, is >gives cryptic names for variables, or at best not self-explanatory sure a big one. It's part of a category of small decisions that dramatically increase cognitive load when accumulated. Along with it: >Passing many arguments into functions with names that have no relevance to their role inside the function, so you constantly have to look up which argument maps to which function param >Needlessly reorganizing data structures or renaming variables so that it becomes more difficult to reason about the flow of data Naming things isn't just the hardest problem in programming, it's also the quickest way to piss off your peers if you're lazy about it.

vidanay 8y ago
A former primary developer of my code base had something wired backwards in his brain. The code is full of double negatives: if(!FeatureNotDisabled){ .... } It drives me absolutely bonkers!
- rabidrat 8y ago
  For me this often happens incrementally. Like they started with "if (FeatureNotDisabled)" and then locally refactored the code until it was "if (!FeatureNotDisabled)". The problem is that they then didn't go back for another pass before commit, and reverse the double-negative by changing the variable name and semantics. This could be due to laziness, ignorance (it works, what's the problem?), fear (it works now, let's not break it), or time mismanagement (it took long enough to get it working, no time to make everything "perfect").
  - vidanay 8y ago
    I could understand that evolution, but I have become convinced that this particular developer simply worked with negative logic in his brain. Even the configuration files will have: Feature1Disabled=False Feature2Disabled=True Feature3Disabled=False Instead of using feature flags to enable a feature, he used feature flags to disable features. He was very consistent and the logic is all correct, simply inverted.
- timw4mail 8y ago
  That's a triple negative! (!, Not, Disabled). Yes, `if (!FeatureEnabled){ ... }` would be clearer.
  - dragonwriter 8y ago
    > That's a triple negative! (!, Not, Disabled). It's only a double negative (“disabled” is affirmative, though the same sense can be communicated by the single negative “not enabled”.)
PascLeRasc 8y ago
My coworker used to be a solo developer and would make up recursive acronyms for every variable name, like: MSA: MSA subject analysis It's pretty hard to go through scripts older than a year and understand what's going on.
DigitalVerse 8y ago
Gah, naming! It feels like a sign of a lack of empathy to not at least give some semi-meaningful name to a variable. "x" is only acceptable if you're literally writing a function to perform algebra.
jboles 8y ago
Another one is giving insanely long names but only changing one little part, instead of taking advantage of the heirarchical nature of programming languages and coming up with a nice nested structure. Example: class TheRpcThing { object TheRpcThingHost object TheRpcThingHostTimer class TheRpcThingValidationException { object TheRpcThingHostValidationException object TheRpcThingHostValidationExceptionErrorMessage object TheRpcThingHostValidationExceptionErrorMessageFormatter } } The cognitive cost of reading a bunch of previously-unseen code, which has an accumulation (the perfect word for this kind of thing) of the above can be so frustrating.
- avinium 8y ago
  I actually use the number of capital letters in camel-cased variable/method names as a signal that the code might need refactoring. Generally, every capital letter indicates another hierarchical relationship from left-to-right. Usually these are implementation details that shouldn't be publicly exposed, or at least could be separated out/encapsulated better in a different object/function structure. Obviously it's a rule-of-thumb and there are exceptions, but I've found this works pretty well.

by koboll 8y ago

vidanay 8y ago

A former primary developer of my code base had something wired backwards in his brain. The code is full of double negatives: if(!FeatureNotDisabled){ .... } It drives me absolutely bonkers!

rabidrat 8y ago
For me this often happens incrementally. Like they started with "if (FeatureNotDisabled)" and then locally refactored the code until it was "if (!FeatureNotDisabled)". The problem is that they then didn't go back for another pass before commit, and reverse the double-negative by changing the variable name and semantics. This could be due to laziness, ignorance (it works, what's the problem?), fear (it works now, let's not break it), or time mismanagement (it took long enough to get it working, no time to make everything "perfect").
- vidanay 8y ago
  I could understand that evolution, but I have become convinced that this particular developer simply worked with negative logic in his brain. Even the configuration files will have: Feature1Disabled=False Feature2Disabled=True Feature3Disabled=False Instead of using feature flags to enable a feature, he used feature flags to disable features. He was very consistent and the logic is all correct, simply inverted.
timw4mail 8y ago
That's a triple negative! (!, Not, Disabled). Yes, `if (!FeatureEnabled){ ... }` would be clearer.
- dragonwriter 8y ago
  > That's a triple negative! (!, Not, Disabled). It's only a double negative (“disabled” is affirmative, though the same sense can be communicated by the single negative “not enabled”.)

PascLeRasc 8y ago

My coworker used to be a solo developer and would make up recursive acronyms for every variable name, like: MSA: MSA subject analysis It's pretty hard to go through scripts older than a year and understand what's going on.

DigitalVerse 8y ago

Gah, naming! It feels like a sign of a lack of empathy to not at least give some semi-meaningful name to a variable. "x" is only acceptable if you're literally writing a function to perform algebra.

jboles 8y ago

Another one is giving insanely long names but only changing one little part, instead of taking advantage of the heirarchical nature of programming languages and coming up with a nice nested structure. Example: class TheRpcThing { object TheRpcThingHost object TheRpcThingHostTimer class TheRpcThingValidationException { object TheRpcThingHostValidationException object TheRpcThingHostValidationExceptionErrorMessage object TheRpcThingHostValidationExceptionErrorMessageFormatter } } The cognitive cost of reading a bunch of previously-unseen code, which has an accumulation (the perfect word for this kind of thing) of the above can be so frustrating.

avinium 8y ago
I actually use the number of capital letters in camel-cased variable/method names as a signal that the code might need refactoring. Generally, every capital letter indicates another hierarchical relationship from left-to-right. Usually these are implementation details that shouldn't be publicly exposed, or at least could be separated out/encapsulated better in a different object/function structure. Obviously it's a rule-of-thumb and there are exceptions, but I've found this works pretty well.