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...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
A fundamental of this is whether the code is going to be under continual frequent redevelopment, if it is then my advice is where you may be looking at adding greater functionality over time e.g. file output format for example ensure you use dependency inversion and get your interface for the abstraction right prior to developing your different output classes and seriously think about your output formatting classes and their single responsibility. People that are talking about comments, probably need to review their code not their comments as it probably needs refactoring and proper variable/function names. For comments relating to writing down steps in plain English, look at UML there are techniques within it to do this.
Keep clean design, code we clean-up later
One thing I think can help beginners is to feed the code to LLM to refactor after it's written.
They are not always correct but it's not that LLM never suggests a good idea. And models are becoming smarter as time goes by.
So a balanced approach could be to get the suggestions from LLM, learn more about it if needed, evaluate it, implement or ignore. LLM is like static analysers but for larger refactoring.
Surprised I didnt see anyone mention mutability and side-effects. I usually think it is a code smell if mutability and side-effects are spread across a system. These should be generally as centralized as possible so that you can easily trace how your system interacts with the outside world.
Here is my quick tip, order alphabetically everything: params, methods, etc. The next person that comes to the code will have a quick way to find anything.
A lot of linters will not work with this.
Documenting your code like Java did. Even if we already followed any clean code rules, our code still difficult to read because someone else need to understand it line by line.
I mainly focus on variable and functions name and sometime i use comments to specify what that function does
i have always follow to create reusable clean code
Ask chatGPT to write comments for my code
Following SOLID principles, we'll be publishing an article on that with examples in Go soon here - packagemain.tech
Using Spark instead ov writing the boilerplate CSS yourself.
make it easy to understand
Prevent file size bloat. Pull out functions/classes/hooks to their own appropriately named files (NOT utils!) to keep the file focused on one goal.
clean and consistent naming convention