Formatting code should be unnecessary

Post by psychoslave » Mon, Sep 08, 2025, 7:21 AM UTC

Joker_vD wrote: post #110

skinner927 wrote: post #72

Earlier quoted context omitted.

I still prefer 80. I won’t (publicly) scoff at 100 though. IMO 120 is reasonable for HTML and Java, but that’s about it. Sent from my 49” G9 Ultrawide.

Give a try to 132 mode, maybe? It was the standard paper width for printouts since, well, forever.

Post by someothherguyy » Mon, Sep 08, 2025, 7:27 AM UTC

elevation wrote: post #88

jupp0r wrote: post #56

Earlier quoted context omitted.

I generally agree, but max line length being so high you have to horizontally scroll while reading code is very detrimental to productivity.

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_co…

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

Post by benrutter » Mon, Sep 08, 2025, 7:29 AM UTC

TheAlchemist wrote: post #68

I like that. We should have something like this for python. Black is great, but maybe it's just me since it aligns with how I like the code formatted. Would there be any downsides for python (or git ?) to define a standard way of formatting to save a valid file, and all the formatting necessary to read a file happens in the IDE showing the file ? That would very much fit with python ethos 'There should be one-- and p…

Post by yccs27 » Mon, Sep 08, 2025, 7:30 AM UTC

pwdisswordfishz wrote: post #47

davetron5000 wrote: post #25

There’s also a typography element to formatting source code. The notion that all code formatting is mere personal preference isn’t true. Formatting code a certain way can help to communicate meaning and structure. This is lost when the minimal tokens are serialized and re-constituted using an automated tool. https://naildrivin5.com/blog/2013/05/17/source-code-typograp...

> A C argument declaration is made up of modifiers (register, const), a data type (char *), and a name (from). Now explain a declaration like "char *argv[]"... > We’ve also re-set the data type such that there is no space between char and * - the data type of both of these variables is “pointer to char”, so it makes more sense to put the space before the argument name, not in the middle the data type’s name (update:…

Post by sn0wleppard » Mon, Sep 08, 2025, 7:31 AM UTC

elevation wrote: post #88

jupp0r wrote: post #56

Earlier quoted context omitted.

I generally agree, but max line length being so high you have to horizontally scroll while reading code is very detrimental to productivity.

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_co…

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