What are your favorite strategies for writing code that's easy to understand, maintain, and extend? Share your top tips and tricks for keeping your codebase sparkling clean and developer-friendly.
Follow the DEVteam for more discussions and online camaraderie!
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (37)
Seperation of concerns: making sure one function does only one particular thing and is reusable if needed.
Clear and concise comments
Self descriptive variable and function names
On a lighter note, the above bullet points are not indented correctly π
BTW, great share π
Lol, in the markdown they were properly indented, but for some reason when I post the comment, it just did that. Tried editing it twice, eventually just left it like thatπ
Self descriptive variable and function names >> I use this, thus reducing the need for additional comments.
My personal experience with the recommendation of low coupling is that it's helpful to write out a "plain English" version of requirements. For example, creating a report from data based on a 3rd party API may look something this:
After writing these out, it helps me think about how the code could be organized. For example, each of these steps should at the very least be in their own function and there's probably separate modules/classes that can be derived as well.
But I think the biggest advantage to operating this way is seeing when code may be mixing concerns. If I look at my code and it deviates from this list - eg the code for implementing the email logic is in the same function as the code that implements the API request logic - I've likely grouped things together that should be split out.
I use the same process. The act of jotting down that bulleted list might show that I'm missing a step or that some assumption won't work, which is best to catch before any code hits the screen.
Think about the big picture. It's rarely about the code you're staring at, but how it fits into the system.
This is my mantra. Knowing the big picture helps us to know when to stop making a piece of code cleaner and cleaner...
This might be a strange strategy to some, but I try to avoid abstractions as much as possible. IMO, it's much easier to go back and abstract something for re-usability when you need to, instead of constantly trying to throw everything into a function or class.
Actually, itβs well known software design principle known as YAGNI , which stands for βYou Arenβt Gonna Need It.β
I use SOLID principles as the base of clean code strategy. Trying to make your code reusable is a great column too. And the last one I use the most is TDD, to clarify in every moment what I want and how to do it the best I can.
I agree, in general I try to keep my code as decoupled as possible. For instance, if you have a class in charge of sending emails, do not give that class the responsability of configuring the mailer. Instead, create another class to do that so you can decoupling sending from configuring.
descriptive names for variables and functions.
using functions to avoid writing same code again and again
importing functionalities from other files to separate like and unlike things
writing comments where ever required
keeping in mind, which is deprecated and using what's new and versatile
I think there is a great reason WHY several people have already said well named functions and variable names is a common clean code practice. I can't stress the importance of that concept enough. The problem with most code is INTENT. If you are clear with the INTENT of your code then you will have created clean and easily maintainable code. Usually that means just break out some code into a WELL named function. If you start to write comments around functionality then that's usually a good indicator (code smell) that intent isn't clear and it needs to be separated out.
Other things of note:
I agree. A lot of comments are usually a sign of code smell. Especially after the code has been modified several times, but the comments are never updated when someone is enhancing it or making a bug fix.
I have seen this way too many times in production. The CODE is ALWAYS the source of TRUTH, not the comments.
Function and variable names should be clear, succinct and avoid acronyms (that can lead to misinterpretation).
Also if you think there are not enough characters to give your function a meaningful name, your function is probably doing more than one thing, a sign that its time to refactor.
One last thing I would add is to also not waste time trying to optimise code before you are finished AND there is an actual need to make the program or process run faster. Otherwise you might waste a tonne of time on something that gets refactored anyway or thrown out all together in the end.
Thanks.
I starter writing something in a comment, and I talked about so many things that I ended up considering writing an article.
How to be a better developer for you and the others
Christophe Colombier γ» Apr 7
I hope you will find it interesting
When working on the front end, avoid using two full-fledged libraries simultaneously, such as Bootstrap and Ant Design (antd).
Ensure that the same library is not included multiple times with different versions
If parts of the code have been replaced with a new version, ensure that the old version is not left commented out, as this can be avoided.
Cool.
I think the main ones I'm thinking about while writing code would be:
map()instead).I'm writing a book on clean code, where I talk about each (and many more) in great detail with lots of examples, most chapters are available online.