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

351–360 of 484 posts

Re: Formatting code should be unnecessary

#351

Post by gr__or »

zokier wrote: post #226
gr__or wrote: post #206

Earlier quoted context omitted.

Text surely is a hill, but I believe it's a local one, we got stuck on due to our short-sighted inability to go into a valley for a few miles until we find the (projectional) mountain. All of your examples work better for code with structural knowledge: - grep: symbol search (I use it about 100x as often as a text grep) or https://github.com/ast-grep/ast-grep - diff: https://semanticdiff.com (and others), i.e.: hide…

But as the tools you link demonstrate, having "text" as the on-disk format does not preclude AST based (or even smarter) tools. So there is little benefit in having non-text format. Ultimately it's all just bytes on disk

Even that is not without its cost. Most of these tools are written in different languages, which all have to maintain their own parsers, which have to keep up with language changes.

And there are abilities we lose completely by making text the source of truth, like a reliable version control for "this function moved to a new file".

Re: Formatting code should be unnecessary

#352

Post by zahlman »

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…

> Also, my OCD hates inconsistency

Mine hates trailing commas :)

More seriously, I don't like having lists like that in the code in the first place. I don't want multiple lines taken up for just constant values, and if it turns out to require maintenance then the data should be in a config file instead anyway.

Re: Formatting code should be unnecessary

#353

Post by gr__or »

jrochkind1 wrote: post #348
gr__or wrote: post #206

Earlier quoted context omitted.

Text surely is a hill, but I believe it's a local one, we got stuck on due to our short-sighted inability to go into a valley for a few miles until we find the (projectional) mountain. All of your examples work better for code with structural knowledge: - grep: symbol search (I use it about 100x as often as a text grep) or https://github.com/ast-grep/ast-grep - diff: https://semanticdiff.com (and others), i.e.: hide…

So there was an era, as the OP says, where your arguments were popular and believed and it was understood that things would move in this direction. And yet it didn't, it reversed. I think the fact that "plain text for all source files" actually won in the actual ecosystem wasn't just because too many developers had the wrong idea/short-sightedness -- because in fact most influential people wanted and believed in what…

For me, that's what "short-sighted inability" means. The business ecosystem we have does not have the attention span for this kind of project. What we need is individuals grouping together against the gradient of incentives (which is hard indeed).

Re: Formatting code should be unnecessary

#355

Post by parthdesai »

austin-cheney wrote: post #271
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…

Yes, everyone has personal opinions about code vanity. When this becomes a holy war I really start to question the maturity of people on the project. I find that people worry about trivial nonsense to mask their inability to address more valid concerns. All that really matters is consistency. Let a team make some decisions and then just move forward.

It's one of my pet peeves when some senior engineers are bothered more by these coding semantics in a PR when there are bigger data model/code architectural issues, and don't call that out.

Re: Formatting code should be unnecessary

#356

Post by carlosjobim »

mindwok wrote: post #300
carlosjobim wrote: post #292

Earlier quoted context omitted.

I see no reason to accommodate to worthless programmers who aren't able to read or format the code that's sent to them. They can lint it themselves if they want.

It's not about accomodating people, it's about consistency in codebases when many people with different preferences or styles are working on it. You just eliminate the cognitive overhead so people can develop intuition about how the code works and flows.

Good, let huge companies do that. Now this lint madness is pushed onto everybody who wants to program, including individual hobbyists. And many of them are trying to learn coding and get their compiling sabotaged by the linter, not knowing it's something they can opt out of.

Re: Formatting code should be unnecessary

#358

Post by paddy_m »

crazygringo wrote: post #343
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…

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…

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.

Re: Formatting code should be unnecessary

#359

Post by tacitusarc »

forrestthewoods wrote: post #61
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’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 fee…

That may be true for you, but I have worked with plenty of devs who cannot even be consistent with naming conventions in a function, let alone throughout the application.

Don’t get me wrong: modern liners often annoy me and devs who spend a lot of time fiddling with those settings tend not to be very good programmers. But sometimes having guardrails is necessary.

Re: Formatting code should be unnecessary

#360

Post by kmoser »

grumbelbart2 wrote: post #236
kmoser wrote: post #54

Earlier quoted context omitted.

There are annoying edge cases where formatting does matter, such as whitespace around HTML text nodes, e.g.: foo vs: foo

Sure, but the same goes for verbatim strings, or leading whitespaces in python. "Code formatting" questions usually only concern themself with those degrees of freedom that do not alter the semantic meaning of the code.

Agreed, but my experience is that many formatters will try to "help" by formatting non-code, thereby breaking something.
Post reply on HN