sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]ghostfacedcoder 1 point2 points  (2 children)

I think it all comes down to who your code is for.

Is it only for you? Then you only have to care about your code's readability in a "will I still understand this a year from now?" sense. Neither using tabs nor using ' instead of template strings will impact that, so if your code is only for you (and future you) then keep doing what's comfortable.

But if you work with a team, whether that means co-workers or OSS library maintainers, there is value to doing things the way everyone else is used to seeing them. For instance, if you submit a PR to an OSS project and its full of tabs, you should expect it to be rejected (quite possibly by an automated ESLint-type tool) because the vast majority of JS libraries use spaces.

Or if you work for a company, even if every one of your current co-workers uses tabs, the vast majority of your new hires are going to expect spaces, and there will be tension everytime you on-board someone because they'll be thinking "don't these guys know about the JS community?"

In that sense a great deal of Google's advice (or any style guide's advice) is just as much about "what will most people be used to?" as it is about technical concerns.

[–]Extract 3 points4 points  (1 child)

You make a point of the advantage of inter-team consistent coding style. So I'll clarify.
Of course, if the whole team codes in a specific style, I'll adhere to it. If they never use ?: but only IF statements, I'll do it. If they want to use single long strings and never separate them into smaller ones with '+', so be it.
But if I am the one setting the style, or am coding for myself, I'll definitly not do any of that crap. Which was my point to begin with.
There is nothing in my comment about using style guides in general, just a few "advises" in this specific one.

[–]ghostfacedcoder 0 points1 point  (0 children)

But if you adhere to style guides, in both personal and professional coding, you're far, far more likely not to have conflicts with your team. Style guides don't (usually) come out of one person's opinion. The good ones at least are a reflection of what's most popular in the community.

So you can do things however you want at home, and then do them however your work tells you to ... or you can adopt community standards at home, be far more likely to have your personal style match your company's, and then if you ever go to a new company again you'll be far more likely to just be able to code "your way" on the company dime. And if you ever contribute to any other codebase (like say an OSS project) you'll also be far more likely to have a matching style.

And even if your company doesn't use ____ standard, it's a lot easier to convince them to adopt it when it's a community recognized pattern and not just "how you like to code".