Hacker News Reader

Comment by koboll | Hacker News Reader

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.

View on HN

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.

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!

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").

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.

That's a triple negative! (!, Not, Disabled).

Yes, `if (!FeatureEnabled){ ... }` would be clearer.

> 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”.)

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.

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.

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.

Reply on news.ycombinator.com