Only rarely is the vertical alignment useful because mostly code isn't read vertically. Used in moderation, the reverse Christmas tree style used in the Linux kernel can be as good for readability (sorted longest to shortest). For some constant structures a reordering of fields to put the variable length element at the end of the line removes the need for padding space (like in the output of `ls -l` where filenames come last).
A common indentation style for continuation lines is to align with the start of arguments to the function. I've never seen the sense of this variable amount where indentation after a while is much more than after an if. Double the normal indentation for continuation works well in languages where line continuation isn't otherwise distinct from normal blocks.
I recall reading something about "tab stops" that solved this problem, but I don't think there are any mainstream implementations of it.
But a major flaw is that it only works when your cell has less than 8 characters. Or it will go to the wrong stop. Which isn't that common today.
Because why insist in short names and 80 width character limit? Almost everyone have a screen that can fit hundreds of characters per line today.
Yet, books don't work that way, even though we have the technology. Long lines aren't readable. There's a reason newspapers have columns.
See eg https://baymard.com/blog/line-length-readability and https://en.wikipedia.org/wiki/Line_length
You can keep to mostly text, but give the editor more leeway in how to lay it out and make the code's structure more visible.
Some really simple options, that you might not even recognise as going beyond text: folding of block and go-to-definition.
> Never attempt to line up text by using spaces. The only exception is if you are using a monospaced font. But in word processing applications, there are appropriate tools available for lining up text, like tables[1] and tab stops[2].
[1]: https://practicaltypography.com/tables.html [2]: https://practicaltypography.com/tabs-and-tab-stops.html
Seeing the same shape repeatedly tells me a lot about what is happening. It also helps highlight changes between two lines that are very similar.
I agree and I think that is the same thing as code-readability. Code-readability means you can easily understand the code.
I personally try to abide by what I call "hedge" formatting convention, the punctuation forms a vertical hedge which then shows the structure of your code clearly:
[ a
, b
, c
]
Moving my eyes down to look for the closing bracket is easier (to me) than moving my eyes from left to right to spot it somewhere on the right side of the page.
Note how above ALL the punctuation is in the same (first) column, Having read that it then becomes easier to read what is on the rest of the columns.
In general it helps when things that are the same, or have the same purpose, on each line are in the same horizontal position. It is is then easier to see what is different about each line, since it is easy to see what is the same.
But as long as everything is written under the same guidelines, I will accept it.
Your explanation makes good sense. I guess I just wasn't seeing the forest for the trees. ;)
[
, a
, b
, c
]
[
- a
- b
- c
] [
a,
b,
c,
][ a
, b
, c
]
because, I think this is as 'uniform" as it gets. All syntactic separators are in the first column. Thus they are all uniformly in the same column. Line 1 has the syntactic separator '[' which means start-of-array. Lines 2 and 3 have ',' as the syntactic separator which means element-separator. And line 4 has the final syntactic marker which means "end of Array".
All elements of the array start at the same column, uniformly. And all syntactic separators are in the same column also uniformly.
abc = 1
d = 2
Things like
func(arg1,
arg2,
arg3)
1) my text editor (emacs) aligns those lines for me (probably any programmer's editor does) so at least I don't have to do precision work
2) I ended up writing code like
func(
arg1,
arg2,
arg3
)
If the arguments are few (two or three) and there are no named arguments I don't break them on multiple lines.
The result is that no coworker ever complained about my code.
Languages with a formatter (Elixir) solve the problem once and for all and align well with both kinds of fonts.
if (condition...
&& condition...
&& condition...
) { if ((
condition1
) && (
condition2
) && (
...
)) {At the same time I get your point and also the argument about Git diffs (which also should be readable). So maybe the ideal situation would be a separation of code and its formatting, so that we have more options than tabs and also no need for crutches like tabs. Like a better, more flexible code formatter that lets you display and edit code in the editor using one style but then saves the file in a standard format that's consistent across the whole project.
func(arg1, arg2, arg3)
Once you’re splitting it across lines I don’t think that is a desirable attribute. Better to use a format that suits multiple lines than attempt to match as closely as possible to a format intended for one line. Like those “flying cars” that try to look like the “canonical” car.
From my perspective this is a UI problem (though not a serious one).
Seems wrongheaded to me; that's the same reason Elm wanted you to write arrays like this:
[item1
,item2
,item3
,item4
]
Who cares? It's not hard to understand what's happening in a diff that makes this kind of change. You want the code to be easy to read, not easy to diff.
You could also easily base your diff algorithm on a lexer for the language rather than a lexer for ascii, in which case changing the amount of whitespace would register as "not a change".
[
item1,
item2,
item3,
item4,
] [ item1
, item2
, item3
, item4
] (item1
item2
item3
item4)
[ a [ a [ a
, b , b / , b
, c --> , c / , c
, d , d / , dd
] , e ]
]
[ a
, b
, c
, dd
, e
]
[ a, [ a, [ a,
b, b, / b,
c, --> c, / c,
d d, / dd
] e ]
]
However, if you were to require a trailing comma after the final element you wouldn't have this problem.
Example doesn't have a trailing comma. If it did, it would act the same as the leading comma.
But also the leading comma just moves the problem to the beginning of the list instead of the end. Trailing comma with the opening [ on its own line wouldn't have that problem anywhere.
I've encountered this sentiment more than a few times and I find it hard to accept. It totally makes sense to align repetitive stuff in columns. That's why people use tables in other contexts, and code should be no different. This alignment makes clear any deviations from the norm and lets you "see" the structure of the data easily.
It doesn't matter for minor stuff and, usually, the code linter/formatter is "good enough"-- but sometimes, you REALLY want to have columnar layout!
> Sometimes programmers rely on the monospaced grid to create a second column of values or comments on the right side of the page. It’s true, these secondary columns won’t align in a proportionally spaced font. But why are we making these columns in the first place? Even in a monospaced font they can be finnicky and hard to maintain.
> In virtually every other form of typography, the responsibility of alignment is given to the typesetting application, not the font. If source code editors can highlight syntax, they could also interpret tabs and syntax to create true, adjustable columns of text.
You want 8-space tabs and braces on their own lines? Cool. We'll save the file with all the formatting defaults, but run a formatter tuned to your preferences before displaying.
Same reason I don't like using those things where <= turns into ≤ in your editor but it's written to disk as <=.
If the code doesn't parse, save it as-is. If it does, run the formatter with the defaults before saving. When opening, run the formatter with the user's preferences before displaying.
Gets you the benefits of a formatter, with the freedom to control your environment to your tastes. You can already pick your editor, font, and color theme. You ought to be able to pick your formatter settings too.
With monospaced fonts, the columns will be guaranteed to line up with the correct number of spaces, which your IDE will determine anyway.
I might give these fonts a try, although I've been used to Menlo for a long time.
When I attended university in the mid-1990s, and again in mid-2000s, we were required to hand in papers using monospace font, black ink, with a specific point size and margins.
It kept everything looking consistent with typewriters (which some people still used through the 1990s), but also kept people from using distracting or illegible fonts, or trying to work around page or word limits by using different fonts.
The main use of this in practice is using line-char-count limits as a proxy to lint for code readability, but it can also be beneficial in other contexts.
> You might be thinking, “Okay, but now characters won’t line up neatly.”
Then again, I don't see values lined up much these days:
and if you only care about leading whitespace (that is, the whitespace before a character appears on the line), maybe it doesn't matter how your font is spaced.I suspect numbers in these almost-mono fonts are monospaced, so numerical values should still have nice rhythm too.