Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Formatting code should be unnecessary

maxleiter.com

Post reply on HN
Print view View original

251–260 of 484 posts

Re: Formatting code should be unnecessary

#251

Post by saagarjha »

account42 wrote: post #167
komali2 wrote: post #119

Earlier quoted context omitted.

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!

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.

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

Re: Formatting code should be unnecessary

#252

Post by worldsayshi »

automatoney wrote: post #50

I've never understood why people care so much about the linter settings. It's so obviously bikeshedding, just make a choice, run the linter automatically and be done with it. I'm too busy doing actual software engineering to care about where exactly everything goes - I promise after a week you'll just get used to whatever format your team lands on.

I agree. Linters are one of the more frustrating aspects of modern dev. It's of such little relevance and yet it takes up a sizeable portion of my time when I'm going for a merge. Many editors/language combinations don't give automatic linting out of the box and when they do I can bet that the rules they infer is different from what the CI pipeline infers.

Re: Formatting code should be unnecessary

#253

Post by saagarjha »

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…

This makes it really annoying to grep for log messages. I can't control what you do in your codebase but I will always argue against this the ones I work on.

Re: Formatting code should be unnecessary

#254

Post by onion2k »

einpoklum wrote: post #165
automatoney wrote: post #50

I've never understood why people care so much about the linter settings. It's so obviously bikeshedding, just make a choice, run the linter automatically and be done with it. I'm too busy doing actual software engineering to care about where exactly everything goes - I promise after a week you'll just get used to whatever format your team lands on.

If you ride a bike every day, bike sheds are rather important. If you write and edit and read and search code every day, code formatting is rather important.

Consistency is important because it helps you pattern match.

What the pattern is doesn't really matter.

Re: Formatting code should be unnecessary

#255

Post by sarchertech »

hananova wrote: post #234
socalgal2 wrote: post #152

Earlier quoted context omitted.

some settings have advantages. For example, trailing commas on tables [ 'apple', 'banana', 'orange', ] has an advantage over [ 'apple', 'banana', 'orange' ] Because adding a new line at the end of the table (1) requires editing 1 line, instead of 2 (2) makes the diffs in code review smaller and easier to read and review. So a bad choice makes my life harder. The same applies to local variable declarations. Sorted lis…

Meanwhile, I know and understand the reasons for trailing commas, but I find them incredibly ugly so I always strip them out.

Can’t strip them out if the compiler requires them.

Re: Formatting code should be unnecessary

#256

Post by rapind »

socalgal2 wrote: post #152
automatoney wrote: post #50

I've never understood why people care so much about the linter settings. It's so obviously bikeshedding, just make a choice, run the linter automatically and be done with it. I'm too busy doing actual software engineering to care about where exactly everything goes - I promise after a week you'll just get used to whatever format your team lands on.

some settings have advantages. For example, trailing commas on tables [ 'apple', 'banana', 'orange', ] has an advantage over [ 'apple', 'banana', 'orange' ] Because adding a new line at the end of the table (1) requires editing 1 line, instead of 2 (2) makes the diffs in code review smaller and easier to read and review. So a bad choice makes my life harder. The same applies to local variable declarations. Sorted lis…

Let this sink in though:

    [ 'apple'
    , 'banana'
    , 'orange'
    ]

Re: Formatting code should be unnecessary

#257

Post by xpe »

automatoney wrote: post #50

I've never understood why people care so much about the linter settings. It's so obviously bikeshedding, just make a choice, run the linter automatically and be done with it. I'm too busy doing actual software engineering to care about where exactly everything goes - I promise after a week you'll just get used to whatever format your team lands on.

I suggest rephrasing as a series of question:

1. Assuming at least one person who cares about linter settings isn't utterly confused or moronic, what are their self-described reasons why they care? People's work styles, brains, and even sensory perception differ in some important ways!

2. As freedom-loving developers [1] who want to make our own choices to help our own styles of work, why should we even have to care about "enforcing" one standard for something that isn't really necessary? This one-standard-per-project thing is a downstream result of a design decision upstream (storing source code as plain text).

3. How should we design languages going forward? This brings the conversation back to top-level post (which is why we're here -- to think about what languages could be, not to rehash tired old debates, after all): how can we take what we've learned and build better languages -- perhaps ones where the primary source of truth for source code is not plain text?

[1] Slightly tongue-in-cheek. It is one thing to want to have freedom to do our jobs well, it is another thing to turn this into advocacy an overarching system such as a political philosophy or various decentralized financial mechanisms and so on. Here, I'm merely referring to the "let me do my job in the way that actually works for my brain" sense.

Re: Formatting code should be unnecessary

#258

Post by DonHopkins »

someothherguyy wrote: post #143
elevation wrote: post #88

Earlier quoted context omitted.

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

Re: Formatting code should be unnecessary

#259

Post by IshKebab »

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

Yeah in theory people can do a better job than auto-formatters. In practice they absolutely do not, so that argument is moot.

Re: Formatting code should be unnecessary

#260

Post by xpe »

IshKebab wrote: post #259
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...

Yeah in theory people can do a better job than auto-formatters. In practice they absolutely do not, so that argument is moot.

> Yeah in theory people can do a better job than auto-formatters. In practice they absolutely do not, so that argument is moot.

Status quo fallacy alert. Arguments are not forever mired in a current state of affairs. People can learn and can build tools to help them do better.

This could change quickly; e.g. if Claude or GitHub or (Your Team) decide to prioritize how source code looks.

Post reply on HN