-
Use lint and some kind of style checker.
-
Never arbitrarily disable a lint rule. If there is any inconsistency between the rule and the design style, the rule should be revised.
-
Use descriptive names, even if they are long.
Avoid abbreviations, especially if the variable is used in a broad context. In short contexts it may be acceptable (eg a lambda function).
Avoid ambiguities.
Think carefully before assigning a name.
const c = 0; // ๐ const userActivityCounter = 0; // ๐
const admins = usersList.filter(u => u.isAdmin()); // ๐ but let's avoid it
const projectData = {}; const dataProject = {}; // ๐ if they are in the same context
-
Variable names must be nouns, as they represent things.
const user = {}; const counter = 0; const houses = [];
-
Function names must contain verbs as they represent actions.
function saveFormChanges() {} function handleKeyboardEvent() {} function createNewTemplate() {}
-
Functions that return logical values in general can use
is
andhas
.function isActive() {} function hasRole(role) {}
-
Comments are rarely needed. The code must be clear and expressive enough to be understood.
-
Never submit "magic numbers" to the repository.
Refactoring.com > Replace Magic Literal. -
Never commit commented code to the repository. Use branches.
-
Remove any commented code you find if you make sure that is wasn't commited by accident.
-
In the absence of a Feature Flags system, never push unused code to the repository as it can confuse your team.
-
In the absence of a Feature Flags system, remove any code that you ensure is unused.
-
Code lines should not exceed 100 characters (It's hard to find a criterion to define the exact number. It can be 72, 80, 120...).
-
Respect code indentation.
Summary of 'Clean code' by Robert C. Martin @github.com/wojteklu
Clean Code concepts adapted for JavaScript @github.com/ryanmcdermott
- Avoid repetitions but be careful with coupling.
DRY is about Knowledge @verraes.net - Split the code into short functions, always focused on a single action, even if these functions are only used in one place. Too many loops and conditions in a function is a symptom that it needs to be split.
Cyclomatic complexity @wikipedia.org - Whenever possible, implement pure functions without side effects. Side effects make code extremely difficult to understand, test, and debug.
Pure vs Impure Functions @dev.to/sanspanic - Too many parameters in a function (or props in a component) is a signal that the function is poorly designed and needs refactoring.
โถ๏ธ Clean Code III: Functions - Robert C. Martin - Avoid abstract classes. Favor composition over inheritance.
Composition vs. Inheritance: How to Choose? @thoughtworks.com - Refactor your new code before pushing it to the repository.
refactoring.com/catalog/
refactoring.guru/refactoring
sourcemaking.com/refactoring - Always try to leave the code better than you found it.
- Think hard about the task to be performed, the problem to be solved.
โถ๏ธ Hammock Driven Development - Rich Hickey - Count on change and always think about the future.
If someone else needs to maintain this code six months from now, will they be able to understand what they did and change the code easily?
- What makes software easy to change is its structure. Structure is more important than behavior.
Software must be soft.
What is the value of software development? @medium.com/@mvidaurre
Clean Architecture โ Two values @medium.com/@stoltmanjanWorking software that cannot be modified tends to become obsolete and disappear. Software open to change, even if defective, can work again.
SRP: The Single Responsibility Principle.
OCP: The Open Closed Principle.
LSP: The Liskov Substitution Principle.
ISP: The Interface Segregation Principle.
DIP: The Dependency Inversion Principle.
REP: The Release-Reuse Equivalence Principle
CCP :The Common Closure Principle
CRP: The Common Reuse Principle
ADP: The Acyclic Dependencies Principle
SDP: The Stable Dependencies Principle
SAP: The Stable Abstractions Principle
DDD, Hexagonal, Onion, Clean, CQRS, โฆ How I put it all together @herbertograca.com
Ready for changes with Hexagonal Architecture @ netflixtechblog.com
Introducing Domain-Oriented Microservice Architecture @eng.uber.com