6 ms·
I long ago concluded that trying to line stuff up in columns like this in code is a mistake. It often results in realignment of blocks for small changes so what
by opk 4y ago
I long ago concluded that trying to line stuff up in columns like this in code is a mistake. It often results in realignment of blocks for small changes so what should be a small diff in the git history ends up being big.
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.
- andai 4y agoThis just seems like a limitation of the technology. When you change the width of one column, the whole table should realign, without any changes to those parts of the file (it's just about how it's displayed). I recall reading something about "tab stops" that solved this problem, but I don't think there are any mainstream implementations of it.
- archseer 4y agoI think you mean elastic tab stops https://nickgravgaard.com/elastic-tabstops/ https://nickgravgaard.com/elastic-tabstops/
- operator-name 4y agoElastic tabstops actually mentions the input font in its "see also" section!
- mmis1000 4y agotab stops is still available in terminals. Tab in terminal move the cursor to next x*8(depends on setting) position independent of what character you input before. 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.
- eru 4y ago> 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 https://baymard.com/blog/line-length-readability and https://en.wikipedia.org/wiki/Line_length https://en.wikipedia.org/wiki/Line_length
- mmis1000 4y agoEven without the line length problem, 8 character is unlikely to fit in a meaningful word. And because you need a space between each column, you actually only have 7. And nobody using random abbreviations now.
- throwaway290 4y agoWriting programs by manipulating text is the actual limitation of the technology here, alignment is just a minor detail by comparison.
- throw827474737 4y agoThat's often heard, but what's the alternative? So far every other alternative has been more limiting, not?
- eru 4y agoThere are some sane alternatives. 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.
- throwaway290 4y agoAST, GUI... The technology is not there yet.
- Rafert 4y agoTab stops are called out in the footnotes: > 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 https://practicaltypography.com/tables.html [2]: https://practicaltypography.com/tabs-and-tab-stops.html https://practicaltypography.com/tabs-and-tab-stops.html
- rocqua 4y agoThe value of alignment (at least for me) is not in making the text of the code more readable. Instead, the value is communicating the structure of the code. 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.
- galaxyLogic 4y ago> the value is communicating the structure of the code. 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.
- hoseja 4y agoYes, this is what I've also gravitated towards.
- the_sleaze9 4y agoThanks, I hate it. But as long as everything is written under the same guidelines, I will accept it.
- q7xvh97o2pDhNrh 4y agoHuh, I've always wondered about this style of code formatting and never fully understood why people did it. Your explanation makes good sense. I guess I just wasn't seeing the forest for the trees. ;)
- layer8 4y ago
- ako 4y agoI stopped manually formatting code long ago, just accept what the code formatter tool decides is good enough. Saves a lot of time.
- sverhagen 4y agoIn circumstances, and depending on configuration, the code formatter tool may still aim for alignment, such as assignment operators on subsequent lines. Whether you like that or not, for me the question still stands: how does that jive with "almost monospaced".
- pmontra 4y agoI've been using proportional fonts in programming for about ten years. I stopped doing things like abc = 1 d = 2 which add very little readability value IMHO. Things like func(arg1, arg2, arg3) usually don't align well because func( has a different width than the five spaces in the lines below. However 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 ) especially with named arguments (arg=value). That aligns even with proportional fonts and all arguments immediately stand out. 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.
- thaumasiotes 4y ago> I long ago concluded that trying to line stuff up in columns like this in code is a mistake. It often results in realignment of blocks for small changes so what should be a small diff in the git history ends up being big. Seems wrongheaded to me; that's the same reason Elm wanted you to write arrays like this: [item1 ,item2 ,item3 ,item4 ] instead of a sane way. It means adding or removing an element only changes one line in the diff! 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".
- mikojan 4y agoThis looks bad. Haskell is much better: [ item1 , item2 , item3 , item4 ]
- thaumasiotes 4y agoCompare lisp: (item1 item2 item3 item4) ;p
- madsohm 4y agoMany languages also support a comma after the last item, meaning you can still have one line diffs and have a sane reading structure: [ item1, item2, item3, item4, ]
- vore 4y agoLeading comma is better at resolving textual 3-way merges, e.g.: [ a [ a [ a , b , b / , b , c --> , c / , c , d , d / , dd ] , e ] ] Your usual 3 way merge algorithm will correctly deduce: [ a , b , c , dd , e ] Contrast this with trailing comma: [ a, [ a, [ a, b, b, / b, c, --> c, / c, d d, / dd ] e ] ] You now have a merge conflict between "d," and "dd". However, if you were to require a trailing comma after the final element you wouldn't have this problem.
- hnbad 4y agoArguably another problem with lining up code like in the example is that it emphasizes the relationship between the keys and between the values rather than between each key-value pair. This may be useful when writing out matrices but in the example of an object/dict with key-value pairs it seems a distraction more than an affordance.
- crispyambulance 4y ago> ... trying to line stuff up in columns like this in code is a mistake. 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!