My Other lists
- Software Development General Best Practices
- PR Code Review Practices
- Defensive Programming / Application Security Best Practices
I usually follow Airbnb's JavaScript Style Guide, still, I intend to keep this list as reference. Most of these rules will be enforced automatically if you integrate ESLint in your project.
- Always use 'use strict' if you are still using es5
- Don't use global variables
- Always Prefer const over let. Ditch the var
- Prefer writing pure functions over stateful functions which mutate data or produce side effects
- Learn and use functional composition
- Favor functional programming over imperative programming
- Use method chaining
- Prefer composition over inheritance
- Use linters to ensure your code is consistent.
- Use Airbnb JavaScript Style Guide for JavaScript (https://github.com/airbnb/javascript)
- Avoid client-side console logs in production
- Prefer '===' over '=='
- Use default arguments instead of short-circuiting or conditionals
- Function arguments (2 or fewer ideally)
- Encapsulate conditionals in a separate function if possible
- Avoid negative conditionals
- Learn and practice implementation of SOLID Patterns
- Use Promises, not callbacks
- Async/Await is even cleaner than Promises, use it more
- Use try/catch with async/await
- Use Async-Await or promises for async error handling
- Don't ignore rejected promises, log it to external logging service
- Never use eval
- Structure your solution by components
- Wrap common utilities as npm packages
- Separate Express 'app' and 'server'
- Use environment aware, secure and hierarchical config
- Distinguish operational vs programmer errors
- Use only the built-in Error object
- Handle errors centrally, not within a middleware
- Exit the process gracefully when an unknown fatal error occurs
- Use a mature logger to increase error visibility
- Discover errors and downtime using APM products (sentry.io)
- Catch unhandled promise rejections
- Fail fast, validate arguments using a dedicated library
- Use ESLint
- Separate your statements properly
- Prefer named function over anonymous. Name all functions, including closures and callbacks. Avoid anonymous functions, as it helps in profiling
- Require modules by folders, opposed to the files directly
- Require modules at the beginning of each file, before and outside of any functions
- Detect code issues with a linter
- Refactor regularly using static analysis tools
- Avoid using the Node.js crypto library for handling passwords, use Bcrypt
- Prevent evil RegEx from overloading your single thread execution
- Don't block the event loop
- Bootstrap using 'node' command, avoid npm start (In container environment)
NOTE: If you want to update this list, please comment, I'll incorporate your changes.
Ref.
https://github.com/goldbergyoni/javascript-testing-best-practices
https://github.com/ryanmcdermott/clean-code-javascript
https://github.com/goldbergyoni/nodebestpractices
https://github.com/RisingStack/node-style-guide
https://github.com/DrkSephy/es6-cheatsheet
Top comments (8)
Prevent evil RegEx from overloading your single thread execution
Can someone give me more information about that? What does that mean exactly?
Here is an explanation:
Here is another:
Thank you.
You're welcome :-)
Really like your list! However I have to ask your reasoning behind item no 30.
I have used middlewares designed only for errors in express and serverless node applications and it had a really positive experience. This approach works quite well as it allows your can check if the error is a custom one and then pass the extra params that will help you debug the app. Otherwise it will be a standard error and won’t change your apps behaviour. Thoughts?
Thanks Harris! I believe - the following article sums it well:
medium.com/devcbeirut/error-handli...
Hey great list! Got a concern for item no 39. In past I’d say ofc do it that way it’s more elegant but when deno came out, it felt better and increased the readability of the code for me. Thanks!
Thanks. Can you please elaborate more with an example?