[bcrl]

In my experience, if your variable names are long enough to overflow an 80 column limit, you've probably already got a problem. Longer variable names have a cognitive load in and of themselves, which, to me, usually means someone didn't think about naming enough or is subject to too many levels of pointless indirection.

To me it is important to try to keep code concise so that it is easier to read. This applies to variable names as much as it does to how many lines a function is. The smaller the unit of functionality it is, the easier it is to understand in its entirety.

[flakes]

I care less about the length of the code, and more-so about the cognitive load. As the business logic grows, and the lines of code increases, the assignment of variables tend to get further and further away from their usage. What was once simple to read, now requires back-tracking as you read to double check exactly what they are.

Consider this contrived example:

    margin = (price - cost) / price

You can be reasonably sure what is being calculated, but it's hard to be exactly sure unless the surrounding context is very small. Having longer names allows you to keep more context for a line in isolation, meaning (personally) I require less backtracking while reading.

e.g. the above could be rewritten as the following, removing a lot of ambiguity:

    retail_margin = (retail_price - wholesale_cost) / retail_price

I find 80 character limits much too small in these cases. 100-120 characters is the sweet spot for me. I can still have 2 split panes of code on a single screen at once, and write more expressively without excessive linebreaks per statement.