After 3 Months of JavaScript Linting, It's Pretty Much All Pain and No Gain | Hacker News Reader

After 3 Months of JavaScript Linting, It's Pretty Much All Pain and No Gain

bennadel.com

29 pointsPretzelFisch41 comments

This is a fantastic example of how to not write a blog post. Putting aside the ridiculous self quotes, the author has missed the point and value prop of linting entirely and set up a perfectly silly straw man in it's place.

Linting exists for two reasons: 1. To catch silly mistakes (unused variables) 2. To provide a standard style

In most code bases, and I imagine this is probably true for Invision, code is read much more frequently then it's written. Someone reading my code shouldn't struggle because I prefer tabs or spaces, or because I happen to appreciate an odd spacing scheme. Code should be relatively consistent, expected and non-magical.

Instead this blog post reads like a school kid mad that they have a dress code. There are valid concerns around linting:

+ linting rules can hurt good practices (what makes sense for one codebase may not make sense for all code bases)

+ they require regular review (is this pattern still the best one for the team?)

+ they may be overly designed (and require developers to spend more time fighting whitespace alignment then actually helping readability)

Of course, all of the above are fixable problems. There's no sense in throwing linting out with a ruleset. For most developers linting provides a lot of value in the form of immediate feedback, even if the rulesets used can be flawed.

> Formatting is part of my being - an extension of my genetic makeup. And, when I write code, my formatting is the fingerprint that I leave behind.

I've read so, so many blog posts that all argue that when working on a team, you should not own code. It's the team's code, the app's code, whatever. Don't feel so paternalistic about it.

Don't... don't leave your DNA all over it. I mean, come on, that even sounds gross.

Dude's even inconsistent:

> That said, my approach to code formatting is the best. If it weren't, I wouldn't use it.

> And, as time goes on and I collect more evidence and experiment with new choices, my approach to code formatting will continue to evolve and become more refined.

And, ugh:

> That said, my approach to code formatting is the best. If it weren't, I wouldn't use it.

> Years ago, I was naive enough to try and make an objective case for my design choices - I even used science. But, today, I now realize that, while there is some validity to my argument, personal preference is ultimately the source of Truth on such topics.

This guy seems really, really not fun to work with.

In general, I don't really give a shit about style - I could care less about tabs vs spaces, semicolons vs ASI, etc.

I just want it to be consistent, readable, and not pollute my code reviews with superfluous changes.

So, I prettymuch only use style rules that can be enforced and corrected automatically (usually with `eslint . --fix`). Anything else is just annoying.

I'm also a huge fan of prettier and starting to use it everywhere - https://github.com/prettier/prettier

His examples are kind of strange.

First, I don't really consider const vs let to be the same kind of stylistic rule as single quotes vs. double quotes. Single quotes vs double quotes really don't matter too much. Const vs. let though don't mean the same thing at all, and using them correctly can go a long way to reducing cognitive load. The two keywords simply don't mean the same thing and if his linter is complaining often, it's probably because he doesn't understand the difference.

And if you can't standardize on tabs vs. spaces, you're going to have all sorts of trouble in your commits. This is basic stuff. This article reads like the author has spent his entire career working on individual projects, and doesn't really understand working with a team.

> When I'm asked to change my style, I am - quite literally - asked to deny a fundamental Truth of my being.

Ugh. Come on.

I used to indent with 4 spaces. I lead a team where in the early days I added linting and had to decide one rules. Some of these I felt fine about - semicolons, for instance. But others the team had a fairly unanimous feeling about, 2 spaces being one of them. So I set the linter to 2 spaces, and now that's what I use for everything. I like it.

If we didn't have linting to standardise this and other rules across the codebase, it'd be a mess. It's one thing to be able to identify who's written a thing, but it should be a subtlety in amongst consistency. Not a glaring stylistic mis-match.

https://github.com/prettier/prettier looks promising, on this topic.

Edit: a rebuttal https://news.ycombinator.com/item?id=14921580

Yes, just a kid crying about having to follow style guidelines. If manually running his team's tool is really wasting as much time as he claims, they should switch to a tooling that automatically corrects style. I use tabs, but the policy is spaces. When I commit a change, my my tabs are automatically controverted to spaces. Zero time lost and no one fights about tabs vs spaces.

Just a thought -- it would be neat to see a project that would allow you to check the code out again with your tabs instead of the committed spaces. More of a style translator than an enforcer.

It should be relatively easy to set up with git hooks:

Take one of the many Git Hooked Autoformaters: For example: https://github.com/michalrus/git-hooks-code-autoformat

Then add similar hooks for pulling on "post-merge" and "post-rewrite". There is no hook for "pull" per se, but either a merge or commit rewrite (rebase) happens after pull that changes code. So you should be good with those both hooks

> Yes, just a kid crying about

This breaks the HN guidelines against calling names in arguments, so please don't do that. Your comment would be just fine without the first sentence.

"tabs are automatically controverted to spaces"

I don't know if that was a typo or intentional, but I like it!

I agree. You're a software engineer, not an artist.

Actually, you're both. You're an engineer when you hand your code to the computer to execute. But you are an artist when writing code for others to read. It's not a coincidence that a lot of advice for beginning authors (of novels) is quite similar to advice on writing readable code.

I'm happy to have a standard formatter because it saves me time.

I write my code ignoring indentation and whitespace, then autoformat it moments later.

There's some stuff I have to do myself still, like ordering methods, adding empty lines for readability, and line-breaking string literals and comments.

Totally agree with this article. An Emperor-has-no-clothes situation which baffles me that more programmers don't see as obviously as I do is the following sequence of logic:

1. If the code format check can be automated, then the code format change can be automated.

2. If the code format change can be automated, then the change could be applied as you type, or as the code is loaded.

3. If the format change is applied as the file is loaded, it could just as easily be an editor view-setting, much like syntax highlighting or font size.

4. QED we're collectively wasting time on a lot of pointless B.S. that should just be a checkbox on the Tools... Options menu.

Or to put it another way: the fact that editor background colors, font, and text coloration are not part of plaintext files, but whitespace and line breaks are (and that plaintext files, as opposed to databases, are used to store program code) is an historical accident. One could easily imagine an alternative history in which things played out differently in terms of what is and is not a "view option" vs intrinsic to the source text.

For example, a lot of developers seem to like the white-on-black or "midnight" theme for their IDE; personally, I hate it, and prefer black text on paper-white background. I just thank goodness that that is an editor option, rather than that being encoded by the source file. If it were, maybe we'd have requirements like every source file needs to be on a black background, except for viewmodels which need to use a purple background, etc.

When I'm not forced to use a coding standard, I use line breaks, spacing, etc. to communicate whatever I think is important about a particular section of code, rather than following a prescribed format mechanically. Indeed, breaking style in a particular section can be used to show "hey, something different is happening here".

However, if people are going to get pedantic about style choices which have no effect on compiler parsing or output, I would gladly trade away this freedom of expression in return to gain freedom from code-formatting-busywork by making all of these formatting choices be part of the editor view options. Then if a busybody has an opinion about non-functional source formatting, let him change the settings on his own IDE.

"my approach to code formatting is the best. If it weren't, I wouldn't use it. Formatting is part of my being - an extension of my genetic makeup. And, when I write code, my formatting is the fingerprint that I leave behind. When I'm asked to change my style, I am - quite literally - asked to deny a fundamental Truth of my being."

This is some seriously arrogant, even anti-social (coding) shit. I'm sure his approach is the best. And the next person will say the same. Pretty soon, you're stuck because you can't agree on style and you've wasted all the time debating style. Get an automated formatter and be done with it. Or do it manually in a consistent style. Such arrogant attitudes don't belong anywhere in the professional world. Imagine if people said that about blueprints and CAD drawings. Nothing would ever get built.

Something I think that programmers don't always appreciate is that linting isn't an either/or proposition necessarily. A linter is exactly like the spelling/grammar checker in your word processor. It's there to advise you. It's not always right, and it's often a distraction to what your actual goal is (telling a story, etc).

Common advice among writers is: for the first draft, turn off spelling/grammar checks. Ignore the distraction to focus on the important bits (the plot arc). When it is time to polish, then turn them back on.

I've seen too many teams that don't trust linters and have them entirely off, because they find it too much of a distraction.

I've seen too many teams that get hobbled in the minutiae of linters and mandate that a linter be on 100% of the time, that every last rule of the linter be 100% followed, that linter advisement/warnings should be taken as gospel and break the build.

Absolutely don't use a linter if you don't think it is helping you and you don't like the advice it gives. On the flipside, don't treat a linter as gospel, not just because there are many ways to style something and have it be readable/useful, but also because it distracts sometimes from the actual importance of the work (building working coed), and sometimes the creativity (creative styling used sparingly can enhance the code's readability; just as creative spellings or intentional grammar breaks can be useful in a work of fiction). It's easy to forget that programming is a creative act and that people aren't machines and don't need to follow every rule to a T every time.

I treat linters as a weirdly pedantic code review friend. I tell it to go away if it is bugging me and I'm trying to focus. I take it's advice with a grain of salt, and I use my own human judgment sometimes.

I understand why teams make lint errors build problems, and invite linter checks directly into their PR reviews, but that's not something I care to do in my own projects. Being a slave to a linter dehumanizes the experience of a programmer, and sometimes as programmers we deride the creative chaotic mess that a linter prevents, but that chaotic mess is sometimes art and poetry, too.

Linting not only addresses syntax but also addresses a lot of other issues:

- Unused variables (more often an error than not)

- Redefining the same variable name twice

- Having a class method that doesn't use the "this" keyword (usually a logical error)

I think it is worth keeping those kind of rules on even if you turn off ones like how many spaces at the start of the line.

Linting also isn't just for you. It is for the other people on the team so that they don't have to deal with the B.S. of either "fixing" the 50 lines of code you indented with tabs or dealing with multiple styles in the same file.

Although it is a good point that linters could just fix the formatting rather than just complain for a lot of issues.

Although coincidentally when I started using the AirBnB style guide, it corresponded almost identically to the style I was already using so the shock wasn't there.

The author clearly has a hacker "get shit done" kind of mentality and to an extent I love that. But it would drive me nuts if he was on my team.

I disagree that there's no positive effect. A difference in code styles can introduce cognitive load, though naturally the actual effect will depend on the individuals involved, and the actual differences (for some, I agree it could be a non-issue).

> Hopefully, you feel as passionately as I do about your own stylistic choices. My approach works best for me; but, it's not for everyone. And, clearly, other people's choices don't thrill me. It's a completely subjective matter.

I do not. I do have preferences, but I'll let them go quickly in favour of following a standard convention for a given project. I care more about consistency than my own subjective opinions on code style.

I would agree that manual code style checking is painful. I've previously used jslint, eslint, tslint, etc. and I always forgot to run it locally, and then get frustrated when it inevitably failed during CI. There's tooling to address that (syntax highlighting in editors, git hooks, etc.) but it doesn't completely alleviate the problem.

Personally, I quickly adapted and the initial friction of adjusting my workflow (and co-workers theirs) meant a more consistent code base. I was pretty happy with that.

Lately, I've been using Prettier.js that runs on save, and frankly I think it's fantastic. I don't always agree with the specific format it's chosen, and there's at least a few things it doesn't handle (e.g. superfluous new lines), but for the most part I no longer need to think about what my code looks like (stylistically, anyway).

A lot less cognitive load, more consistent code base.

You are lucky that you work with talented and engaged people. I had to bring in a linter at my new job because my coworkers were incredibly lazy about their code. No indenting at all, or the indenting is all mixed up and they didn't care to fix it. They would commit completely broken javascript without testing it.

I stand by linting for development teams that don't have the luxury of good talent.

Fundamentally, the big problem is, most engineers don't understand opportunity cost. So, whenever a new review tool comes along, we always say: yes! let's do that because only good things can come from it. And, that's simply not true. You always need to evaluate the benefits vs the cost - the cost being your time. Spending all day, replacing quotation marks and other arbitrary coding style won't help much.

You gotta remember, coding quality is not something you increase just for it's own sake. the whole purpose of increasing code quality, is to increase future productivity. Any process or decision you add to your coding process, should reflect positively on those goals.

Bind prettier (https://github.com/prettier/prettier) to run on your editor/IDE "Reformat code" shortcut. Follow the github page to add the automatic git pre-commit hook. Add eslint-config-prettier if desired. Done. No more bikeshedding.

You'll be in good company, with React, Babel, Yarn, Webpack etc.

And just use const by default. Let/var is a warning sign that side effects are happening, like a traffic warning to slow down and stay alert.

Suck it up. Either set your IDE to conform to the house style whatever that may be, or deal with the drubbing in code reviews and, by extension, negative marks on your performance evaluation.

... but there's a semantic difference between `const` and `let`...

The least interesting component of style is syntax and form. Therefore use tooling to eliminate such concerns from your code. Javascript is a syntactic mess with ASI, braces, indentation. Linters remove such concerns.

The important components of style are preference to declarative vs. imperative code, heavy use of `class`, the `prototype` chain, or preferring function composition and purity. These are the concerns your style guide should be focused on.

Javascript, like C++, is what I call a kitchen sink language. If you use all of it your code will be a frightening mess to maintain. Choose to use a subset of the features and stick to it.

> I am talking solely about stylistic rules. Tabs vs. Spaces. Const vs. Let. Single quotes vs. Double quotes - that sort of thing

let vs const is not stylistic - they mean different things and V8 can optimize for them differently.

JS linters catch sources of bugs. That's a gain.

A standard style makes code easier to read across a codebase. This makes the code easier to understand and easier to find bugs in.

So no.

100% agree with this. I relax a lot of the rules for my personal projects. I want linting to tell me when there is a potential problem. Other than that it just slows me down.

If a computer can lint it, it can also beautify it. Leave me alone and take care of it for me automatically.

Stop wasting my time and breaking builds because I forgot a comma after the last key in an object and dumb stuff like that.

> there's no real value in [linting]. Because, the choices that can be controlled by a linter are, ultimately, not the choices that matter.

Interesting. He says there is no value in linting and then follows it up with the main value of linting. You're right, they aren't the choices that matter. That's why I don't want to waste time thinking about them.

We're using prettier on a project at work. I was reluctant, I thought that there would be lots of bugs and mangled code, but it has been wonderful.

We run eslint with the fix option and prettier all in one command. It even formats JSON that you paste in for a test and changes the quotes to your preferred quote.

A+

I introduced Prettier at work because I got rather sick of seeing poorly formatted code strewn about.. it is indeed wonderful. I don't want me or my coworkers to have the freedom to write weirdly formatted or bad looking code - reading and understanding other people's code is hard enough even if it's perfectly formatted.

More importantly, Prettier + ESLint fix on save makes coding quicker! I don't have to waste time getting things lined up any more.. I just write write write awful looking code and on save.. boom! it looks nice.

You're not writing a novel, you're not painting a picture.. you're writing code that _I'm_ going to have to read, understand, and modify at some point. Having a consistent style and enforced line lengths makes my job easier. Don't make my job harder just because you want some extra freedom to make your code look weird.

I have no idea what this author is going on about.

The value linters should (hopefully) provide is to keep code reviews focussed on actually important things instead of having to renegotiate naming, spacing, and other "arbitrary" things. Also, a decent linter for JavaScript will detect some obviously buggy code.

I've never disagreed with a title of HN subject stronger in my life.

Yes. This so correct.

Linting efficacy is one of the many myths about software quality and team efficiency that abound in this industry.

Go fmt

And clang-format for c/c++/java/js/typescript. Tools like these are fast enough to be hooked to version control commits, and even on save

> Hopefully, you feel as passionately as I do about your own stylistic choices.

Nooooo. No. Hopefully the exact opposite. The correct feeling about this is, let's pick a style and move on. Ideally there's a tool that just formats the code according to the style so coders don't even have to do it.

Arguing about style details is absolutely one of the least productive possible things a programming team could do. It's aggravating and pointless. Getting upset that your pet style rule isn't in the official style is egotistical and childish. Code that way on your GitHub when you're not working, if it's so important to you.

This is one thing Go got right.

Note how he explicitly recognizes how everybody has their own best style. Nowhere does he encourage arguing about style details.

I just think it's silly. It's a silly thing to get attached to or care about. The code just needs to be legible and consistent.

Consistent is a big one.

Imagine every time you reach for a module in your codebase you have to remember that Joe came from C# so he likes to use PascalCase for his methods instead of camelCase like the majority of JS libraries. And John likes Snake_case for his classes because he came from PHP and that seems more natural to him.

I've been in that environment. It will make you tear your hair out in a week.

(Just don't mention PHP has this in spades, people hate when you point that out.)

> Three months ago, I joined an internal team that uses the JavaScript linting library, Standard.js.

My life got so much better when I started avoiding taking jobs with people who make bad decisions.

Using Standard.js is a huge red-flag for me. If you think leaving semi-colons out of Javascript is a good idea then I can only deduce that you value style over functionality and complexity over simplicity.

Thank you. I still have this argument with people today. I think it's laziness for many devs. ASI is an _error correction mechanism_ that Eich added because there was no compile step in JS in 1995. It helped people ship code without having to spend forever tracking down missed semicolons or worry about getting bit by one in an undertested code path. It is part of the language. If you hate semicolons that much, go write VB/Ruby/Python...

Reply on news.ycombinator.com