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

361–370 of 484 posts

Re: Formatting code should be unnecessary

#361

Post by johnnypangs »

kristopolous wrote: post #240
AdieuToLogic wrote: post #107

Earlier quoted context omitted.

> I've never understood why people care so much about the linter settings. Source code formatting programs are not the same as lint[0] programs. The former rewrites source code files such that the output is conformant with a set of layout rules without altering existing logic. The latter is a category of idempotent source code analysis programs typically used to identify potential implementation errors within otherwi…

Formatters, if you want to be specific, are even worse. They slyly add git noise and pollute your audit trails by just going through and moving shit around whenever you save a file. And sometimes, they actually insert bugs - string formatting errors are my favorite example. It's for people who think good code is a about adhering to aesthetic ideologies instead of making things documented and accountable. This is most…

I’ve used this before, it helps when you format the entire repo and remove the one commit from the history https://docs.github.com/en/repositories/working-with-files/u...

Re: Formatting code should be unnecessary

#362

Post by robertlagrant »

kolme wrote: post #338
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 did that when I was young and naive. I'll tell you why I did it. I thought I was very smart. Like, really really smart, maybe the smartest programmer in the team. And as such my opinion was very important. Maybe the most important opinion in the team. Everyone had to listen to it! That is all. Also, I was wrong.

> Also, I was wrong.

This is probably the only useful takeaway, but can you explain why you were wrong?

Re: Formatting code should be unnecessary

#363

Post by oftenwrong »

__MatrixMan__ wrote: post #42

Unison doesn't move the formatting choices further than the machine on which the code was written. The codebase only contains the AST. Its such a cool idea, though I haven't spent much time using it in anger, so its hard to say if its a useful idea.

Unison's immutable definitions also enable a bunch of compelling capabilities. No merge conflicts. Incremental everything: build, test, lint, distribution, rendering as formatted text, et cetera. Trivial to apply "hot" updates to running systems.

Re: Formatting code should be unnecessary

#364

Post by tacitusarc »

iainmerrick wrote: post #329
maratc wrote: post #275

Earlier quoted context omitted.

I may be unusual in a way I treat my profession and care about my professional output (the code I write), and I take both very seriously. There's a quote from Steve Jobs (or maybe his carpenter father): “When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going…

I don't think we'll ever fully agree, but I'd just like to clarify that I value that kind of craftsmanship too! I just honestly believe that if you fully automate the formatting, the results are better than if you do it painstakingly by hand; better by virtue of being more consistent. It's using the right tool for the job.

Did you read the example pietnas gave? The changed formatting ruined the communicative intent of his code. Formatters do that a lot, and it makes the code unambiguously worse.

I don’t really care about whether the back is plywood or whatever. I don’t know how to write plywood code. I do care about creating clear, readable code that communicates my intent. Sometimes formatters help with that. Often they hinder, as they reflect the arbitrary aesthetic preferences of their creators.

Re: Formatting code should be unnecessary

#365

Post by BurningFrog »

Code layout is important, even though it - much like naming - doesn't impact functionality.

I can write code that (IMHO) is substantially better than any formatter. But I've realized that there is no way to make other people on a team have the same opinions and skill as me, so I accept automatic code formatters.

Re: Formatting code should be unnecessary

#366

Post by Ygg2 »

kelseyfrog wrote: post #2

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…

> would those who prefer tabs have any other arguments?

Yes. Because Yaml exists. And mixing tabs and spaces is horrible in it. And the rules are very finnicky.

Optimal tab usage is emit 2-4 spaces.

Re: Formatting code should be unnecessary

#367

Post by triknomeister »

kristopolous wrote: post #240
AdieuToLogic wrote: post #107

Earlier quoted context omitted.

> I've never understood why people care so much about the linter settings. Source code formatting programs are not the same as lint[0] programs. The former rewrites source code files such that the output is conformant with a set of layout rules without altering existing logic. The latter is a category of idempotent source code analysis programs typically used to identify potential implementation errors within otherwi…

Formatters, if you want to be specific, are even worse. They slyly add git noise and pollute your audit trails by just going through and moving shit around whenever you save a file. And sometimes, they actually insert bugs - string formatting errors are my favorite example. It's for people who think good code is a about adhering to aesthetic ideologies instead of making things documented and accountable. This is most…

formatting on git diffs is a concept which should be embraced.

Re: Formatting code should be unnecessary

#368

Post by oftenwrong »

Storing an IR also means we can create languages beyond the limits of syntactical practicality. Imagine, for example, an entire comment/documentation dimension of the code. Instead of commenting on a line near some code, you could attach comments semantically to an expression, or to a variable, or to any unit of code.

Re: Formatting code should be unnecessary

#369

Post by jillesvangurp »

zokier wrote: post #305
jillesvangurp wrote: post #288

There was a movement towards working with syntax trees directly and treating source code as a generated serialization of those syntax trees about 20-25 years ago. This probably started with refactoring as it was pioneered in the nineties. Things like Visual Age actually stored code in a database instead of on the file system. Later intentional programming (Charles Simonyi was pushing that) tried to also do things wit…

Meh. > That stuff becomes a lot easier when the code representation isn't a bunch of files but the syntax tree You are just mixing abstraction layers here. That syntax tree still needs to be stored in file(s) somehow, and nothing prevents having syntax tree aware (or smarter) tooling operating on human readable files. Basically deserializing AST and parsing source code are the same thing. The storage format really is…

> That syntax tree still needs to be stored in file(s) somehow

Sure, but there are less flaky ways than spreading a syntax tree across files. Visual Age actually used a database for this back in the day. Smalltalk did similar things by storing code in an image file that contained both byte code and method definitions. You could export source code if you wanted. But wouldn't do that while developing typically. That's not an approach that caught on. But it has some advantages.

What you are describing is what Eclipse did with Java. Eclipse was the successor to Visual Age. The Eclipse incremental compiler for Java updated an internal data structure for the IDE. It could do neat things as partial compilation to enable running tests even in the presence of some compile errors. It also was really fast. By the time you stopped typing, it would have already compiled your code. Running the tests was similarly fast.

The problem of syncing a tree of source files with an AST is just a bit hard. Intellij never came close to this and has always had lots of trouble keeping its internal caches coherent. There's even a top level "invalidate caches" option in the File menu (still there, I checked. Right next to the Repair IDE option). They were off by 2-3 orders of magnitude. Seconds (at best) instead of milliseconds. I still miss Eclipse's speed every day I use Intellij.

Some compilers are taking some steps to supporting more advanced IDEs. But there aren't a lot of those beyond what Jetbrains provides. VS Studio Code support varies between different languages. But mostly it's very limited on this front. The Rust compiler is one of those. Though I don't know the current state of that. Mostly it's not well known for its blazing performance (the compiler). I'm not sure if Jetbrains leverages many of those features in its Rust IDE (I'm not a Rust developer).

Re: Formatting code should be unnecessary

#370

Post by dvdkon »

crazygringo wrote: post #346
sn0wleppard wrote: post #149

Earlier quoted context omitted.

The worst is when you have lines in a similar pattern across your formatter's line length boundary and you end up with 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);

I think with the Black formatter you can force the multiline version by adding a trailing comma to the arguments. The pain point you describe is real, which is why that was intentionally added as a feature. Of course it requires a language that allows trailing commas, and a formatter that uses that convention.

A similar tip: As far as I can tell, clang-format doesn't reflow across comments, so to force a linebreak you can add a // end-of-line comment.
Post reply on HN