Formatting code should be unnecessary

Post by lsaferite » Mon, Sep 08, 2025, 11:57 PM UTC

TheDong wrote: post #137

hackerbrother wrote: post #23

Along these lines, Go eliminates many formatting decisions at the syntax level. E.g., func main() { fmt.Println("HELLOWORLD") } is not just non-standard formatting, but illegal Go syntax. Similarly, extra parentheses around if clauses are not allowed.

> Similarly, extra parentheses around if clauses are not allowed. However 'if (x) == (1) {}' is totally fine with the formatter. As is an assignment of '(x) = (y)'. It's actively annoying too because like, extra parenthesis often have important meaning. For example, consider the following code: if (x.isFoo() || x.isBar()) /* && x.isBaz() */ { /* code */ } In that case, the code is obviously temporarily commented out,…

Post by forrestthewoods » Tue, Sep 09, 2025, 3:21 AM UTC

layer8 wrote: post #222

forrestthewoods wrote: post #62

Earlier quoted context omitted.

Define high? I think 120 is pretty reasonable. Maybe even as high as 140. Log statements however I think have an effectively unbounded length. Nothing I hate more than a stupid linter turning a sprinkling of logs into 7 line monsters. cargo fmt is especially bad about this. It’s so bad.

100 is the sweet spot, IMO. I like splitting long text as in log statements into appropriate source lines, just like you would a Markdown paragraph. As in: logger.info( "I like splitting long text as in log statements " + "into ” + suitablelAdjective + " source lines, " + "just like you would a Markdown paragraph. " + "As in: " + quine); I agree that many formatters are bad about this, like introducing an indent for…

Post by DemocracyFTW2 » Tue, Sep 09, 2025, 5:05 AM UTC

DonHopkins wrote: post #258

someothherguyy wrote: post #143

Earlier quoted context omitted.

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

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…

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

Post by DemocracyFTW2 » Tue, Sep 09, 2025, 5:11 AM UTC

bogomog wrote: post #452

giveita wrote: post #65

Earlier quoted context omitted.

Thats a slippery slope towards storing semantics and displaying locally preferred syntax ;)

That's why Python should have gone all-in on significant spaces: tabs for blocks, spaces after tabs for line continuation

Post by VBprogrammer » Tue, Sep 09, 2025, 6:28 AM UTC

DemocracyFTW2 wrote: post #464

VBprogrammer wrote: post #104

Earlier quoted context omitted.

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.

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