Summary 📑
Soft tabs with two spaces
Never use semicolons
Always use single quotes
Keep else in the same line of closure of the if
Add...
For further actions, you may consider blocking this person and/or reporting abuse
Couple of things:
const msg = "Why wouldn't I?";.const msg2 = 'Must I suffer because of someone else\'s preference by escaping the single quote everywhere?';thiskeyword. So no to that one too.That's me. Problematic guy for sure. 😄
You can also use template literals instead, if you need to use single or double quotes in a string.
How about using correct characters instead?
I can't add too much to the code formatting question, because I use Prettier, which does the job. I think I use two spaces then Prettier does it better:) I never thought about it, it's in the muscle memory:)
The arrow function thing is interesting. The reason, why these were introduced to ES6, is that they do not bind the value of 'this' but inherit it. I have tiny code sample to show this in the arrow-function-example repository. The important point is that in some cases you should use arrow functions if you want to avoid binding 'this' explicitly in a regular function. It was important for some cases for event handling in React class components. Function components behave differently, so it's not so important in modern React. There are other cases, when you can't use arrow functions for the same reason. I met some cases when I used mongoose. There are cases, when arrow functions do not cause error, but not recommended for efficiency reasons. For example arrow functions shouldn't be used as methods in ES6 classes, because they become instance methods instead of prototype methods. In practice it means if you had 100 instances of the same objects the method is stored in the memory in all the 100 instances in the case of arrow function. In the case of the regular function the method is only stored once in the prototype object.
It's been years and I have yet to see anyone make a coherent argument for spaces, or to even address the multitude of reasons why tabs are objectively better for indentation.
At this point I'm starting to think it's just clueless programmers intentionally placing hints in their code that it's not worth reading.
Every now and then you need semicolons to disambiguate your code though. "Never" and "Always" rules are just dumb. Know the language, and know when you need to use them, otherwise don't.
Quote styles is the dumbest red herring one could come up with. Who cares. Just be reasonably consistent within files and no sane person will care about it.
Just avoid short names in general;
queryis still a bit short for my taste; it doesn't tell me what is being queried. The builtin browser APIs are doing this right:document.querySelectorAlltells you everything you need to know, even if you don't know that particular function.Again, this is a really dumb rule. Use whichever you need. Sometimes you may want
==, or you may know your input types.I despise people who do this. It works for short conditions, like
1and2, but for longer expressions, it just makes the code much harder to read for no reason whatsoever. It's just making people's lives harder.I like this example because it perfectly encapsulates why this sort of thing usually isn't a matter of how you format your code, but of how it's structured. Here's a better way of doing the same thing:
All in all, these style guides always make me think if people put any degree of thought into how appropriate they are for collaborative projects, or just note down their personal preferred code style to lend it legitimacy and to push it onto others.
Tabs FTW 👍
Anything is fine with me, but a big, big, big no to tabs for indenting!
Do anything you want, I don't care, but tabs for indenting (or using any kind of non-printable characters in source code for that matter, except for linefeeds) are such a huge no-no for me.
...so you don't use spaces in your source code either?
Spaces are printable, I can clearly count the number of spaces (15) in this sentence :)
Here, count these:
What do I do If I am ugly ?
You compensate by writing pretty code instead, starting with using tabs 😉 😝
Tabs are the incarnation from hell. Tabs makes your code look one way in editor A, but another way in editor B. Spaces is the only sane option! 😡
There is exactly one person who has any business deciding what indentation level any code appears in in my editor, and that's me.
Everyone else has exactly the same authority over my preferred indentation level as over my colour theme. That's the whole point of tabs: You don't have to read my code in 3-space indentation if you don't want to, and I don't have to read yours in whatever you prefer.
Arguing for spaces is really just trying to shove ones preferred indentation level down everyone else's throat.
And I'm sorry but the "I'm too dumb to configure my editor" argument just doesn't make sense. Any modern code editor will let you change your tab width. This is extremely silly.
I agree with your point in theory, but tooling in real life is not always helpful. You don't always have the ability to set your tab size in a tool. Spaces is the only sane path.
Call me idealistic, but I don't think bad tools should be an excuse for bad practices. It's the tools that need to change, not the code.
While I agree with most of the rules you included, this is highly opiniated and just your style, which you shouldn't impose upon others (I feel that's implied from "if you're beautiful"). Some things are 100% up to the programmer's personal taste, e.g. whether to use double quotes or semi colons.
I think one thing lacking from this article is why. Why should I follow those guidelines, and what benefits are there? Sure, I believe you should have meaningful variable names and spaces between operators, but does it actually matter whether you use double quotes or not? I feel like this guideline was formed solely for your visual pleasure in "beautifully formatted code".
Besides that, I think you could have simply left the article to Prettier or something. Just type your code and have Prettier do the annoying formatting for you. I like their presets anyways.
P.S. What do you have against functional declarations? In my opinion declaring the function as an expression looks really ugly and should only be done for arrow functions.
I'll let semicolon as an option for the dev. About the rest, i'm agree with @brense about keeping a clear idea of what we're doing using both function keyword and getting the expressions into const. Good post btw 😁!
Not bad
I also use air-bnb style guide
Single quotes for strings is an aberration. In C, a char array would use double quotes and a single character would use single quotes. It matters a lot as they are 2 completely different definitions (zero ended uint8 array vs uint8).
If you are a decent old-school programmer, you will NEVER use single quotes for strings. The same for the semicolon. Optional semicolon is also an aberration decision for JS and not using it denotes a genZ that only knows JS, Python and maybe Java because of high school.
Damn late millenials... [Insert old man yelling at clouds gif here]
Agree with everything except function expressions instead of declarations. Being concise is always better imho and using the
functionkeyword is clearer than turning everything into an expression and assigning to const. Besides that, function declarations are also functionally different from function expressions in terms of scope.Great article though, with good examples! 👍
Two spaces aren’t enough for readability. It’s a legacy code style from the bad old days of extremely nested callbacks.
Function expressions are ugly, verbose and unnecessary. Just use
function foo() {/*...*/}at the top level. There's probably a good case for using function expressions where you need functions inside functions; in that case, use an arrow function to avoidthisissues.I am waiting for the post author to reply to the strong comments made by community members here. Let's see.
I just clicked this article thanks to DEV's newsletter they share (I don't know how they pick the articles) and was instantly in doubt as to how "If you are beautiful" and "follow this JS code style" can be together.
I skimmed for like 5 seconds and ranked it as a low-quality article as a DEV mod. I will be happy to change it to high-quality if I see some hard work in this piece.
You should start using the semicolon
I strongly disagree with the semicolon and the 2 spaces rule.
For me, semicolons making the code much more readable and organised as well as 4 spaces tabs. I find 2 spaces make the code too cluttered and compressed. But well as always, its a personal preference. :)
One addition which helps to implement this is to use prettier extension for VSCode. You can configure prettier to take care of the above mentioned rules and this will help greatly.
On frontend stuff, when I use 4 space tabs for my code and especially for the markup part, the code goes all the way to the other side of an IMAX screen.
If it weren't for that I wouldn't mind... but then again... it's just easier to go with 2 for everything.
Since there's an extension (hidden preference) for basically anything, I'm wondering if there's one to make 2 spaces look like 4 (and vice versa).
Those are the best teachers.
They slap you in the face,
and never explain WHY you did it wrong.
Who says 4 spaces is wrong and 2 spaces is correct, or that we shouldn't use semicolons? Totally arbitrary.
Young people that don't have eye problems... Then around 40 years old their eyes are not what they used to be and they need more than that measly 2 spaces to read the code properly. But then it would invalidate their crusade for the last 20 years so they keep repeating the dogma to justify their existence... 😒
I'm a big fan of not using semicolons unless absolutely necessary because it's been proven times and times again that less noise in the code is better. It's a matter of eye pattern and keeping the attention of the dev on what matters. Semicolons mostly don't matter anymore and Prettier will add them when absolutely necessary.
It's all about accessibility and readability for everyone.
But... obviously, it's not a huge problem either. I've been in projects that used semicolons everywhere and it works just fine. The mental load of having semicolons is not problematic enough to make it a hill to die on... So even though there are benefits in avoiding semicolons unless necessary, realistically speaking I wouldn't impose it on people if they really hate it.
There is two "standards" in javascript "standard" and "air-bnb". Use one or a variant of it but make the linter enforce these rules for everybody working on a project. I don't want a 1000+ line commit because all lines was suffixed with semicolons or the other way around. Any style I would call ugly is an unlinted frankensteinian stackoverflow cut and paste bonanza where you mix and match every and no style.
theres also John Papa... I think even John Papa gave up on adding extra spaces everywhere possible though, so thats good. Guess hes pretty mainstream now :P
Been using all of these methods thanks to @antfu's eslint config :)
First time seeing about the 2 tabs, good to know it.
But I love new Array() 😢