Hacker News Reader

Comment by frou_dh | Hacker News Reader

Put another way... if the proponent of a particular (serious) syntax style guide can't be bothered to automate it, then they are pissing in the wind.

I laugh when I see those 50-page English-language documents describing how some institution wants code to be formatted. Ain't nobody got time for that.

View on HN

I worked at a place recently where someone (who left before me) argued seriously that automated syntax fixing shouldn't be brought into the millions of lines multi-project codebase with approximately a dozen developers with a 40% retention rate over any two year period because it would encourage bad habits by not properly punishing people for being bad.

There are some limits to what you can automate but stuff like spacing should definitely be enforced by a tool.

I feel like Prettier does a really good job with JavaScript.

What situations have you found where automated formatting doesn’t suffice or has these limits?

Ordering code.

Some tools order/deduplicate imports. Prettier does not. [1]

And no tool that I've seen orders fields/constructor/method, etc.

[1] https://github.com/prettier/prettier/issues/949

Interesting, yeah, that’s definitely missing. ESLint has rules for ordering, feels like it’d be a relatively simple addition to prettier.

In JavaScript, imports sometimes (too often, really) have side effects. I don't know if it makes sense for prettier to do that, at least by default.

In my experience, side-effecting imports are fairly uncommon.

But in any cases, all formatters allow you to selectively disable it for certain liners.

Hopefully uncommon, anyways. Imports with side effects sounds like a nightmare to debug.

I don't have a problem with anything that discourages imports with side effects. You can always ignore[0] any cases where this happens.

[0] https://prettier.io/docs/en/ignore.html

eslint and prettier are not mutually exclusive

I didn’t mean to imply that. In fact we use eslint + prettier where I work.

> it’d be a relatively simple addition to prettier.

It would be, but as you can see in the linked issue, it was closed for being a non-goal. So, it's not likely to change.

(Prettier generally keeps the AST identical; i.e. whitespace and parentheses changes only.)

I don't know if it supports JavaScript but Resharper does this for .Net

I think all three major Java IDEs do this as well.

Humans format with rules that take into account semantic information, symmetry, and aesthetics. They know that a function call that gives the entries of a matrix is formatted as a grid for a reason even when the auto-formatter could fit it on one line. They know that that arm of the match that would be formatted weird if it were on its own is actually formatted well because it exhibits that case's consistency with the other cases in the match. Probably the most important formatting decision they make is to, rather than format a long line, break it into intermediate results and store them in local variables given human-meaningful names.

Many programmers are still committed to manual formatting, or fixed width fonts would have been obsolete already.

Fixed width fonts let you quickly parse syntax. Syntax and semantics are equally important when reading code, whereas semantics are generally the only thing you need for understanding the written language.

That said, I haven't seriously tried programming using variable width fonts; maybe it's a well-kept secret to digesting code. Or maybe it's like Hemp Milk, there's a reason it hasn't caught on.

I don't know if variable width fonts are a help or a disaster but I've been using multiple fonts in a single editor window for quite a while and the productivity boost is huge. My choices are Operator Mono (to typeset keywords and math stuff) and Firecode (to typeset ligatures). You can find my custom Atom stylesheet here if you want to try.

PS: The idea is not mine but I can't remember where I read the instructions about this editor setup, so Google is your friend.

https://gist.githubusercontent.com/diegoperini/853d54c8873e7...

There is actually no evidence for that. Programmers in general seem to be faster with whatever they are used to. I personally have trouble parsing code in fixed width fonts versus proportional ones* because I’m used to the latter and the kerning of fixed width formatting annoys me. Keywords pop out easily with syntax highlighting in any case, making syntax pretty obvious.

* to be fair, I’d have trouble with a bad proportional font like Times New Roman, but I’m sure many would have trouble with Courier New on the other side, the specific font matters.

wait are you saying fixed width fonts are only useful for manual formatting? because I find they make it much easier to read code.

There is no evidence that fixed width fonts have any advantage. It seems to be a matter of just what you are used to.

Fixed width fonts are used for programming because of cargo culting. I tried programming in serif fonts only after a HN comment suggested it (would never have thought of it myself) and it's fantastic. Very readable. They were right.

And you can still manually format code, serif or monospace.

Proportional or monospace font choice is orthogonal to formatting.

(Edited to be more specific)

I prefer a San serif myself.

Mono space allows you to do manual alignment, eg if you want ascii art in your code or non standard formatting. Doing this with a proportional font means other people can’t read your code without using the same font.

Fixed with fonts work well when you are using the alt key to work with multiple lines of code at once. This is especially helpful in the middle ground where the lines of code are similar enough that one can easily use a pattern but the extent needed to be written with that pattern doesn't justify creating some tool to automate writing the code.

I strongly prefer coding in normal fonts instead of typewriter fonts. This is the primary reason that tabs are better than spaces. Working with a proportional width font in a space-indented file is always trying.

Reply on news.ycombinator.com