Introduction   Writing clean code is a fundamental skill for every software developer. Clean... Tagged with webdev, javascript, programming, productivity.

Dev.to is a community platform for developers, offering resources, discussions, and networking opportunities to empower individuals in their coding journey. Developers can learn new programming languages, frameworks, and tools, engage in discussions on best practices, and share their experiences with fellow developers to enhance their skills and grow their professional network.

Clean code is code that is easy to read, easy to understand, and easy to modify. Clean code follows a set of conventions and best practices that make it more consistent, making it easier for multiple developers to work on the same project seamlessly. Code that is difficult to understand is more prone to errors during modifications or enhancements.

Writing Clean Code: Best Practices and Principles

Best Practices and Principles for Writing Clean Code

Eventually, clean code becomes second nature, like coding itself or riding a bike. It will happen naturally as you start to integrate the concepts into your daily engineering.

Core Tenants of Clean Code:
<ol>
<li>Meaningful Variable and Function Names</li>
<li>Keep Functions and Methods Short</li>
<li>Comments and Documentation</li>
<li>Consistent Formatting and Indentation</li>
<li>DRY (Don’t Repeat Yourself) Principle</li>
<li>Use Meaningful Whitespace</li>
<li>Error Handling</li>
<li>Testing</li>
<li>Refactoring</li>
<li>Version Control</li>
</ol>
Why?
<ol>
<li>Readability</li>
<li>Maintainability</li>
<li>Collaboration</li>
<li>Bug Reduction</li>
<li>Efficiency</li>
</ol>

The author could probably elaborate on commenting good/bad as it remains a point of debate. I am very much in favour of python style ‘docstrings’ on all public methods… for two reasons, it can become your application’s documentation later and most importantly - it helps to focus your development - what is this portion of code intended to do? If you can’t state it in one short docstring comment maybe you’re violating single responsibility…
Multiple inline comments that restate what the code is already doing is not good practice.

I also think that one of writing clean code’s practices that could be shelved below “Readability” is “Writing clear code not clever code”.

I thought this would be more impactful but each of these points come with experience.
The next level is when you start recognizing structural and behavioral patterns