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

91–100 of 484 posts

Re: Formatting code should be unnecessary

#91

Post by MyOutfitIsVague »

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…

The way I envision this working is with something like git filters. Checking out from version control converts it all into text in your preferred formatting, which you then work with as expected. Staging it converts it into the stored representation. In git, this would be done with smudge and clean filters, like how git LFS works. You'd also have viewers for forges and the like that are built to interpret all the stored representations as needed.

You still work with text, the text just isn't the canonical stored representation. You get diffs to resolve only when structure is changed.

You get most of the same benefit with a pre-commit linter hook, though.

Re: Formatting code should be unnecessary

#92

Post by pluto_modadic »

my initial gut take from the title was "OH MY GOODNESS don't let {x} toxic developer who writes TERRIBLE code see this as justification". There are enough toxic bros who either 1. think this is unnecessary or 2. think it is perfectly solved.

re: intermediate representation and projectional editing: yes, editors are now getting better at helping you refactor code (rename function in language XYZ is possible in language servers for IDEs, /no AI required, it works better when a human coded AST tool does it/)

projectional editors aren't around /because the more complex parts of it are harder/ - BUT - I could definitely see more intelligent refactor tooltips written by humans.

For example: in Rust, if I've been passing a pointer vs borrowing (or whatever), pattern A for most of my code, then pattern B and it complains, it would be useful to have a tooltip that goes "do you want to refactor all the other references/parameters to pattern B" instead of Rust's default "this function isn't using pattern A" borrow checker error.

Re: Formatting code should be unnecessary

#93

Post by brabel »

bee_rider wrote: post #81
teo_zero wrote: post #73

Earlier quoted context omitted.

From TFA: > Everyone had their own pretty-printing settings for viewing [DIANA] however they wanted.

> Back when he was working on Ada, they didn't store text sources at all — they used an IR called DIANA. Everyone had their own pretty-printing settings for viewing it however they wanted. I’m still confused because the specifically call the IR DIANA, and they talk about viewing the IR. It isn’t clear to me if the IR is more like a bytecode or something, or more like just the original source code with a little proces…

I imagine it’s like storing JVM bytecode, ie class files instead of Java files. So when you open it up the editor decompiles it , like IntelliJ does if you try to open a class file, but then it also applies your own style, like from .editorconfig, on the code it shows. It’s a really good idea and I can’t believe people here are complaining that it’s bad because they can’t use grep! But that’s a good thing!! Who the hell is grepping code as if code had no structure and that’s the best you can do? So you also grep JSON instead of using jq? Just don’t!

Re: Formatting code should be unnecessary

#95

Post by mdaniel »

rbits wrote: post #36
jsharpe wrote: post #7

Earlier quoted context omitted.

Exactly. This idea comes up time and time again, but the cost/benefit just doesn't make sense at all. You're adding an unbelievable amount of complex tooling just to avoid running a simple formatter. The goal of having every developer viewing the code with their own preferences just isn't that important. On every team I've been on, we just use a standard style guide, enforced by formatter, and while not everyone agre…

Yeah it would probably be a waste of time. It's a nice idea to dream about though. It would be nice to be able to look at some C# code and not have opening curly brackets on a separate line.

I say this fully cognizant of the thread in which it's posted, but these people are sick

https://astyle.sourceforge.net/astyle.html#_style=whitesmith

And then someone said: oh yeah? Hold my beer https://astyle.sourceforge.net/astyle.html#_style=pico

Re: Formatting code should be unnecessary

#96

Post by raspasov »

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

Exactly. This idea comes up time and time again, but the cost/benefit just doesn't make sense at all. You're adding an unbelievable amount of complex tooling just to avoid running a simple formatter. The goal of having every developer viewing the code with their own preferences just isn't that important. On every team I've been on, we just use a standard style guide, enforced by formatter, and while not everyone agre…

>> The goal of having every developer viewing the code with their own preferences just isn't that important.

Bah! So, what is more important? Is the average convenience of the herd more important? Average of the convenience, even if there was ever such a thing.

What if you really liked reading books in paper format, but were forced to read them on displays for... reasons?

Re: Formatting code should be unnecessary

#97

Post by hannasm »

This article is barely a comment on some other situation; but I've been saying this to anyone who wants listen for years.

There's nothing special about whitespace (unless you write python).

Capitalization and a bunch of other stuff in your coding convention document are usually just signs that you have poor tooling and lack of skill.

Give me a PR that satisfies the requirements and the appropriate test cases and i'll happily rewrite it to spaces only indented with curly braces on newlines and etc... as I see fit.

The hard part is the first two tasks, you can train an intern to do the third

Re: Formatting code should be unnecessary

#98

Post by wartijn_ »

garbagepatch wrote: post #76
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.

> just make a choice Now you are bikeshedding. Just go with the defaults.

Which defaults? The programming languages I’ve worked with don’t have defaults for everything related to formatting. Editor defaults don’t work, since not everybody uses the same editor. So you have to make a choice somewhere.

Re: Formatting code should be unnecessary

#99

Post by lambdaba »

elevation wrote: post #88
jupp0r wrote: 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.

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 agree, I'm very much against any line length constraint, it's arbitrary and word wrapping exists.

Re: Formatting code should be unnecessary

#100

Post by IlikeKitties »

elevation wrote: post #88
jupp0r wrote: 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.

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'm suprised. I find the short-line version to be much better.
Post reply on HN