Subscribe to my email list now at http://jauyeung.net/subscribe/
Follow me on Twitter at https://twitter.com/AuMayeung
Many more articles at https://medium.com/@hohanga
Even more articles at http://thewebdev.info/
More often than not, we’ve to work as a team to build our software.
In this article, we’ll look at how the coding practices that’ll make all our teammates happy.
Standardize Code Formatting
If we all standardize our code formatting, then we won’t see a lot of spacing changes during code review.
Then our teammates can focus on reviewing real code changes rather than looking at spacing and formatting changes.
We can use a linter or a program like Prettier to standardize formatting with our own configuration.
Make Abstractions If We Have to Write the Same Code 3 or More Times
We only need to follow the do not repeat yourself principle if we have to write the same thing 3 or more times.
If we don’t, then we don’t need to abstract the repeated code. This ensures that we aren’t doing extra work to extract out the repeated code unnecessarily.
We can move it out when we have to add the same thing a 3rd time.
Add Logs to Debug
Logging is a great way to look at the values of whatever we want to look at for debugging purposes.
However, we shouldn’t put those everywhere and we should make sure that we remove the debug logs before we check in our code.
No Premature Optimizations
We only need to optimize our code when it’s too slow for our purposes. Otherwise, it’s work that we don’t need to do when it’s a waste of time.
We should benchmark our code so that we know it’s fast enough. This way, we have confidence that it can be put on production and still be usable.
No Useless Features
The less code we write, the better. So code for useless features is useless and it’s more stuff that our teammates have to read and to know that it’s useless.
Therefore, we should take them out so that everyone will be happier not to have to read that code and save everyone time.
Continuous Integration and Deployment
Continuous integration and deployment pipelines save us from having to run builds and tests manually.
Doing everything manually just isn’t ideal by any stretch of the imagination. It’s error-prone, slow, and repetitive.
So we should just get our computers to do that stuff automatically with a continuous integration and deployment pipeline so we don’t have to do it manually.
We just build and deploy on every check-in and then we won’t have to worry about things getting out of date on our servers.
No Useless Comments
Useless comments don’t do us any good and they take up space, so we shouldn’t have them.
Instead, our code should be mostly self-documenting with a few comments here and there if we have something that’s not obvious from the code that we want to explain.
Consistent Indentation
Inconsistent indentation is bad for readability. Therefore, we should make sure that we should keep indentation consistent.
We can indent code automatically with a code formatted or linter then we won’t have to worry about that again.
Code Grouping
Grouping related code together is a good idea. We separate groups by a blank line.
We can have a loop as its own group and file operations code in their own group for example.
Consistent Naming Scheme
We should just stick with the naming conventions for a given programming language.
Most languages have their own convention. For example, JavaScript specifies that variable and function names are camelCase and constructors and classes are PascalCase.
This way, everyone will know what something is from their case.
No Deep Nesting
Deep nesting is the worst for readability. Nobody can understand what deeply nested code like the following is doing:
const foo = () => {
if (a) {
if (bar) {
if (baz) {
if (qux) {
// ...
} else {
return false;
}
} else {
return false;
}
} else {
return false;
}
} else {
return false;
}
}
No one can understand what the function is doing with all that nesting.
We can eliminate nesting by using guard clauses and other things to eliminate nesting.
Conclusion
Useless code should be removed from our codebase. This includes useless comments, useless features, and optimizations we don’t need.
Also, deep nesting is bad.
Standardizing code formatting is also good so that people won’t have to look at spacing changes during code review.
Top comments (1)
Thanks. I corrected it.