3 ms·
I'd argue that the real issue here is slavish adherence to the style guide without stopping to consider what's readable. Alignment, in my opinion, is a readabil
by swift 9y ago
I'd argue that the real issue here is slavish adherence to the style guide without stopping to consider what's readable. Alignment, in my opinion, is a readability win in general. (We may have to agree to disagree here.) But when column alignment results in unreadable code like the examples you gave, you shouldn't use it. It's that simple. That doesn't mean that column alignment as a general principle is bad; you should optimize for the common case, and be willing to handle exceptional cases differently.
A similar issue is formatting for 80 columns. In general, this is a good idea, because long lines can be hard to read and hard to edit. That doesn't mean that you should contort the formatting of your code in bizarre ways to avoid an 85 character line.
- concede_pluto 9y agoConstructionItem::TableColumnFragment is 37 characters[1]. A style that permits huge identifiers like that should allow more than 2.2 identifiers per line and should not allow alignment that requires the eye to jump over that much whitespace and land on the correct line. [1] not columns. Bitmapped displays don't have columns, and it's objectively measurable that humans read fixed-pitch fonts more slowly.