6 ms·
Formatters eliminating long lines is a pet peeve of mine. About once every other project, some portion of the source benefits from source code being arranged i
by elevation 1y ago
Formatters eliminating long lines is a pet peeve of mine.
About once every other project, some portion of the source benefits from source code being arranged in a tabular format. Long lines which are juxtaposed help make dissimilar values stand out. The following table is not unlike code I have written:
setup_spi(&adc, mode=SPI_01, rate=15, cs_control=CS_MUXED, cs=0x01);
setup_spi(&eeprom, mode=SPI_10, rate=13, cs_control=CS_MUXED, cs=0x02);
setup_spi(&mram, mode=SPI_10, rate=50, cs_control=CS_DIRECT, cs=0x08);
Even if we add 4-5 more operational parameters, I find this arrangement much more readable than the short-line equivalent:
setup_spi(&adc,
mode=SPI_01,
rate=15,
cs_control=CS_MUXED,
cs=0x01);
setup_spi(&eeprom,
mode=SPI_10,
rate=13,
cs_control=CS_MUXED,
cs=0x02);
setup_spi(&mram,
mode=SPI_10,
rate=50,
cs_control=CS_DIRECT,
cs=0x08);
Or worse, the formatter may keep the long lines but normalize the spaces, ruining the tabular alignment:
setup_spi(&adc, mode=SPI_01, rate=15, cs_control=CS_MUXED, cs=0x01);
setup_spi(&som_eeprom, mode=SPI_10, rate=13, cs_control=CS_MUXED, cs=0x02);
setup_spi(&mram, mode=SPI_10, rate=50, cs_control=CS_DIRECT, cs=0x08);
Sometimes a neat, human-maintained block of 200 character lines brings order to chaos, even if you have to scroll a little.
- lambdaba 1y agoI agree, I'm very much against any line length constraint, it's arbitrary and word wrapping exists.
- IlikeKitties 1y agoI'm suprised. I find the short-line version to be much better.
- growse 1y ago//nolint
- bloak 1y ago/* clang-format off */
- VBprogrammer 1y agoThose kind of tables improve readability right until someone hits a length constraint and had to either touch every line in order to fix the alignment, causing weird conflicts in VCS, or ignore the alignment and it's slow decay into a mess begins.
- Cthulhu_ 1y agoIt's not an either/or though. Tables are readable and this looks very much like tabular data. Length constraints should not be fixed if you have code like this, and it won't be "a slow decay into a mess" if escaping the line length rules is limited to data tables like these.
- VBprogrammer 1y agoBy length constraint I meant that one of the fields grows longer than originally planned rather than bypassing the linter.
- DemocracyFTW2 1y agoso you're basically saying "look this is neat and I like it, but since we cannot prevent some future chap come along and make a mess of it, let's stop this nonsense, now, and throw our hands up in the air—thoughts and prayers is what I say!"?
- VBprogrammer 1y agoAt best I'd say it's ok to use it sparingly, in places where it really does make an improvement in readability. I've seen people use it just to align the right hand side of a list of assignments, even when there is no tabular nature to what they are assigning.
- a_e_k 1y agoYes, so much this! I've often wished that formatters had some threshold for similarity between adjacent lines. If some X% of the characters on the line match the character right above, then it might be tabular and it could do something to maintain the tabular layout. Bonus points for it's able to do something like diff the adjacent lines to detect table-like layouts and figure out if something nudged a field or two out of alignment and then insert spaces to fix the table layout.
- Cthulhu_ 1y agoI believe some formatters have an option where you can specify a "do not reformat" block (or override formatting settings) via specific comments. As an exception, I'm okay with that. Most code (but I'm thinking business applications, not kernel drivers) benefits from default code formatting rules though. And sometimes, if the code doesn't look good after automatic formatting, the code itself needs to be fixed. I'm specifically thinking about e.g. long or nested ternary statements; as soon as the auto formatter spreads it over multiple lines, you should probably refactor it.
- a_e_k 1y agoI'm used to things like `// clang-format off` and on pairs to bracket such blocks, and adding empty trailing `//` comments to prevent re-flowing, and I use them when I must. This was more about lamenting the need for such things. Clang-format can already somewhat tabularize code by aligning equals signs in consecutive cases. I was just wishing it had an option to detect and align other kinds of code to make or keep it more table like. (Destroying table-like structuring being the main places I tend to disagree with its formatting.)
- komali2 1y agoDevs have different pixel count screens. Your table wrapped for me. The short line equivalent looks best on my screen. Thus 80 or perhaps 120 char line lengths!
- account42 1y agoSo fix your setup? Why should others with wider screens leave space on their screen empty for your sake? Especially 80 characters is a ridiculously low limit that encourages people to name their variables and functions some abbreviated shit like mbstowcs instead of something more descriptive.
- komali2 1y agoMy main machine is an ultrawide, but I usually have multiple files open, and text reads best top-down so I stack files side-by-side. If someone has like, a 240 character long line, that is annoying. My editor will soft wrap and indicate this in the fringe of course but it's still a little obnoxious. 80 is probably too low these days but it's nice for git commit header length at least.
- genericspammer 1y agoDo you guys never read code as side by side diffs in the browser?
- komali2 1y agoNever mind in a browser, this is how I review a ton of code, either in magit or lazygit or in multiple terminals.
- delusional 1y ago> So fix your setup? Why should others with wider screens leave space on their screen empty for your sake? What a terrible attitude to have when working with other people. "Oh, I'm the only one who writes Python? Fix your setup. why should I, who know python, not write it for your sake?" "Oh, I'm the only one who speaks German? Fix your setup. Why should I, who know German, not speak it for your sake?" How about doing it because your colleagues, who you presumably like collaborating with to reach a goal, asks you to?
- someothherguyy 1y agosetup_spi( &adc, mode=SPI_01, rate=15, cs_control=CS_MUXED, cs=0x01 ); setup_spi( &eeprom, mode=SPI_10, rate=13, cs_control=CS_MUXED, cs=0x02 ); setup_spi( &mram, mode=SPI_10, rate=50, cs_control=CS_DIRECT, cs=0x08 ); ftfy
- Marazan 1y agoThat is harder to read than the long line version. However, it is the formatting I adopt when forced to bow down to line length formatters.
- someothherguyy 1y agoto you, to me, it reads nicely, and thus the issue -- editors should have built in formatters that don't actually edit source code, but offer a view
- thaumasiotes 1y agoTo me, that reads fine, but it has lost the property elevation wanted, which was that it's easy to compare the values assigned to any particular parameter across multiple calls. In your version you can only read one call at a time.
- lenkite 1y agoErr..I find the short-line version easier to read. Esp if you need to horizontally scroll. This is why a Big Dictator should just make a standard. Everyone who doesn't like the standard approach just gets used to it.
- DonHopkins 1y agoThis is good, and objectively better than letting the random unbounded length of the function name define and inflate and randomize the indentation. It also makes it easier to use long descriptive function names without fucking up the indentation. setup_spi(&adc, mode=SPI_01, rate=15, cs_control=CS_MUXED, cs=0x01 ); setup_spoo(&adc, mode=SPI_01, rate=15, cs_control=CS_MUXED, cs=0x01 ); setup_s(&adc, mode=SPI_01, rate=15, cs_control=CS_MUXED, cs=0x01 ); validate_and_register_spi_spoo_s(&adc, mode=SPI_01, rate=15, cs_control=CS_MUXED, cs=0x01 );
- sn0wleppard 1y agoThe worst is when you have lines in a similar pattern across your formatter's line length boundary and you end up with setup_spi(&adc, mode=SPI_01, rate=15, cs_control=CS_MUXED, cs=0x01); setup_spi(&eeprom, mode=SPI_10, rate=13, cs_control=CS_MUXED, cs=0x02); setup_spi(&mram, mode=SPI_10, rate=50, cs_control=CS_DIRECT, cs=0x08);
- crazygringo 1y agoI think with the Black formatter you can force the multiline version by adding a trailing comma to the arguments. The pain point you describe is real, which is why that was intentionally added as a feature. Of course it requires a language that allows trailing commas, and a formatter that uses that convention.
- dvdkon 1y agoA similar tip: As far as I can tell, clang-format doesn't reflow across comments, so to force a linebreak you can add a // end-of-line comment.
- bryanrasmussen 1y agoPeople have already outlined all the reasons why the long line might be less than optimal, but I will note that really you are using formatting to do styling. In a post-modern editor (by which I mean any modern editor that takes this kind of thing into consideration which I don't think any do yet) it should be possible for the editor to determine similarity between lines and achieve a tabular layout, perhaps also with styling for dissimilar values in cases where the table has a higher degree of similarity than the one above. Perhaps also with collapsing of tables with some indicator that what is collapsed is not just a sub-tree but a table.
- account42 1y agoAnother issue with fixed line lengths is that it requires tab stops to have a defined width instead of everyone being able to choose their desired indentation level in their editor config.
- DonHopkins 1y agoAnother issue with everyone being able to choose their desired indentation level in their editor config is unbounded line length.
- rerdavies 1y agoI think you have that backward. Allowing everyone to choose their desired indentation in their editor config is the issue. That's insane!
- jaimebuelta 1y agoThe first line should be readable enough, but in case it's longer than that, I way prefer the style of setup_spi(&adc, mode=SPI_01, rate=15, cs_control=CS_MUXED, cs=0x01); setup_spi(&eeprom, mode=SPI_10, rate=13, cs_control=CS_MUXED, cs=0x02); setup_spi(&mram, mode=SPI_10, rate=50, cs_control=CS_DIRECT, cs=0x08); of there the short-line alternative presented. I like short lines in general, as having a bunch of short lines (which tend to be the norm in code) and suddenly a very long line is terrible for readability. But all has exemptions. It's also very dependent on the programming language.
- vbezhenar 1y agoIt is an obvious example where automatic formatter fails. But are there more examples? May be it's not high price to pay. I'm using either second or third approach for my code and I never had much issues. Yes, first example is pretty, but it's not a huge deal for me.
- crazygringo 1y agoI get what you're saying, and used to think that way, but changed my mind because: 1) Horizontal scrolling sucks 2) Changing values easily requires manually realigning all the other rows, which is not productive developer time 3) When you make a change to one small value, git shows the whole line changing And I ultimately concluded code files are not the place for aligned tabular data. If the data is small enough it belongs in a code file rather than a CSV you import then great, but bothering with alignment just isn't worth it. Just stick to the short-line equivalent. It's the easiest to edit and maintain, which is ultimately what matters most.
- paddy_m 1y agoThis comes up in testing a lot. I want testing data included in test source files to look tabular. I want it to be indented such that I can spot order of magnitude differences.