Hacker News Reader

Comment by petetnt | Hacker News Reader

These days I vastly prefer autoformatters, only run at precommit stage myself. Instead of having to adapt to different styles everytime and getting distracted by stylistic changes mid-coding (eg. on save), I can just rely that the styles are eventually consistent and code ahead. It takes some time getting used to, but it’s super refreshing.

View on HN

Personally, I rely a lot on autoformatters ran on save. It frees my mind completely from thinking about formatting, I can write ugly one-liners that get immediately beautified and I have an almost-immediate feedback for syntax errors (it doesn't autoformat => I made a syntax error somewhere)

This was something I wasn't really expecting when I started working on prettier. It was a strong selling point when people adopted it within Facebook.

I still can't believe that it only took a year between the first commit of prettier and 100% of Facebook massive codebase to be completely formatted using prettier.

Prettier is also growing extremely quickly in open source. It's now at 3.7 million downloads a week, compared to 6 million for React.

I didn't get to say this before I quit working at FB, but thank you for building prettier! It really made writing and reviewing JS much less painful.

Even if there were no other advantages to Prettier, I would use it for this. It seems barbaric to write in languages now that don’t have something similar happening on save.

Same here. This is so powerful. I absolutely love python, but this is one thing it doesn't allow. On the other when working in say Rust, I can express my thought in a line or 2 straight from brain to keyboard without having to care about any formatting, hit autoformatter and also typically get an immediate feedback about basic syntax.

When writing in a language that can be auto formatted, it is a huge cognitive overload removed from my shoulders, like having a copilot.

Have you tried any Python autoformatters? `autopep8`, `yapf`, and `Black` come to mind.

Yes. They can format correct python to pep8, but can't guess which if an else correspond to if I write it all on one or two lines.

This experience must have been with a formatter different than Black. That one has no problems with any valid syntax.

I think the point is that the valid python syntax is potentially a limitation on any autoformatting tool. Like, suppose you were writing in C. You might well write this:

    if(x);else if(y){if(z);else;}

and clang-format would turn it into this:

    if(x) {
    } else if(y) {
        if(z) {
        } else {
        }
    }

But the equivalent in Python has to be correctly indented to be interpreted properly, because you need to distinguish these two cases:

    if x: pass                 if x: pass
    elif y:                    elif y:
        if x: pass                 if x: pass
    else: pass                     else: pass

(This is the classic shift/reduce problem: https://www.gnu.org/software/bison/manual/html_node/Shift_00...)

This is sort-of not unreasonable, because of course code has to be syntactically correct for the autoformatter to do its thing, and if you're working in Python, these are the syntax rules. So, what can you do?

But suppose you'd come to find it valuable to be able to stuff all your code on one line and have the autoformatter sort it out: you might then find the Python syntax a backwards step by comparison, rather than an improvement. I think this is the claim that's being made, and no more.

It even has a name, the Dangling Else, and dates back to Algol:

https://en.wikipedia.org/wiki/Dangling_else

One solution is to make the formatter interactive and prompt for which interpretation is desired.

A CL restart-style editor integration for this could be interesting.

This is what I meant, yes, although I could never have explained it half as well as you did!

My team just converted to `black`. I find it shockingly bad. I does format code legally according to its rules, but the result is often absolute trash from a human readability standpoint.

I’m fascinated by this response: Black has been the first Python autoformatter I have had that problem with and felt comfortable enabling as a pre-commit / CI check.

Do you have any examples of things which were so bad? The team has been pretty response for the handful of things which I reported.

I think it's really a people problem:

Black will mindlessly split long lines into shorter, and my coworkers will just leave them as is. The results are eye bleedingly awful.

I hope most black proponents expect people to look at the generated code and change things until it looks decent?

Of course this problem is inherent in a tool that is autoformatting rather than warning, and seems to me to indicate a mentality that code is meant to be read by computers, not humans.

I think some of this is just that you have strong personal opinions which are somewhat out of the norm. I have Black split long lines but the results are never what I’d call awful and I’d increasingly class that as a code-smell indicator since the cases where I haven’t been happy with the results were generally unnecessarily complex lines which could be split to be more readable.

I would also flip your last sentence completely: computers don’t have problems reading code of any style. Auto-formatting is so humans don’t burn time adjusting to different styles or, worse, failing to parse them the same way as a compiler.

You seem to be sitting on two chairs here.

The split of the long lines aren't bad, but they are also bad because the long lines are inherently too complex.

Of course some times our broken up lines are too complex, and should ideally be restructured, but...

1. The mechanical way Black does it is rarely the best way to decomplexify things.

2. Often the long line wasn't complex at all. It just contained a simple but long string. Line length is a weak measure of code complexity, but as a dumb script, it's all Black can use.

That said, my main beef is really with the 88 char line length. If it was 120 or 140, I wouldn't like Black either, but I'd only be kinda annoyed. Coupled with 4 char indentations, 88 s an absurdly small space to fit code in, when we have the biggest screens in history. It's an incomprehensible madness to me.

Not sure what your final section says. I hope it's not that humans should learn to read code just like computers do?

To me, one of the most important quotes about our job is this:

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

FWIW, Black now allows line-length customization via the `--line-length` argument.

Yeah, we actually looked at that today, and I'm impressed by how it repairs what it tore apart in "88" mode.

We might change things up and I might be OK with my 'black life after all.

Agreed, I now feel like I'm editing the AST instead of editing text, it's quite magical.

That latter point is how I do a lot of my syntax-related bug finding with Emacs: press C-x h Tab, look for where the indentation starts to look unexpectedly wonky, fix the issue that caused it, repeat.

Ok, help me understand this. I’m on #TeamTab which puts me at odds with most coding standards. I usually work solo, so I don’t care, but every time I do let someone else edit a file, the commit shows every line has changed because their editor converts my indents.

Are you saying there’s a tool that will let me work with (superior) tabs but have standards compliant commits?

I’ve tried doing this in my .gitconfig with limited success. It didn’t work consistently.

See `go fmt` for Go and Black for Python for examples to try out.

gofmt uses tabs too ;-)

This should help. Stick and en editorconfig file in the root of your project and tell it to use tabs and if all developers are using a supported editor then their (superior) spaces would be converted to the (inferior) tabs lol

on the other hand, i appreciate being able to comment out lines by typing `//` and not having my indentation f'd up. i also like to be able to un-indent stuff using backspace rather than shift-tab. also, using tabs at 4-spaces allows me to more easily detect misalignment since deleting one 4-space tab is obvious, while deleting a single space is not. while i know EOL line comments are not everyone's cup of tea, good luck getting good alignment (or changing alignment) on those with spaces.

i say tabs are superior. the real solution is probably variable width tabstops: http://nickgravgaard.com/elastic-tabstops/

My experience with spaces is usually editors treating 4 spaces as a tab when backspacing. The rare need for a real single unit backspace has to be made up for with 3 additional spaces.

The trouble is most editors do this half-assed, for example you can select half of a "tab" if you use spaces, which makes no sense and lets you screw up the indentation easier.

The only editor that really does properly support "just set this option and then it's like you are using tabs" is Atom. But I don't really want to use Atom.

> also, using tabs at 4-spaces allows me to more easily detect misalignment since

If you use an autoformatter there is no need to manually check for misalignement!

Just type in some code, press a key and everything is aligned, problem solved!

Yes. With this sort of tool, all this potential drudge work simply vanishes! I suppose if you don't use these tools, it might not be obvious just how amazingly super convenient it all becomes.

Indentation all fucked up? No problem, press the auto format key, and the computer will unfuck it for you.

Need to indent or unindent a block of code? No problem, press the auto format key. You don't even have to think about whether it needs more indentation, or less. The computer will do that for you.

Do you type all your code on one line without putting any spaces in? Well, don't tell anybody, just press the auto format key, and they will never find out. (I know I just told you not to tell anybody, but: I do this all the time. And it's great.)

In fact, you don't need to really think about any of this whatsoever even at this level of detail, because you can just develop the habit of pressing the reformat key every now and again. Or get the editor to do it every time you save, and then you don't even have to remember to do that.

But, however you do it, this sort of tool reduces to pretty much zero the amount of energy you have to expend on caring about how the code looks.

Tabs are an editor feature, and their use in your editor is somewhat unrelated to the way your editor serializes them onto disk.

There are configurations for your editor that will allow this, independent of the EditorConfig project.

This isn't true, because lining things up visually works differently with tabs than with spaces. (Although, personally, this is why I never visually align code like that, but that's the standard style in many organizations/languages.)

I will never understand why people get so religious about tabs vs spaces, but this is a hill I’m willing to die on: please don’t line things up visually in your source code, beyond standard indentation.

There are some popular coding standards that essentially require it, unfortunately.

My opinion on this is that it's a bad idea in the age where we (finally) have near universal acceptance of source control, because they bloat commits with irrelevant changes in surrounding lines to preserve alignment when identifiers change. Black got it exactly right - optimize for readability and change locality.

why are you against it?

It’s brittle and fiddly, and it’s basically the only way to make it impossible to use proportional fonts, which are much more important for readability.

If you feel like it’s useful, you should probably be using an editor with real elastic tabstops instead.

"It’s brittle and fiddly"

You picked the wrong vocation my friend. It's "brittle and fiddly" all the way down.

the fact that most editors use mono-space fonts by default and hardly anyone is clamoring for the ability to use proprotional fonts seems to argue against them being particularly important to readability, at least as far as the community seems to be concerned.

re "you should probably be using an editor with real elastic tabstops" ... i don't get what you're trying to say. What does real or fake elastic tabstops have to do with the choice to align code beyond just indentation?

Manual alignment is often used as a poor man’s elastic tabstops.

I think there’s a chicken-and-egg situation with monospaced type and programming. Programming was a thing before digital proportional typefaces were a thing, so some people came to rely on the fixed spacing to treat their source code as a 2d grid rather than a 1d buffer. This in turn made it more difficult to switch over to proportional typefaces despite their advantages, and at some point code == monospaced was just taken for granted. Another issue that comes from mistaking your code for a 2d mosaic is the dogma of dictating a maximum number of characters per line, instead of the more reasonable approach of using whatever expresses the structure of the program most clearly, and relying on line wrapping to make sure it’s all visible.

FWIW I use proportional fonts, and 95% of the time it’s completely unproblematic. Fortunately I rarely work with code that uses manual alignment. It’s usually the occasional ASCII diagram that forces me to temporarily switch over to fixed pitch.

> but this is a hill I’m willing to die on: please don’t line things up visually in your source code, beyond standard indentation.

what's the argument against this? There are many arguments for how it can improve readability and speed up understanding of what you're looking at when you're not familiar with it.

It may be an editor feature, but it's a UX anti-feature.

If you are in a system small enough that you only ever have to look at code in a code editor, then this anti-feature won't be a real problem.

If you work in a sufficiently complex environment that displays code across a variety of platforms, tabs will only make working with the code more difficult.

Not really. Most interfaces let you select the tab size or use some sensible default (e.g. 4). If you are using tabs properly it doesn't matter what display size they have.

One odd exception is GitHub which inexplicably uses size-8 tabs by default which is way too big. I can only assume that somebody there is a space zealot and wants to screw up the UX for enlightened tab users.

Yes really.

When I have to work on N platforms that are constantly shifting, I don't want to spend the overhead and mental effort to reconfigure the ones that can be reconfigured, and eat nameless dread on the ones that can't.

When you view code across dozens of platforms, across dozens of machines, your perspective on "high maintenance config" everywhere changes a bit.

If you can't be effective with default configs, you lose efficiency to config maintenance.

Really, the last thing I want to deal with while I'm triaging some critical issue is dependency management for N code viewers.

Take a look at a picture of a mechanical typewriter:

http://blog.gngcreative.com/wp-content/uploads/2015/02/mi0fg...

Those metal things you can see there, those are tabstops. They are called tabstops because when you press the tab key, the carriage mechanically stops at the tabstop.

Tabstops were placed every 8 characters. A tabstop is simply a way to "type" 8 spaces with one keypress.

Github is not the only page that uses 8 spaces for a tab, and it's definitely not inexplicable. The Unix/Linux terminal uses 8 spaces by default if you insert a tab. Vim uses 8 spaces by default if you insert a tab. Python considers a tab to be equivalent to 8 spaces. I'm sure there are a lot of other systems that default to this value.

If you want to control how an indentation looks, use spaces. If you want tabs because the size is configurable and can be adjusted to one's preferences, you can't at the same time complain about "unreasonable configurations" that others use :)

> Tabstops were placed every 8 characters. A tabstop is simply a way to "type" 8 spaces with one keypress.

tabstops were _not_ restricted to 8 characters. In many systems different tabstops were different widths from their predecessor. E.g. your first tabstop might be 20 characters in but all the ones after it would be 8 past their predecessor. Alternately you could vary all of them but that'd look pretty weird.

Thanks, TIL. But 8 was common, right? At least from online sources I was under the impression that typewriter tabstops were the reason for the 8 character default.

Ok but I don't know if you noticed but we don't use typewriters anymore.

I was only answering to the assertion that tab-width of 8 is "inexplicable".

8 is the standard tab width. That's probably why GitHub chose it. (Why 8? I've no idea. Somebody will be along with an explanation soon enough, I am sure, and you can decide whether you believe it or not. But, whatever, it has been 8 for a very long time.)

If you're using a typewriter and constructing tables (hence "tab"), 8 is a good balance between column width and number of columns.

I don’t think it’s GitHub that chose this; the standard size for a tab in most browsers seems to be eight characters.

That's a good point. I checked and it does actually just seem to pass the tab characters through, letting the browser do its thing.

To change it from 8, you need the `tab-size` CSS property. This has long been supported by all except IE/Edge.

This can be very neat for responsive design: use tabs for your indentation, and then on large screens use `tab-size: 4` because you’ve got space to spare and four is generally superior to two, and on narrow screens use `tab-size: 2` because you don’t have as much width to play with.

The `.editorconfig` file in question actually also instructs GitHub to display source code in your repository with a given amount of spaces-per-tab. Just place the file in the root of your repository:

  root = true
  [*]
  indent_style = tab
  indent_size = 2

That being said, GitHub's default setting can only be seen as a spaces mongering ploy to subvert the true usage of tabs.

The real-world choice is not (tabs) || (spaces), it's (tabs && spaces) || (spaces). Which is why spaces is the objectively superior choice.

It depends on the exact formatting used. Many popular schemes only require tabs at the beginning of the line, and are not dependent on tab size.

Tabs allow each developer to choose his level of indentation. I think personal choice and flexibility to always be the objectively superior choice.

That's not true if your code style doesn't allow visually lining things up. Then tabs will only ever act as standard indentation, and so tabs vs spaces doesn't actually matter aside from enforcing line length.

In any project I've worked on that has used tabs for indentation, I've found no need to combine tabs and spaces. I've never been anywhere that enforces neurotic alignment standards, and if such guidelines aren't part of your workflow, I don't know why anyone would consciously inflict spaces upon themselves or their team. Some editors handle them like shit, and formatting fuckups always find their way in unless you're using an autoformatter.

The only arguments I hear for spaces are alignment (I don't have time to give a shit about such minor aesthetic preferences) and forcing other people to see code a certain way (I really don't understand why I would want to force my editing preferences on others). I don't think either one of them justifies the annoyance of spaces.

Huh? You say "[I wouldn't] force my editing preferences on others", yet you want to insist on inserting invisible whitespace characters into shared source code. That seems inconsistent to me.

That's a disingenuous misinterpretation of the comment. There's a clear difference between "I'd like code to be indented", which is widely agreed upon to be a good idea, and "you need to see my code indented with four characters because I hardcoded this into my source code", which is personal preference.

They are invisible whitespace characters that are handled reliably and flexibly in every editor that I've ever used them in. The same cannot be said for spaces. If a codebase is using two space indenting, I get to look at the resulting puke (this is subjective, of course) on my screen. I might be able to do some hackjob fix to change how they're displayed, but why should I have to? There's a character that satisfies both me and the animal that wanted to indent their code with 2 spaces.

Using hanging indents for line continuations solves this issue by making the choice of using tabs or spaces a non-issue.

You’re jumping to conclusions. Projects use both tabs and spaces because they have different purposes: tabs are for indentation, and spaces are for alignment. When you use spaces exclusively, you’re conflating the two and requiring tooling to be more complex to handle figuring out what you meant semantically from a lossy format. (Also, many people use who use tabs will do so exclusively and give up alignment, for simplicity’s sake.)

I'm not jumping to anything. Rather, I'm sharing my observations. I've been in the field for 20 years, and I stand by my point, which is that spaces will always find their way into a project. Projects that use tabs inevitably end up containing spaces too; not because of an intended specialized use case, but because of human nature.

Human nature being that people who prefer spaces will end up inserting them where they don't belong, and then have the gall to blame tabs for being confusing because they messed up the indentation :/

Do git commit hooks work for you? You and your collaborators can do whatever. The hook ensures things are converted to either tabs or spaces prior to commit. You can also set up a CI job to auto-reject any PRs that aren't tab/space compliant.

This is all pretty pretty straightforward to configure on a per-repo basis too, so you can hop around multiple projects with different standards and not have to think too much about this.

The thing with ideal auto-formatters is that there is no discussion about tabs vs spaces anymore!

In a perfect world each language has exactly one (non-configurable) formatter and this solves all the formatting discussions.

For JS I use prettier and altough I am not 100% happy with some of the formatting choices I _love_ it because I can focus on code and not have flamewars about tabs vs spaces with my co-workers. prettier ends all style discussions. And code reviews are much nicer because people concentrate on checking the code, not the formatting.

I think the perfect world would have any number of formatters, but with ubiquitous tooling that allows each person to see code in their preferred format.

This sounds horrible for collaboration and pair programming tho.

For an open source project, I'd recommend using an autoformatter, documenting it in the contributing guide, and enforcing it in CI so that anyone submitting a PR can clearly see if they submit something that breaks the formatting rules. I am much happier contributing to projects like these rather than trying to figure out all of the nuances of the author's preferred formatting style. Working with autoformatters for the last year or two has made me care much less about things like tabs vs spaces, I just care that the tooling is set up so that I don't need to think about it.

As a concrete example (for JS projects), you could configure Prettier to use tabs for indentation:

https://prettier.io/docs/en/options.html#tabs

Then you could use eslint-plugin-prettier, which fails lint if the code isn't Prettier-formatted and makes ESLint autofix also run Prettier:

https://github.com/prettier/eslint-plugin-prettier

Then set up lint to run in CI alongside tests.

> Are you saying there’s a tool that will let me work with (superior) tabs but have standards compliant commits?

Yes. It's an autoformatter and it will make you never care again about tabs and spaces and other unimportant issues us devs love to bicker about. Focus on the higher level stuff instead :)

I use both: an increasing percentage of formatters and linters support .editorconfig so you can set the common basics there and not need to duplicate configuration for every tool you use on a project.

I’m in very strong agreement on using formatters, too, but I have mine run on-save. It’s slightly disconcerting at first but extremely relieving when you realize how long it’s been since you’ve talked about code style.

I agree, I love on-save formatting. Now I can just type code I know is syntactically correct, hit save, and let the formatter worry about the formatting.

I first encountered this when I began working in golang because it was batteries included with go fmt.

I know this makes me late to the party, so can anyone comment on similarly dominant/official tools in their language of professional experience?

A web search can find tools, but it’s hard to know when one is likely to be “blessed” by potential future project teams.

I use go fmt and editor config together. Gotta tame the white space locally. All them tabs give me whiplash.

For Javascript, ESLint and Prettier are the most used (can be used together)

Flake8 + Black for Python do a good job

Black is written by python core devs AFAIK (pip install black).

I love it so much because you cannot configure it much, so it defines a clear standard that everybody can depend on

C, C++, Objective-C: clang-format

Java: Probably google-java-format

HTML, CSS, JavaScript, TypeScript, Markdown, YAML: Prettier

Python: autopep8, yapf, and black are all widely used and I don't think any of them is dominant. I personally favor black, as it's the only one of the three that strives to leave as few degrees of freedom as possible (i.e., the same source code is always formatted the same way).

Rust: rustfmt

Black seems to be the most popular these days. It's certainly the one you hear the most about and it's getting support by default in vscode and pycharm.

Since we're on the subject: I was just looking into https://standardjs.com and wondering about how others are using these kinds of tools. It seems you've made extensive use of formatters: what made you decide on the ones you listed? I like linters a lot myself, but I'm not using formatters because it is difficult to work on code after a tool has reorganized it without my understanding of what it did. However, I rarely have time to go back through and do the cleanup myself. Does using these tools save you from the "I'll go back and clean this up later." mentality?

clang-format works with Java. It’s not as great at Eclipse’s formatter, but it is quite good and I’ve never had significant issues with it.

Perltidy for Perl. https://metacpan.org/pod/perltidy

On my case,

C++, .NET languages, TypeScript, JavaScript: Default Visual Studio/VSC configuration

Java: Eclipse/Netbeans/InteliJ configured for Sun's conventions

Bah I read a lot about the niceties of using autoformaters then I had to use clang-format for C++ at work and when I discovered that the format is totally borked when you use macros in lambdas, well..

I prefer manual formatting, yes each coder does it differently but who cares? The result is still readable which is NOT the case when an automatic formatting tool goes nuts..

I agree that autoformatters are the only way to go. It is nice if your editor kind of gets it close, though, so it's less jarring when things move around after save.

This is why I love gofmt. Because I don't care about formats and finally there's a tool to remove the tabs vs spaces debate and allow people to focus on issues of substance.

You might still want this for your editor to properly have indenting information as you are coding though no?

Also a good policy for naive diff algorithms that don't know whether minor changes are semantic or not (e.g. whitespace in Python vs. PHP)

So, do you format back again to your style before editing?

You can't preview a file without modifying the file.

Reply on news.ycombinator.com