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

271–280 of 484 posts

Re: Formatting code should be unnecessary

#271

Post by austin-cheney »

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…

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.

Re: Formatting code should be unnecessary

#272

Post by Cthulhu_ »

torginus wrote: post #153
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.

The problem is that tools like ESlint often come with highly opinionated rules that might not even be applicable all of the time (leading to me having to manually turn them off via annotations) And there's no centralized idea on best practices.

ESLint is the centralized idea I suppose, but getting consensus is difficult.

When it comes to formatting, there's other languages (Go, Python?) that have clear, top-down guidelines applied by tooling, at least for code style. I think that's clever, and besides the odd mailing list post trying to change it because of a personal preference, it minimizes discussions about trivialities over the really important things.

Because 2 vs 4 spaces or line length discussions are ultimately futile; those aren't features, individual preferences don't matter. Codebases have millions of lines and thousands of developers; individual opinions do not matter at scale, consistency does.

Re: Formatting code should be unnecessary

#274

Post by balamatom »

Joker_vD wrote: post #110
skinner927 wrote: post #72

Earlier quoted context omitted.

I still prefer 80. I won’t (publicly) scoff at 100 though. IMO 120 is reasonable for HTML and Java, but that’s about it. Sent from my 49” G9 Ultrawide.

Give a try to 132 mode, maybe? It was the standard paper width for printouts since, well, forever.

That's actually just weirdly specific enough to be worth a shot.

Re: Formatting code should be unnecessary

#275

Post by maratc »

iainmerrick wrote: post #268
maratc wrote: post #250

Earlier quoted context omitted.

Agree. There's a python linter named `black` and it converts my code: important_numbers = { "x": 3, "y": 42, # Answer to the Ultimate Question! "z": 2 } into this: important_numbers = {"x": 3, "y": 42, "z": 2} # Answer to the Ultimate Question! This `black` is non-configurable (because it's "opinionated") and yet, out of some strange cargo cult, people swear by it and try to impose it on everybody.

This is the flip side of "I’ve never understood why people care so much about the linter"! Why are you caring about formatting? Just write your code, get it working, let Black tidy it up in the standard way. Don't worry about the formatting. In cases where you're annoyed about some choice the formatter makes, somebody else would be equally annoyed by the choice you would rather make. There is no perfect solution. The…

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 to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through.”
When you say "Don't worry about the formatting", what you're saying is "use a piece of plywood on the back," and I'm just not going to do that.

Re: Formatting code should be unnecessary

#276

Post by zokier »

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

I’d also add: * [Difftastic]( https://difftastic.wilfred.me.uk/ ) — my go-to diff tool for years * [Nu shell]( https://www.nushell.sh/ ) — a promising idea, but still lacking in design/implementation maturity What I’d really like to see is a *viable projectional editor* and a broader shift from text-centric to data-centric tools. The issue is that nearly everything we use today (editors, IDEs, coreutils) is built aro…

But almost every editor worth its salt these days has structural editing.

https://docs.helix-editor.com/syntax-aware-motions.html

https://www.masteringemacs.org/article/combobulate-structure...

https://zed.dev/blog/syntax-aware-editing

Etc etc.

Re: Formatting code should be unnecessary

#277

Post by Nevermark »

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' ]

This is so clearly superior. Delimiters are prefixes.

But the scale of technical debt this insight has revealed is depressing.

Re: Formatting code should be unnecessary

#278

Post by citizenkeen »

Nevermark wrote: post #277
rapind wrote: post #256

Earlier quoted context omitted.

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

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.

Re: Formatting code should be unnecessary

#279

Post by setr »

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.

The only correct syntax/format

    [
      , a
      , b
      , c
    ]
If only there existed a language designer intelligent enough to support it

Re: Formatting code should be unnecessary

#280

Post by zokier »

bapak wrote: post #175
MyOutfitIsVague wrote: post #91

Earlier quoted context omitted.

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…

This is it, unfortunately git is "too dumb" for this. In order to merge code, it would have to either understand the AST. What happens when you stage the line `} else return {`? git doesn't allow to stage specific AST nodes. It would also mean that you can't stage partial code (that produces syntax errors)

Git can use arbitrary merge (and diff) tools. Something like https://mergiraf.org/introduction.html works with git and gets you ast aware merging. Do not underestimate gits flexibility.
Post reply on HN