Formatting code should be unnecessary

Posted by MaxLeiter 6 days ago

Formatting code should be unnecessary(maxleiter.com)

350 points | 476 commentspage 6

inetknght 5 days ago|

tbqh I would be insanely happy if a formatter would format code the team's way when committing/pushing and my way when I'm viewing locally

I've never found a single formatter that formats my way though...

Perz1val 5 days ago||

One thing I absolutely despise is 2 space indentation. Instead of not creating stupid 5+ level deep nesting, people decided to decrease the indentation size. Then everyone uses tab colorizers or those stupid vertical margins in vscode, because you can't read it otherwise. And then those people put it everywhere with some opinionated formatters - looking at you Elixir. I don't even have vision problems and it's already shit to look at.

yeasku 6 days ago||

Kind of a stupid take if you ever plan on sharing your code or using git.

kesor 6 days ago|

Is it? When every developer has an IDE that can easily format the code in whichever the way they prefer, and minify it back just before pushing a commit.

MaxLeiter 6 days ago|||

No reason websites couldn’t let you choose how to view it like editors, either

yeasku 6 days ago|||

The world is not javascript.

bertil 6 days ago||

That’s essentially what black has done with Python, though.

dubya 6 days ago|

I want to like Black (or rather, uv format), but the mandatory trailing commas weird me out, especially in function definitions. It always looks like an error to me.

thewisenerd 6 days ago||

this is so future 'git diff's when adding new parameters don't look bad

i wonder how many default formatting decisions are made this way (including go fmt, etc)

dubya 5 days ago||

I've seen the reason, I just don't find it convincing. I would like to omit these commas, but also use the formatter sometimes, but that's not really an option. It's frustrating since 'uv format' will omit them for older python versions, so the logic is there.

Something between "everything fits on one short line" and "every argument gets its own line" would be nice too. Spreading a function definition or call across ten lines when it would fit on two or three doesn't feel like an automatic win.

pbiggar 5 days ago||

This is how darklang works as well.

Jean-Papoulos 6 days ago||

So I need to run a tool to even be able to read the code. No thank you, if anything goes wrong your file is now garbage.

benrutter 5 days ago||

In theory that's true of standard office document files too (.docx etc)? Don't think I've encountered too many issues of that actually happening though in the wild?

I'm mainly just being pedantic to be honest, I realise my comment is just me essentially saying "what could possiblye go wrong?"

account42 5 days ago||

Word documents absolutely do get messed up if you open it in a different office suite - or even a different enough version of the same suite.

IshKebab 5 days ago||

Doesn't seem like a real risk - these files are all version controlled.

The bigger problem is you now need custom tooling for your IDE, version control, diff & merge, code review, code hosting, etc. etc.

conartist6 5 days ago||

You're spot-on. HTML and XML are similar textual embedding formats for documents which can contain arbitrary text. Neither is particularly good when the documents are syntax trees though. CSTML takes the design ideas that obviously work and adapts them to be natural for syntax trees, like this: https://gist.github.com/conartist6/75dc969b685bbf69c9fa9800c.... The trees always store inside themselves the complete source code as the parser saw it, so there's little fear of not being able to recover the original, and they're quite human-readable unlike, say, docx files. My team and I are working on building out the VCS, diff and merge, review, hosting, grepping, blogging and other kinds of solutions necessary to make our format able to take over as a de-facto standard.

semiinfinitely 5 days ago||

some people do not understand the difference between form and substance

pluto_modadic 6 days ago||

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.

jgalt212 5 days ago|

line length limits make code harder to grep

More comments...