Live data from Hacker News

Formatting code should be unnecessary

maxleiter.com

61–70 of 484 posts

Re: Formatting code should be unnecessary

#61

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’ll go a step further.

I’ve never understood why people care so much about the linter. Just let people write code and don’t worry about the linter. I don’t need to fight a linter which makes my code worse when I could just write it in a way that doesn’t suck. I promise it’ll be fine. I’m too busy doing actual software engineering to care if code is not perfectly formatted to some arbitrary style specification.

I feel like style lingers are horseshoe theory. Use them enough and eventually you wrap back around to just living without them.

Re: Formatting code should be unnecessary

#62
post #56

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 generally agree, but max line length being so high you have to horizontally scroll while reading code is very detrimental to productivity.

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.

Re: Formatting code should be unnecessary

#63
post #3

You can't easily search / grep etc. an IR, unless you use some kind of reverse translator. Readable source files have their benefits in being simple in that sense.

> unless you use some kind of reverse translator

Would a few decades help in universally having such a translator in all the tools?

Re: Formatting code should be unnecessary

#64
post #56

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 generally agree, but max line length being so high you have to horizontally scroll while reading code is very detrimental to productivity.

every editor can wrap text these days. good ones will even indent the wrapped text properly

Re: Formatting code should be unnecessary

#65
post #64
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.

every editor can wrap text these days. good ones will even indent the wrapped text properly

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

Re: Formatting code should be unnecessary

#66

The tradeoff here is not being able to use a universal set of tooling to interact with source files. Anything but text makes grep, diff, sed, and version control less effective. You end up locked into specialized tools, formats, or IDE extensions, while the Unix philosophy thrives on composability with plain text. There's a scissor that cuts through the formatting debate: If initial space width was configurable in th…

If you’re going to store the source in a canonical format and unpack that to suit each developer… why should the canonical format just be regular source code? All the same tools can exist with a text backend, and you get grep/sed support for free too!

My grep may not work on your settings for the same code.

This becomes an issue with say CI where maybe I add a gate to check something with grep. But whose format do I assume? My local (that I used to test it locally) or the canonical (which means I need to switch local format to test it)?

Re: Formatting code should be unnecessary

#67
post #65
post #64

Earlier quoted context omitted.

every editor can wrap text these days. good ones will even indent the wrapped text properly

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

I prefer storing plain text and displaying locally preferred syntax, to a degree.

With some expressions, like lookup tables or bit strings, hand wrapping and careful white space use is the difference between “understandable and intuitive” and “completely meaningless”. In JS world, `// prettier-ignore` above such an expression preserves it but ideally there’s a more universal way to express this.

Re: Formatting code should be unnecessary

#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 preferably only one --obvious way to do it.'

Re: Formatting code should be unnecessary

#69

Earlier quoted context omitted.

That's why you grep for a syntactic structure, not undifferentiated text.

Which grep doesn't do and you need to either use a new different tool or more likely several for little real benefit

comby is fantastic, give it a shot. It’s saved me huge amounts of time.

Re: Formatting code should be unnecessary

#70
post #65
post #64

Earlier quoted context omitted.

every editor can wrap text these days. good ones will even indent the wrapped text properly

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

And the bikeshedding has begun...
Post reply on HN