3 ms·
> I used long variable names (on the basis that they helped readers understand what was going on), lots of whitespace (on the basis that it helped readers under
by karmakaze 5y ago
> I used long variable names (on the basis that they helped readers understand what was going on), lots of whitespace (on the basis that it helped readers understand what parts of a file were most related to each other), and wasn't afraid to duplicate code with minor variations (on the basis that each variation was then clearer to read).
I always contend that we should strive for understanding of the whole over making each statement as clear as possible. Local variable names should be short. Variable names that span larger contexts should be as long as necessary to disambiguate it and provide context. I find less senior devs focus on the zoomed in context rather than the larger one. I say that whitespace, especially vertical space usage needs to justify itself. Allow as much context to fit on the screen as long as density doesn't go too far into being unreadable. The standard line length limit convention is a good rule of thumb.
> I now believe the reason is fairly simple: in essence, OpenBSD's style squeezes more code onto the screen.
- yobbo 5y ago> Local variable names should be short It depends on how complex the functions/algorithms are, and what mental references can be assumed. Local variable names help explain how/what the function does. Function names and context might only be enough to explain the intended output.
- karmakaze 5y agoYes it depends on context, but you should be able to lean on the existing context to shorten local names. E.g. a lambda param dealing with a collection of xxx_yyy_zzz_items can just be called item or xyz_item (if there are other item-like things nearby). Only lengthen the method body or take up vertical space with long names if it adds more than it detracts from reading and understanding the whole.