Open tjstebbing opened 7 years ago
joshgillies
commented
7 years ago I'm literally going to start writing services in python so you all leave me alone ;p
Surely you meant s/python/go ;)
Still, I'm 50/50 with the sentiment of the above comment though. I think code consistency across an Organization is worthwhile, both in style and quality. Linting solves one of those challenges, a good engineering culture solves the other.
SomeoneWeird
commented
7 years ago I was in the same boat as you, it took me ages to stop typing ; because of muscle memory, and to remember to add spaces. Now i'm 6 months into using it for everything (even my personal) stuff and I wouldn't go back.
The reason we do this is not to make it easier for the compiler, but to make it easier for humans to come into a massive codebase (comprised of 100+ repositories) and have them understand it easier because they're all written the same way.
The goal is simple: one way of writing syntax.
It's not that big of a stretch. Python has pep8. Go has fmt. Javascript has standard(?)
Whether or not we want to include semicolons or not, or enforce spaces after function names is a debatable issue that not everyone is going to agree on, but instead of bikeshedding for months on end trying to come up with a conclusion that everyone is happy with, sometimes we just have to make a call.
tjstebbing
commented
7 years ago Ok so we did that with Standard, so by your argument, forking standard is a return to the bike-shedding you wanted to avoid in the first place?
joshgillies
commented
7 years ago SomeoneWeird
commented
7 years ago See my reply to that comment josh just linked :)
@pomke potentially yes. But I've allocated a set timeframe (1m) and that is nearly up, so the bikeshedding won't last forever :p
tjstebbing
commented
7 years ago So lets just not do it at all, stick with Standard as it is, even a month sets a precedent for change.
I'm literally going to start writing services in python so you all leave me alone ;p
Almost everything about standard is a barrier to entry for people both learning JS and existing experienced devs who have their own style. It's also a lazy replacement for good code-review practices and knowledge sharing that used to happen back in the days when code was a craft.
Linters IMO should find bugs like undefined functions, unused imports etc. The computer literally does not give a shit about where your comma is, especially given we're per-compiling all our JS anyway, our coding style is not even what's getting run on the server.
ie:
We currently mandate a space after a function name and before parens:
And in many iflix repos refuse to let the developer push code unless they comply.. the kicker? the pre-compiler strips those spaces out again.
Honestly, nobody in the company gives a @#%^ about that space, it doesn't suddenly make you unable to comprehend the code, but it does add friction when someone gets it wrong and they have to correct it. To what end? really?
I agree we should have some standards but they should be verbal not hard-enforced, and bad programming practice should be spotted in code-review and then explained to the person so they become a better developer through learning, not blindly bashing their head against an angry linter until it passes.. and then having no clue why they should have done it that way at all.
I realise I'm in the minority here, so I dont expect anything to change, but I'd ask that you all consider exactly when linting is a good idea and when it is not a good idea. Given we pre-compile it's (mostly) only having an impact on engineers, and the impact IMO is: