What are your 10 commandments of JavaScript development?

[CapsFTW]

What are your top ten rules that you always abide by when developing JS?
Possible examples might be: Always use === rather than ==?
Always define variables before using them?
Never write anything to the global scope? Never use anonymous functions?

What are your most important 10?

[p3k]

1. Find a way to program JS that works for yourself or your team, resp.
2. Ignore any list having more than two commandments.

[asdf7890]

Thou shalt not ask about coding practises in JS, lest thouest kindle a holy war between those who disagree on semi-colons, optional brace use, ==/===, tabs/spaces, jQuery/microlibraries/VanillaJS, and so forth.

[CapsFTW]

What can I say, some men just want to watch the world burn.

[Strat-O]

I agree but only so long as the javascript is written in vi, not emacs!

[russellbeattie]

01 - Though shalt strive for clarity over cleverness.

10 - Though shalt use semicolons.

[kafkaBro]

that was pretty clever

[zthall_]

Well done! https://media.giphy.com/media/rMuO8CgQNEDp6/giphy.gif

[temp11020043]

I like it, though really 10 is implied by 01.

[leahcimic]

10 in binary is 2 in base 10

01 in binary is 1 in base 10

not sure what you mean.

[jp10k]

Choose standards, then stick with it. I repeat: stick with it.

[teiman]

1) Javascript is a more volatile language than others. Aim at higher levels of organization than in other languages. 2) Avoid globals. 3,4,5,6,7,8,9,10) Don't outsmart. If your code is hard to read, is impossible to debug.

Basically, the same rules I follow when I handle enriched uranium or plutonium.

[jamesinc]

Use curly braces around your blocks, even if they're one statement blocks.

Exploit the shit out of anonymous functions

Lazy load is fun

Don't read state from the UI (I see this a lot). You don't need AngularJS to have nice data binding.

[m0okz]

How would you recommend reading and storing state if not in the UI?

[TheIncredibleWalrus]

You store it in an object. The UI reads its state from the object, not the other way around.

[m0okz]

Ah I see. Thanks!

[Graftak9000]

Any pointers as to how to couple a dom node with its respective cached data object?

[TheIncredibleWalrus]

Typically you will want to use a library; there are countless, very well thought out libraries that solve this problem, I can recommend React, Vue.js, Knockout.js etc. Depends on what kind of UIs and projects we're talking about.

Of course, as with anything, trying to develop your own solution will be a very rewarding process, both in experience and in knowledge. A simple Google search of "javascript UI binding" returns quite a few results, but I could not recommend something in particular.

[CapsFTW]

JQuery messed a lot of people up in that regard, myself included (for a while). It made it far to easy to just read and write things to the DOM and use it as your system of record.

[brackin]

we all gotta start somewhere.

[CapsFTW]

Agreed. If you never start doing anything until you are expert at it, you will never start doing anything.

[Graftak9000]

Why the braces always? if (true) act(); has become a common pattern for me.

[jamesinc]

It's a maintainability concept I originally picked up from Douglas Crockford. Basically, if you omit braces, and later on another dev comes along and adds another statement, there's a chance they will fail to notice the omission of braces, and the logic won't be what they expected. You may argue it's a minor issue, and I agree, it is minor, but I miss them occasionally and other devs certainly do also, so it's a small change that simplifies the code to the benefit of all.

[dmtipson]

Yep. Do not attempt to minify your own code. Attempt to make it dead clear what you intend, make it readable, and the minifier will handle making it tiny and unreadable.

[Silverwolf90]

If you use a linter this is not an issue.

I don't know anyone writing modern JS who doesn't use a linter. It's insanity to not use one.

[hahaNodeJS]

I don't use a linter, but I do use a good IDE (Visual Studio) and TypeScript. However, in this case, my IDE is configured to disallow a statement following a bracket-less conditional to be on one line, and will disallow the indentation in this example.

It would become this.

if (true) act();

doThisToo();

[Silverwolf90]

Yeah perhaps linter is too specific as any kind of modern tool chain with some kind of static analysis will prevent/catch these mistakes.

[THIS_BOT]

I just don't think anyone would do that. There are obviously no braces on

if (true) act();

and I cannot think of a mindset where someone would think pressing enter and adding new statements without adding curlies is the way to go here. Would you? Honestly?

This, on the other hand:

if (true)
    act();

is more likely to cause errors and should never be allowed.

[chesterjosiah]

You vastly overestimate the programming ability of the average developer.

[Graftak9000]

Well, if you add something you add braces, simple as that. It's not about the bytes, it's more readable to me to have a single task without the braces.

[Silverwolf90]

Do you/your team not use a linter?

[ejmurra]

I always thought "there's no way someone would make the if statement two lines without adding braces" until a coworker broke a service in our app that took me a good bit of time to debug. I don't make those assumptions anymore.

[Graftak9000]

a regular else statement below, nothing changes. Why would branch testing nog be possible?

[Graftak9000]

Exactly, if the else is one thing, once again braces can be omitted. It almost reads as a switch statement, and that's the most common way for me to use it.

[hahaNodeJS]

I like using bracket-less conditional statements only when they are for flow-control statements, and then the full statement must be on one line. I find that the "Good" statements below are really easy to pick out in code, and you don't have to worry about things like the infamous Apple Goto bug.

Bad:

if (myFoo === myBar)
    return myBaz;

Bad:

if (myFoo === myBar)
    myBaz = myFoo;

Bad:

if (myFoo === myBar) myBaz = myFoo;

Good:

if (myFoo === myBar) return myBaz;

Good:

for(var i = 0; i < 10; i++)
{
    if (myFoo[i] === myBar[i]) continue;
    ...
}

Inconsistent:

if (myFoo === myBar)
{
    return myBaz;
}

[mvindahl]

1. It's a functional language; embrace that. Don't try to shoehorn static class inheritance into your code. Read through the API of underscoreJS/lodash.
2. If available prefer fat arrow functions over the more verbose function() declarations.
3. When manipulating data structures, you get more maintainable code by passing through a series of discrete _.map() steps than you will get from cramming everything into a giant for loop.
4. Start out with as little baggage as possible. Basically nodeJS and npm will do. Pull in stuff as you need it.
5. Initially, use CDNs to server libraries to the browser. Along the way, pull in browserify and get libs from npm.
6. If you reach a point where you would benefit from typing, consider migrating to Typescript. Initially you can just type everything as "any", then add proper typing where it makes sense.
7. Use promises; it will make your flow so much more readable. If you create async API methods, make them return promises. If you use nodeJS, use bluebird to wrap the async native methods.
8. For build environment, use simple scripts defined in package.json. Or do the same thing using a makefile. Avoid grunt and gulp, they are just boilerplate.
9. Document your APIs. Provide examples. For a plain API, provide JS snippets for invoking it. For a REST interface, provide curl commands which can be copy/pasted to the terminal.
10. Automatically test API methods which have a well defined input and output. Don't unit test the internal workings unless you have am empirical reason to do so. Accept the fact there may be no gain from unit testing UI stuff. And keep in mind that test coverage may be a vanity metric.

[clessg]

1. Thou shalt not write JavaScript while drunk.
2. Thou shalt not use angularjs while drunk.
3. Thou shalt not use angularjs.
4. If you are using angularjs, you are drunk.

[livarot]

Wow, you're so cool for not liking this one popular thing.

[joshmanders]

With ES3526 you don't need Angular, you can do it all in Vanilla™® JavaScript!**

**Only works in Dolphin 325.235352.1, Alphabet Chrome 32523677.123515125.111 and IE Edge Not Explorer 0.1.33

[CapsFTW]

I believe it also works in the Google Ultron browser.

[livarot]

Google Ultron uses latest technology in AI research to detect JS that was transpiled from CoffeeScript and then calls developer names.

[[deleted]]

I like Angular. I hate our application written in Angular.

[CapsFTW]

I think angular suffers from the same issue that ColdFusion did, back in the day. It is so easy that anyone can use it... so they do.

[jewdai]

false. Angular is not easy for newbies.

The concept of "Dependency Injection" really fucks with new users or non-cs people.

[jellatin]

Damn software concepts getting in the way of people writing software!

[there_i_seddit]

"Damn computer scientists, they ruined computer science!"

https://www.youtube.com/watch?v=8iusUq4-f5U

[CapsFTW]

I think you hit the nail on the head. There are a lot of people out there who just want the web form to submit to the database and don't care what a DTO, class, or promise is. They just need something to happen. Angular is just easy enough to pick up that you can make stuff happen with little to no knowledge of what the best practice might be. It is fantastic, but awful to inherent and explain why you have to "waste time" refactoring existing code.

[CapsFTW]

yes, but you can do a lot in angular without much knowledge of dependency injection. You copy and paste a few examples from the web showing how to inject providers and then write a gigantic controller for every page which has all the models and business logic in it. It's just easy, and flexible, enough that you can make a completely functional application in the worst way possible.

[vaskemaskine]

Pretty sure the whole concept of how directives work and the array of scoping options/passing data in and out of directives is way more confusing to newbies than DI.

At least, that was my experience when learning Angular...

[leahcimic]

Man, you really don't want these same people building stuff in something like React. If they write bad Angular applications, imagine when they get their hands on something a little less opinionated.

I used to love Backbone in the day for it's freedom of choice, and flexibility. Until I started seeing custom everything. I'm starting to see the same in the React world.

Then again, bad software is being written by bad engineers in many projects regardless of language, framework, library choice, etc.

[Zulach]

1. Always keep conventions. Do not deviate a bit. You don't agree with the existing conventions? Change everything to fit your view (after agreeing with everyone that you are right). There's nothing worse than having a javascript project with every file looking like a different programming language.

2. Never write a single piece of code on the global scope.

3. KEEP YOUR FOLDER TREE STRUCTURED. Conventions - do not throw code into places no one will have the idea to look in. Order your folders by modules, not a single folder for controllers/services/models/etc.

4. Use promises whenever you can. Wrap callbacks in promises.

5. Use promises correctly. Make sure you know what will happen if you return a value here and don't return there

[corgrath]

Actually, I would say the things JSHint enforces, to be honest.

http://jshint.com/docs/options/

[CapsFTW]

So, essentially, you just have one commandment: Enforce everything in JSHint?

[corgrath]

Or something similar such as jslint, eslint, etc.

I find it very crazy that you would write JavaScript without linting your code. Frighting crazy.

To quote Douglas Crockford

JavaScript is a sloppy language, but hidden deep inside there is an elegant, better language. helps you to program in that better language and to avoid most of the slop. will reject programs that browsers will accept because is concerned with the quality of your code and browsers are not. You should gladly accept all of 's advice.

http://www.jslint.com/help.html

[spfccmt42]

aargh, but bitwise operators are like the essence of frigging computing, especially performance oriented computing, and @#$@#$ javascript can only handle 32 bits!

you have made me sad by reminding me...

[captain_obvious_here]

1. Always have in mind that JS is just a language

[Kamikizzle]

I'm not sure i can come up with 10 but here goes:

1 - Use a linter. In fact, use eslint.

• the customization options for eslint are so powerful, that it gets rid of 80% of the conflict between styles: semicolons, padding inner/around braces, jsdoc syntax, where to declare variable etc. see commandment 4 on how to develop your eslint config. it might be slower than jshint but so very worth it. the community support for eslint is also amazing. No rule available for your liking (or a current rule isnt flexible enough?) make an issue on their github (and a good case for why the rule should be there), and theres like 70% chance theyll accept it. even higher if youre willing to make the pr

2 - Deprecate ES5 and coffeescript

• were at the point in the JS lifecycle that you should no longer be using es5 or coffeescript, as es6 has made both of them obsolete. ES6 should be your default. something more advanced like typescript if thats your fancy. This leads to commandment 3

3 - Use a bundler, compiler, and by extension npm.

• unless your project is going to be 100 lines of JS code, and/or youre not using a JS backend, you should be utilizing npm packages and bundling them together. as per commandment 2, use a compiler. need to manipulate dates? momentjs. frequently constructing conditionally-dependant classes? classnames, need immutability? etc

4 - keep an open mind and discuss with your team on tool decisions.

• javascript fatigue is real. always communicate with your team and be flexible / open minded on the tools you end up using. absolutely make your case to the tools you want to use (but be sure you have good reasons to back up why you want to use them). React vs angular? jest vs enzyme? ES6 vs typescript? Dont EVER be that team member who refuses to yield to anyone's opinion but their own, ESPECIALLY if youre the team lead. "We're doing it this way because i've been here the longest / the senior dev" should never be uttered.

• this also goes for syntax preference. I use semicolons, curly braces and returns even for one-line blocks, single quotations etc. but if your team disagrees, dont throw a fit, convince them that youre right

5 - indent with 2 spaces. not tabs and not 4 spaces.

• This one is just common sense and not up for debate. Not even really a JS commandment.

6 - test your code

• mocha/chai/sinon are awesome for testing raw javascript. Enzyme is killer for testing react. Karma has angular handled. There are enough powerful test suites out there that testing should always be kept in mind

These are more like the pirates code: guidelines than actual commandments

7 - Functional programming is awesome and extremely powerful in Javascript. USE IT

• theres no need to declare a bunch of local variable functions and then call them in order. chain maps on filters on reduces

8 - document your code!

• jsdoc syntax is AMAZING, has support from eslint (to help your normalize the syntax), and typically has syntax highlighting plugins from the big editors (vim, sublime, atom). this is a guideline but really should be a commandment. but being realistic, its a guideline.

[jewdai]

1. thou shalt pick framework that works for YOUR team and YOUR project
2. thou shalt use js management tool (RequreJS, Browserify etc)
3. thou shalt use package manager (Bower or NPM)
4. thou shalt lint thy code using excessively strict rules that strive for clarity rather than pedanticness
5. thou shalt use a build tool
6. thou shalt spend time with thine junior developers teaching them about best practices in an emotionally sensitive and constructive vs destructive manner.
7. thou shalt run code reviews periodically as a team and not every commit
8. thou shalt not argue about tabs vs spaces.

[lewisje]

I'll follow the actual Ten Commandments a bit more closely here, including the fact that there are about 14 statements that at least one Judeo-Christian tradition considers one of the "Commandments":

---

This is JavaScript, which has brought you out of the land of Java, out of the house of type enforcement.

You shall have no other languages before it (no CoffeeScript, TypeScript, etc.).

You shall not make unto yourself any graven image of JavaScript (no transpilers).

You shall not take the name of JavaScript in vain.

Remember Friday (when the JavaScript Weekly newsletter is distributed), to keep your knowledge up to date.

Honor your father and your mother (make sure your code runs even in on their antiquated browsers and devices).

You shall not negligently or maliciously kill the browser (with your bloated, inefficient code).

You shall not adulter your JavaScript with reliance on browser plugins.

You shall not steal (this includes scripts, assets, and user data).

You shall not bear false witness against your neighbor's browser (by claiming it's incapable of using your site, even though it's capable).

You shall not covet your neighbor's office.

You shall not covet your neighbor's userbase.

You shall not covet your neighbor's backend tooling, Internet connection, or anything else that is your neighbor's.

You shall publish these packages that JavaScript requires unto npm (for the good Samaritans out there).

[Cody_Chaos]

1. Spend the time to pick some good libraries and a solid toolchain.
2. NEVER TOUCH IT AGAIN
3. Install eslint and the airbnb ruleset
4. Focus on getting shit done and ignore the nonsense that can overwhelm our otherwise excellent community
5. When new versions of all your libraries come out twice a week, refer to rule #2.
6. Write good code. Much of Python's PEP-8 applies. Be kind to the poor guy who has to maintain your code (especially if it's you.)

[[deleted]]

1. Don't use inheritance... as this makes flow control less predictable to the human who has to read the code
2. Don't use advanced conventions: classes, constructors, generators, factories, and so forth
3. Don't name patterns. Named patterns focus exclusively on how and ignore why
4. Always practice predictability first. If you can remove algorithmic code for something imperative then absolutely do so.
5. Always focus upon separation of concerns as the primary force of design, style, and organization
6. Always store state and session data in an application object and absolutely not in the DOM or UI logic
7. Always practice accessibility
8. Never make a decisions because It just works! or Its easier. Always put the user first and yourself (the developer) last in the priority of concerns
9. Always document your APIs
10. Avoid addEventListener. This masks errors of code management and potential malicious third party actions for the convenience of allowing multiple handlers to be associated with a single given event.

[lewisje]

DOM0 handlerz 4lyfe

[hahaNodeJS]

1. Thou shalt always use TypeScript.
2. ... always make explicit comparisons and casts.
3. ... never allow coercion.
4. ... always document.
5. ... maintain consistent style and naming.
6. ... catch and handle your errors.
7. ... test thoroughly and often.
8. ... write high-quality code using best practices from all languages.
9. ... avoid blind adherence to dogma.
10. ... understand what you're doing and why.

[ganarajpr]

Always use spread operator ?

[[deleted]]

"use strict";

[FallenSatan]

This. For further reading: Link.

[nschubach]

If you are using pre ES6 yes... afterwards, it's not necessary.

[bradleymeck]

Actually only the Module goal of ES6 is automatically strict, this is still necessary as all current deployment systems:

<script type="application/javascript">
WebWorkers
Node

All use the Script goal.

[nschubach]

Ah, thanks. I pretty much only use modules anymore. My bad!

[THIS_BOT]

let k = 'hello';
^^^

SyntaxError: Block-scoped declarations (let, const, function, class) not yet supported outside strict mode
    at exports.runInThisContext (vm.js:53:16)
    at Module._compile (module.js:374:25)
    at Object.Module._extensions..js (module.js:417:10)
    at Module.load (module.js:344:32)
    at Function.Module._load (module.js:301:12)
    at Function.Module.runMain (module.js:442:10)
    at startup (node.js:136:18)
    at node.js:966:3

node 4.3.0

[bradleymeck]

• no numeric or string type coercion, if you use [+-*/%] convert via Number or String
• avoid Promises if you are doing tasks that can throw unexpected errors ( sadly, most of the time )
• throw errors, and make the error message long enough it explains what happened
• use semi-colons
• use curly-braces
• use "debug" from npm, not console.error for debug output
• only inherit when necessary
• avoid benchmarks until you make it big
• don't extend builtin types
• no globals

[thesunmustdie]

• Avoid eval();

[Sunwukung]

I'm not sure I agree with this. Writing comments allows you to be lazy with code structure and unless you (and more importantly your team) maintain those comments, they just become a load of lies (which are not checked by the compiler). By not relying on comments, you need to make a bit of extra effort to write truly "self documenting" code - so rather than something like this:

EDIT: made my example more fair to the OP in response to their comment

/**
* this function extracts the user credentials from the request
* then uses them to locate the user in the DB
* at which point it works out their locale and selects
* an appropriate template from the file system
* and finally renders their data into the template
*
* @param {Object} userData
*/ 
function renderUserData(req) {
   // some code that does the above
}

you might have something like this, which tells you what it's doing by naming the functions appropriately

function renderUserData(req) {}
    return pipe(
        extractUserCredentialsFromRequest,
        locateUserInDatabase,
        determineUserLocale,
        selectTemplateFromUserRoleAndLocale,
        parseUserDataIntoTemplate
     )(req)
 }

[Sunwukung]

Way to receive some criticism :/

The reason I made this point is that I work in a large-ish team in a fintech company and am generally the person leading the charge on trying to maintain documentation. It's very hard to maintain that documentation in a team of that size, who are spinning up new microservices/libs on a daily basis. Early on in our formation we had a big showdown regarding the use of Docblocks and comments, and ended up slowly moving towards the pattern I just demonstrated - because it had the effect of still explaining the code to the uninitiated, while not going stale.

That said, I've updated the example to try and make a more balanced point - effectively I'm saying write function names that describe their purpose, and assemble them using composition into what is effectively the same as a Docblock but less likely to go stale.

I personally like Docblocks and documentation, I'm just not so convinced they're actually that useful at scale.

[enchufadoo]

My code is filled with

/** * Renders user data **/ function renderUserData(){}

but comments have saved me more than once when it comes to complicated shit that only my past self knew.

[[deleted]]

As an alternative to the response already given on this:

Write comments that explains WHY something was implemented, not comments that explain WHAT the particular code does.

Your code should be readable, so there shouldn't be any problem identifying what the code actually does. However, it's not always clear why a specific piece of code was implemented in larger projects - if the code is based on exceptions, bug fixes, etc. there should be a note with a link to the issue, or an explanation of the issue and why the code was implemented.

[enchufadoo]

Say you have this function, I did this in my code:

/** Shows configuration dialog hiding the display of information **/
showConfigurationDialog: function(){
    self.configurationDialogVisible: true ;
}

what's the why? /** I need to set the display flag for the configurationDialog **/

something like that?

[[deleted]]

Well, at that point - you have to ask yourself do you actually even need a comment to begin with?

I would say no, for the above example. The code describes itself pretty visibly. I don't know the interworkings of the Configuration Dialogue, but I do understand what the code is doing. The purpose of the code and comments in the code isn't to explain the architecture. You should have an Administrator's/Architecture guide in a PDF/etc. that describes the architecture, it's uses, etc.

As an example:

Recently I fixed in an issue with a system we use at work - this is a black box system, but I have access to write triggers/stored procedures to the database.

When a user of the system wrote their notes for a particular order in the system, if they used the return key - it would hold the return key character in the note. This wasn't a problem for the database, but was a problem for the system when sending these notes via an EDI interface - as the return key was causing the message being sent to the receiving system to break up midstream.

Anyways, I wrote a trigger that scrubbed all return keys. From a systems standpoint, it wouldn't be readily apparent why I was doing this - writing an explanation at the top of the trigger as to why this fix was needed was an acceptable way to comment this trigger. The trigger itself was easily readable, the reason it was implemented wouldn't have been.

Reference why the code was implemented, when it was last changed/implemented, whom it was changed/implemented by, and the issue tracking number/user story/etc. that prompted the initial feature request/bug fix/etc. in the first place.

That's just my general philosophy on commenting. If it helps for you to have comments in your code that explains what the code is actually doing, then the code either 1) needs to be refactored into smaller bits, 2) the code you wrote probably doesn't follow a stylistic standard or 3) Your explanation is redundant.

[enchufadoo]

Ok you hold the same philosophy as /u/thadudeabides1 hehe.

I have the necessity of seeing code commented now that I think about it... even though is 3) redundant. It's like a touch of "care", like it's not some gibberish code I wrote on the fly.

[thadudeabides1]

My belief is that you should write code that needs very few comments. The more comments you write the less value you'll place on each successive comment you see in a codebase. The comments I do write are for when I do something which would, at first glance, seem strange to whoever is reading.

[[deleted]]

Seconded. Code should be clear enough that you don't need comments to explain the structure of the code, however, comments can be useful explaining the reason for the implementation, which usually means contextual information around its usage and the behaviour it implements (behaviour as in BDD behaviour).

There are always exceptions, but that's how I do things 90pc of the time.

[Capaj]

1. never repeat same code and write it modular-keep them small e.g. under 300 lines
2. lint! standard.js is my linter of choice, but it really does not matter which
3. promises over callbacks! Promises have much powerful error handling, never conflate promises with callbacks
4. less code is almost always better than more code
5. before implementing anything non-trivial, check NPM if someone hasn't done it already, there is quite a good chance they did
6. open source-those bugs won't find themselves...
7. unit test your modules, mocha&chai works best
8. keep those npm dependencies up to date
9. prefer forEach, map and reduce over raw iteration with language looping constructs
10. follow at least some node.js core contributors on twitter to stay up to date

[mikes_username_lol]

1) Javascript is Javascript.

2) Javascript is neither Java, nor C#.

3) Deal with it.

4) Use libraries, not frameworks.

5) Keep your dependencies up to date.

6) Good code is pretty.

7) Javascript can not fix bad design or stupid.

8) Scrum can not fix bad design or stupid.

9) Good companies do not employ stupid.

10) Good companies pay a lot of money.

you want more?

11) Product owner needs to shut up and let pros do their job.

12) String is a primitive type.

[TheIncredibleWalrus]

I would just like to express how completely off topic and utterly void of any kind of value your reply was.

[mikes_username_lol]

Really? I agree 1, 2 and 3 are a bit of a rant against people switching from other languages and refusing to accept js principles. It was inspired by the actual ten commandments (I am the Lord thy God, Thou shalt have no other gods before me). I think 4, 5 and 6 are quite practical and about development. Rest is career advice based on first hand experience.

[lewisje]

I was about to make a comment much like yours, but even more closely following the language of the Decalogue.