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

281–290 of 484 posts

Re: Formatting code should be unnecessary

#281

Post by JBiserkov »

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

Let this sink in though: [ 'apple' , 'banana' , 'orange' ]

In Clojure, commas are treated as whitespace and are thus completely optional.

Re: Formatting code should be unnecessary

#282

Post by conartist6 »

mdaniel wrote: post #38
lisper wrote: post #11

It never ceases to amaze me how many times people can essentially re-invent S-expressions without realizing that's what they are doing.

Wait until that Bablr user shows up to these threads, and then you'll really have to start drinking

Wow I am thoroughly honored. You are probably the first person ever who isn't me to bring it up in a thread.

I had never heard of DIANA but I love old ideas being new again. (Plus you made me laugh)

Re: Formatting code should be unnecessary

#283

Post by sotix »

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.

A strong reason I enjoy Rust for collaboration is that it's so opinionated, it forces people to focus on solving real problems. I agree that bikeshedding over ES Lint and Prettier configs are not a strong use of time.

Re: Formatting code should be unnecessary

#284

Post by jghn »

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

I’d agree with you except for the trend over the last 10 years or so to set limits back to the Stone Age. For a while there we seemed to be settling on somewhere around 150 characters and yet these days we’re back to the 80-100 range.

Re: Formatting code should be unnecessary

#285

Post by Nevermark »

citizenkeen wrote: post #278
Nevermark wrote: post #277

Earlier quoted context omitted.

This is so clearly superior. Delimiters are prefixes. But the scale of technical debt this insight has revealed is depressing.

Saying this is clearly superior means you don’t keep your lists sorted. A sorted list is as likely to add something to the beginning as the end, where this solution has the same problem.

I just reverse the sort order when that case happens.

Re: Formatting code should be unnecessary

#286

Post by Moomoomoo309 »

DonHopkins wrote: post #267
einpoklum wrote: post #165

Earlier quoted context omitted.

If you ride a bike every day, bike sheds are rather important. If you write and edit and read and search code every day, code formatting is rather important.

You're missing what the bike shedding metaphor is about. It's not about having bike sheds or not, it's about coloring bike sheds, which every day bike riders in their right mind really don't give a shit about, because it doesn't affect their life in any tangible way.

No, the original metaphor is they were planning to build a nuclear reactor and they spent significantly more time than expected on the details of the bike shed because it was simple to understand and change, unlike the details of the reactor which were complex and required expertise and had lots of constraints. Who cares what color the bike shed is, we're building a nuclear reactor here!

Re: Formatting code should be unnecessary

#287

Post by aleph_minus_one »

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…

> 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.

This judgement is rather based on a strong personal opinion (which I don't claim to be wrong, but also not as god-given) on what is one, and what are two changes in the code:

- If you consider adding an additional item to the end of the list to be one code change, I agree that a trailing comma makes sense

- On the other hand, it is also a sensible judgment to consider this to be a code change of two lines:

1. an item (say 'peach') is added to the end of the list

2. 'orange' has been turned from the last element of the list to a non-last element of the list

If you are a proponent of the second interpretation, the version that you consider to be non-advantageous is the one that does make sense.

Re: Formatting code should be unnecessary

#288

Post by jillesvangurp »

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 with this. And of course model driven development was a thing around the same time.

Refactorings (when done right) are syntax tree transformations that preserve things like referential integrity, etc. that ensure code does the same thing before and after applying a refactoring.

A rename becomes trivial if you are simply working on the symbol directly. For that to work with file based source trees, you need to parse the whole thing, keep track of where symbols are referred in files, rename the symbol and then update all the places in the source tree. That stuff becomes a lot easier when the code representation isn't a bunch of files but the syntax tree. The symbol just gets a different name. Anything that uses the symbol will still use the same symbol.

People like editing files of course and that has resulted in a lot of friction developing richer tools that don't store text but something that preserves more structure. The fact that we're still going on about formatting issues a quarter century later maybe shows that this is something to revisit. For many languages and editors, robust symbol renames are still somewhat science fiction. And that's just the most basic refactoring.

Re: Formatting code should be unnecessary

#289

Post by sfn42 »

genericspammer wrote: post #231
wartijn_ wrote: post #98

Earlier quoted context omitted.

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.

Please inform me what the defaults are for Java, C#, C++, C, Bash and Python?

As far as C# goes there's `dotnet format`. You can use it as is or provide an `.editorconfig` file to customize it.

Re: Formatting code should be unnecessary

#290

Post by zokier »

MyOutfitIsVague wrote: post #91
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 sto…

The problem is that there is little benefit in not having the canonical stored representation be text. The crucial thing is to have some canonical representation but it might as well be human readable.
Post reply on HN