[elevation]

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.

[sn0wleppard]

The 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]

I 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]

A 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.

[a_e_k]

Yes, 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_]

I 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]

I'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.)

[crazygringo]

I 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]

This 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.

[VBprogrammer]

Those 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_]

It'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]

By length constraint I meant that one of the fields grows longer than originally planned rather than bypassing the linter.

[DemocracyFTW2]

so 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]

At 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.

[lambdaba]

I agree, I'm very much against any line length constraint, it's arbitrary and word wrapping exists.

[jaimebuelta]

The 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.

[bryanrasmussen]

People 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.

[vbezhenar]

It 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.

[account42]

Another 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.

[rerdavies]

I think you have that backward. Allowing everyone to choose their desired indentation in their editor config is the issue. That's insane!

[DonHopkins]

Another issue with everyone being able to choose their desired indentation level in their editor config is unbounded line length.

[growse]

//nolint

[bloak]

/* clang-format off */

[someothherguyy]

  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
  );

ftfy

[DonHopkins]

This 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
  );

[DemocracyFTW2]

Here, fixed it for you:

    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 );

[Marazan]

That 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.

[lenkite]

Err..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.

[someothherguyy]

to 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]

To 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.

[IlikeKitties]

I'm suprised. I find the short-line version to be much better.

[komali2]

Devs 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]

So 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]

My 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]

Do you guys never read code as side by side diffs in the browser?

[komali2]

Never mind in a browser, this is how I review a ton of code, either in magit or lazygit or in multiple terminals.

[delusional]

> 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?

[balamatom]

What do you do about the "oh, I'm the only one who cares about [???]? should I just fucking kill myself then?" Many such cases.

>How about doing it because your colleagues, who you presumably like collaborating with to reach a goal, asks you to?

If a someone wants me to do a certain thing in a certain way, they simply have to state it in terms of:

- some benefit they want to achieve

- some drawback they want to avoid

- as little as an acknowledged unexamined preference like "hey I personally feel more comfortable with approach X, how bout we try that instead"

I'm happy to learn from their perspective, and gladly go out of my way to accomodate them. Sometimes even against my better judgment, but hell, I still prefer to err on the side of being considerate. Just like you say, I like to work with people in terms of a shared goal, and just like you do, in every scenario I prefer to assume that's what's going on.

If, however, someone insists on certain approaches while never going deeper in their explanations than arbitrary non-falsifiable qualifiers such as "best practice", "modern", "clean", etc., then I know they haven't actually examined those choices that they now insist others should comply with. They're just parroting whatever version they imagine of industry-wide consensus describes their accidental comfort zone. And then boy do they hate my "make your setup assume less! it's the only way to be sure!". But no, I ain't reifying their meme instead of what I've seen work with my own two.

[delusional]

> If, however, someone insists on certain approaches while never going deeper in their explanations than arbitrary non-falsifiable qualifiers such as "best practice", "modern", "clean"

You're moving the goalposts of this discussion. The guy I was responding to said "fix your setup" to another person saying "Your table wrapped for me. The short line equivalent looks best on my screen." That's a stated preference based on a benefit he'd like to achieve.

We are not discussing "best practice" type arguments here.

[balamatom]

"Best practice" type arguments are the universal excuse for remaining inconsiderate of the fact that different people interact with code differently, but fair enough I guess

[account42]

Yes, I don't think we should discourage people from using Python or German just because you don't want to learn those particular languages either.

Working together with others should not mean having to limit everyone to the lowest common denominator, especially when there are better options for helping those with limitations that don't impact everyone else.

[DonHopkins]

So haul your wide monitor around with your laptop, you mean? No.

Just use descriptive variable names, and break your lines up logically and consistently. They are not mutually exclusive, and your code will be much easier for you and other people to read and edit and maintain, and git diffs will be much more succinct and precise.

[saagarjha]

I softwrap so I don't care about line length myself but I read code on a phone a lot so people who hardwrap at larger columns are a little more annoying

[maratc]

> Why should others with wider screens leave space on their screen empty for your sake?

Because "I" might be older or sight-impaired, and have "my" font at size 32, and it actually fills "my" (wider than yours) screen completely?

Would you advise me to "fix my eyes" too? I'd love to!

"Why should I accommodate others" is a terrible take.

[rerdavies]

I would advise you to buy one of these: https://www.dell.com/en-ca/shop/dell-ultrasharp-49-curved-us...

80-column line lengths is a pretty severe ask.

[brettermeier]

Living in the 80's XD