JS Style

It's a JS guidline I prepared for my last company, just to share it and see if it can help any programming nova.

Style and standard


  1. Use lastest widely adopted ESMAScript standard as much as possible.
  2. Node.js use latest LTS for a new project.
  3. Frontend web app must have webpack/bable to illustrate the build (implicit use by framework is acceptable).
  4. Use common Javascript syntax, try not to write domain specific syntax on a non domain specific file. (for example vendor buy in of unnecessary library)
  5. Coding Style and Standard should simply obey to a good coding style and standard unless there is strong reason to do your own, make your CV fancy is not one of them. (Pick Google style by default, documentation can be optional)
  6. Use a linter, don't rely on human eye for such low level and boring task.
  7. Make sure your IDE can see all the lint warning inline. We want it blind you eyes with warning in lifetime.
  8. Debugger should work well too, don't just rely on human eyes and genius mind to debug. Investigate a runtime issue is a dirty work and you won't want to suffer with all other stupid burden on your shouder.
  9. Logging. 'Log' as early and properly as possible, you will regret if you put too many just console.log or hesitate to put any log without console.log. Use any well known logger is always the best and laziest idea. Write your own layer to abstract away the debugger is better but totally optional.
  10. Naming convention. Camel case, not snakecase, kebacase etc unless for referencing the snakecase library (or lodash). Don't use short name unless the short name is well accepted by all human language.
  11. Function name should be as instructive as possible. Parameter should take advantage of JS destructure as much as possible.
  12. Variable should consider and eliminate it's affacting scope.
  13. Local variable should be defined as early as possible without breaking others rules and without performance impact.
  14. Don't argue nor ask why, INDENT by 2 SPACE, no tab character.
  15. Not more than 100 lines for a single function.

Programming Practise:

Semantically correct Module:

A js file, as a module, should only serve a single purpose on certain level of abstraction. It's name should clearly describe what the aspect it's about.

For example, a file with named with "paper-cut" shouldn't do any thing beside cutting paper, it's not it's responsibility to prepare paper, buy a scissors, nor what so ever. The only thing it exposes to outside world, should be a function of cutPaper() when it's definitely an action. In contras, if it's named by "paper-cutter", it should expose a constructor of a class (type), which have a instance method (or prototype method) of cutPaper()

Write good function

When writing function, remember not to share state by mutating any global state nor instance variables.

A function output should always be the output people want, means don't let people even think about leveraging it by it's side effect. Keep it as pure as possible, which mean, with same input always give same output and it shouldn't alter the input. function should be as much context less and state less as it should.

Simple purpose (intentially avoid single purpose here to make it easier to understand) function can help you achieve the goals above. Your function name can only be instructive when the purpose of the function is not complex. For example:

function callMyMotherAndSayHello() {} // No!
function callMyMother() {} // ok

First function implicitly expect the first action will always be success, but what happen if it fail? Say hello to the air? When to say hello, immediately? In what language? If the first function considered and answer all the guesses, it will be extremely big. Therefore we should just take care of callMyMother, and things like sayHello or sayGoodbye, we can keep it in another function. And the major usecase should name with a clear, user related intention and use those functions provided for example contactMother() which make a call to mother and say hello in the beginning.

Another easy way to observe if your function is growthing healthily or not, is the indent level. If your function body consider too many if/else/for/while, it's too big, you should break them down.

Sometime you will still have some logic control function need more if/else/switch than the others. On that case, make sure the focus in that function is mainly about logic, the concrete work should already by moved to another function

In a class, try not to share state with instance variable. Instance variable should capturing dependency, it will enforce us not to keep local state, and things won't be that nasty with local state. A function should  If you need output, 'return' it, if you think it's too big to return properly, so do the function you write. (Consider what actually React's state is, it's not violating the rule)

For any conflict, follow any common practise you can easily find on internet.

Subscribe to TechRD.in

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.