
After 3 Months of JavaScript Linting, It's Pretty Much All Pain and No Gain - PretzelFisch
https://www.bennadel.com/blog/3312-after-3-months-of-javascript-linting-it-s-pretty-much-all-pain-and-no-gain.htm
======
vorpalhex
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.

------
pavel_lishin
> _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.

------
nfriedly
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](https://github.com/prettier/prettier)

------
DavidWoof
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.

------
SirHound
> 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](https://github.com/prettier/prettier)
looks promising, on this topic.

Edit: a rebuttal
[https://news.ycombinator.com/item?id=14921580](https://news.ycombinator.com/item?id=14921580)

~~~
slacka
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.

~~~
nulagrithom
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.

~~~
xaedes
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](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

------
phaedrus
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.

------
WorldMaker
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.

------
throwaway2016a
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.

------
mnm1
"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.

------
tomseldon
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.

------
jbob2000
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.

------
pascalxus
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.

------
Androider
Bind prettier
([https://github.com/prettier/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.

------
bitwize
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.

------
agentultra
... 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.

------
hharnisch
> 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.

------
yarrel
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.

------
bcheung
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.

------
choward
> 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.

------
halis
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+

~~~
thatswrong0
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.

------
jkrems
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.

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

------
lotsoflumens
Yes. This so correct.

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

------
mmargerum
Go fmt

~~~
dangerbird2
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

------
whipoodle
> 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.

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

~~~
whipoodle
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.

~~~
nulagrithom
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.

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

------
hungerstrike
> 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.

~~~
azurelogic
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...

