Hacker News Reader

Comment by crehn | Hacker News Reader

Nowadays I couldn't care less about what style is used. As long as the code is consistent and there's an easy way to adhere (clang-format, black, prettier, etc.) I'm happy.

View on HN

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.

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.

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.

Sign of an experienced architect. Read: "I'm old and too tired to argue, just don't break it ok."

I'm 32 and I feel like I'm already at that stage sometimes. What will I be like when I'm 50?

Better.

I'm 70, push out production code every day (Horstmann style https://en.wikipedia.org/wiki/Indentation_style#Horstmann_st...), and I'm having the time of my life.

Horstmann style looks like my ideal, but there's very little tool support for it, from what I've seen. For instance, if I want to swap the first two lines of an "if" statement, I can't use "line-based" copy/paste. Do you do things manually, or does your editor support it fairly well?

EDIT: looks like the tool support is so bad, Horstmann himself pretty much gave up: http://horstmann.com/unblog/2010-06-28/braces.html

Consistency is key. Follow the style that the code already uses. For new apps, I make sure the team has the same style template and use the editor to format the page.

At the end of the day, it is important that the code looks like it was written by one consistent person and not 20 random different people.

Unless the code you're working on combines different styles not only in the same project bet even in the same file.

pet peeve #1 right here.

I really don't like the mandatory use of eslint (used as style enforcement), prettier, etc. When used as a bat to hit developers over the head, all this tells me is that the organization has too many anti-social developers that can't check their ego at the door.

Often someone will recommend a tool or technology in place of simple social common sense. If a developer can't follow the existing code style, they should be shunned. It's their problem. It's not a problem to solve with a fancy tool. You solve this particular problem by telling that person that they are an asshole. Using technology to solve social problems just exacerbates the problem.

All of that leads to a situation where we can't have nice things. You go into a codebase and see hundreds of exceptions to turn off eslint or whatever. Instead of just working around one-off style exceptions with common sense (who really gives a damn if a line needs broken/indented a certain way for a specific function) you have to plead with the style cops to let you off each and every time.

Developers really hate each other. Small organizations or teams tend to be a bit better in my experience. There is more camaraderie. But I often feel like I'm in a group of mercenaries, each ready to stab you in the back.

Linters save so much formatting time, I don't really see what it has to do with ego.

I certainly could go through and make sure all the spacing is exactly right, the functions/properties are in the right place, and rest of the rules of the styleguide are followed. But it's much easier to do when you get a warning, squiggly, or can use an autoformatter to match the rules.

I would never intentionally violate a rule, but I might forget a rule or miss a violation. With linters this is not an issue, the machine will let you know.

Everyone can focus on the correctness and quality of code and let the machine worry about making sure everything is formatted correctly.

Clearly the project you describe, where linting is disabled every other line is bad. But I wouldn't blame the linter for that. I don't know what can be done if a team has such a commitment to their own style that they put in the extra work to disable the linter.

A linter is not a tool for punishing people who violate a style guide, it's an assistant for people who are trying to follow a style guide.

I don't think even you believes that. You're telling me you would be "happy" if every source file was one line?

Just replace "style" with "half reasonable style".

Lint to personally preferred style on checkout. Lint to project style on checkin. Not a problem.

Do you actually do this? From what I hear (and this makes sense from what I know about formatting/parsing algorithms) it's a huge pain, and not implemented for many languages.

I have my IDE do all the formatting every time I close something and rarely personally intervene.

That's easyish: it's a one-way street. The OP imagined something where everyone checks out code in whatever state it's in, applies their own system, then transforms it back, with no artifacts. That's hard.

Same here, with a twist: the test suite does: global reformat (uncrustify or astyle, depending on the team), build, run the actual tests. As people almost always run the test suite before checking code in, all the project stays properly formatted.

My experience is: each time a team started doing this, all coding-style related discussions vanished, and it became a non-issue. It turns out it's a lot easier to accept a coding style you're not the one doing the actual formatting (this is why, BTW, I think stylechecking hooks alone are a bad idea).

Reply on news.ycombinator.com