[arximboldi]

The post peaks with this example is this one:

  bool usersHairColorMatchesThisMonthsAdsColour = _user.hair == HairColour::Red;
  bool userFeetSizeFitsInShoe = _user.feetSize <= _requestedShoe.size;
  bool shoePriceFitsInUserBudget = _requestedShoe.price <= BudgetHelpers::Calculator(_user);

  bool shoeIsProbablyOkayForUser = usersHairColorMatchesThisMonthsAdsColour && userFeetSizeFitsInShoe && shoePriceFitsInUserBudget;

  if(shoeIsProbablyOkayForUser)

That they compare, with the "uglier":

  // this months ad campaign color is red 
  if(_user.hair == HairColor::Red && _user.feetSize <= _requestedShoe.size && _requestedShoe.price <= BudgetHelpers::Calculator(_user))   

I very much prefer the latter, I'm sorry (except it needs some new lines, of course). It performs better (that `BudgetHelper::Calculator` doesn't look very cheap ;) but crucially it is, to me personally, more "readable". First, I find a comment easier to read than a variable name, particularly when you use the not so readable dromedaryCaseToCrambleWordsInLongSentences. Thus, a variable adds no value when it's only used once (arguably, it adds more noise, since one has to go twice through the same text). And it is often debatable how a programmers poor translation of code into English adds any value: in fact, I find `_user.feetSize <= _requestedShoe.size` to be way more succint, precise and easier to parse than `userFeetSizeFitsInShoe`.

We really need to get over this school of thought that "the more wordy your variables the more readable" because it is simply not true. You don't have to go all the other way to the other end and write code using greek letters like in math. Meet somewhere in the middle, be aware of context and use the tools of the language (e.g. lexical scoping) to your power.

Unlike many of these bloggers want us to believe, you can't just boil "readability" down to some simple universal rules, and only experience makes the master. Taste, preference, purpose and context take a big part. As such, I find it useless to talk about "readable" code: readable for who? A law text, a maths paper, a school maths book, a user manual, a tutorial, a novel, a HN comment... they may all be written in English and with great skill in consideration for their "readability" by their target audiences, yet manifest completely different styles even when discussing the same topics.

For me, I like my code like I often enjoy most good writting: succint and precise. Wordy variables that add no value or abstraction are of little use to me.

[DangitBobby]

I find that people want to find a name for some condition or computed result so they can box away a concept and use it without thinking about it anymore. That's great when you're writing software and you have lots of time to consider and remember your names, but not always so great when you revisit software and now you need to actually _know what those things are and whether they are logically correct_. Sometimes even the best name isn't enough to describe what it is you have in your hands right now, and instead of seeing it where it's used, you have to go find where it was originally defined, and you potentially have to repeat this process for several named objects at once, keeping them all in your head. IMO you need a better reason to name something than the example from the article, or you actually sacrifice clarity and readability.

[alpaca128]

I tend to prefer the method of defining clearly named variables, but I agree those names are ridiculous.

    hair_col_matches && size_fits && in_budget

is less than half the length and imho more readable because it doesn't turn each variable intoNeedlesslyWordyCamelCaseSentences.

> you can't just boil "readability" down to some simple universal rules

Yes, in the end blindly following rules doesn't turn out as well as understanding why those best practices exist in the first place.