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

171–180 of 484 posts

Re: Formatting code should be unnecessary

#171

Post by huflungdung »

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…

That isn’t ocd.

Re: Formatting code should be unnecessary

#172

Post by torginus »

__alexs wrote: post #155
torginus wrote: post #153

Earlier quoted context omitted.

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 slow and has terrible UX. Use Biome instead.

Hi, I'm you from the future. Biome is slow and has terrible UX. Use Tokamak instead (/s)

Re: Formatting code should be unnecessary

#173

Post by account42 »

anilakar wrote: post #146
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.

But a 49" ultrawide is just two 27" monitors side by side. :-)

Better yet, its three monitors with more reasonable aspect ratios side by side.

16:9 is rarely what you want for anything that is mainly text.

Re: Formatting code should be unnecessary

#174

Post by aleph_minus_one »

Some (sometimes) desirable source code formatting cannot be deduced from the abstract syntax tree alone:

Consider the following (pseudo-)code example:

  bar.glob = 1;
  bar.plu.a1 = 21;
  bar.plu.coza = fol;
Should this code formatted this way? Or should it be formatted

  bar.glob     = 1;
  bar.plu.a1   = 21;
  bar.plu.coza = fol;
to emphasize that three assignments are done?

Or should this code be formatted

  bar.glob      = 1;
  bar.plu .a1   = 21;
  bar.plu .coza = fol;
to bring make the "depth" of the structure variables more tabular so that you can immediately see by the tabular shape which "depth" a member variable has?

We can go even further like

  bar.glob     =   1;
  bar.plu.a1   =  21;
  bar.plu.coza = fol;
which emphasizes that the author considers it to be very important that the reader can easily grasp the magnitudes of the numbers involved (which is why in Excel or LibreOffice Calc, numbers are right-aligned by default). Or combining this with making the depth "tabular":

  bar.glob      =   1;
  bar.plu .a1   =  21;
  bar.plu .coza = fol;
Each of these formattings emphasizes different aspects of the code that the author wants to emphasize. This information cannot be deduced from some abstract syntax tree alone. Rather, this needs additional information by the programmer in which sense the structure behind the code intended by the programmer is to be "interpreted".

Re: Formatting code should be unnecessary

#175

Post by bapak »

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…

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)

Re: Formatting code should be unnecessary

#176

Post by aleph_minus_one »

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…

> Anything but text makes grep, diff, sed, and version control less effective.

Perhaps this is rather a design mistake in how UNIX handles things and is so focused on text.

Re: Formatting code should be unnecessary

#177

Post by account42 »

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…

Please no, git trying to automatically "correct" \n vs \r\n line endings is already horrible enough. At least you can turn that off.

Re: Formatting code should be unnecessary

#178

Post by aleph_minus_one »

lmm wrote: post #39
Avshalom wrote: post #6

Earlier quoted context omitted.

The entire OS was built around these source files. the unix philosophy on the other hand only "thrives" if every other tool is designed around (and contains code to parse) "plain text"

> The entire OS was built around these source files. And how did that work out for them? This seems like one of the many cases where unix won out by being a lowest common denominator. Every platform can handle plain text.

> This seems like one of the many cases where unix won out by being a lowest common denominator.

The lowest common denominator rather is binary blobs. :-)

Re: Formatting code should be unnecessary

#179

Post by dcminter »

psychoslave wrote: post #141
Joker_vD wrote: post #110

Earlier quoted context omitted.

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

Printing industry have not been anything close to forever, even writing is relatively novel compared to human spoken languages. All that said, I'm interested with this 132 number, where does it come from?

Printers aside the VT220 terminal from DEC had a 132 column mode. Probably it was aping a standard printer column count. Most of the time we used the 80 column mode as it was far more readable on what was quite a small screen.

Re: Formatting code should be unnecessary

#180

Post by account42 »

hnlmorg wrote: post #111
michaelmrose wrote: post #60

Earlier quoted context omitted.

Which grep doesn't do and you need to either use a new different tool or more likely several for little real benefit

grep is half a century old now. If we can’t progress our ecosystem because we are reliant on one very specific 50+ year old line parser, then that says more about the inflexibility of the industry to move forward than it does about the “new” ideas being presented.

We still use grep because its useful. And it's useful precisely because it doesn't depend on syntax so will work on anything text based.
Post reply on HN