Hi everyone, Gophers You have to write code that can be maintained when dealing with golang. Simplicity, readability, and clarity are the fundamental components of maintainable code; these qualities h...

Materialize

Bobby Iliev

DevOps

Community Picks is a section on daily.dev where our community members share the most interesting and valuable content they've discovered online. From insightful articles to handy tools, every post is a gem curated by our dedicated coomunity. To contribute to Community Picks, you need to have at least 250 reputation points, ensuring that only active and trusted members can share their finds.

Community Picks

Maintainable Go code emphasizes simplicity, readability, and clarity to help new team members easily understand and continue the work. Key strategies include keeping the `main` function minimal, using meaningful names, writing clear comments, avoiding repetitive code, minimizing deep nesting, using early returns to reduce code complexity, and preferring switch cases over if-else statements. Continuous refactoring is crucial to keep the codebase modern and secure.

How To Write Maintainable Go Code?

Try to write meaningful comments wherever possible

Return early and use conditions very wisely

Use switch case more often instead of if/else

I can’t entirely agree with the comments and dry sections.
Here are my two cents.
The author uses excessive comments; you don’t need to comment on each line you wrote. Please don’t comment on implementation, only the behavior; implementation description is only necessary if it’s a very complex logic.
DRY is a trick; use it sparingly, or you will fall into the Wrong Abstraction Problem. Initially, avoid duplicate domain/business logic and prefer small duplications on auxiliary methods over flawed/premature abstractions.

early return may be a good idea for short functions, but for slightly more complex code I think it is better to use single return point.

I might not be 100% aligned with the concepts here, but they are ovrall reasonable good rule of thumbs!
I’ll print it in a qr for each student that will come in 😄

It’s a good general rule of thumb, thank you for sharing. I would like to add that comments like:
<ul>
<li><code>// describeEvenNumber handles even numbers</code></li>
<li><code>// describeOddNumber handles odd numbers</code></li>
</ul>
aren’t helpful and should be avoided in my opinion. Also for example this method:
<code>func describeEvenNumber(number int) { if number &gt; 10 { fmt.Println(&quot;The number is positive, even, and greater than 10.&quot;) } else { fmt.Println(&quot;The number is positive, even, and 10 or less.&quot;) } } </code>
I would try to avoid <code>else</code> cases if you can and keep the happy path to the left. A good article about this can be read here: <a href="https://medium.com/@matryer/line-of-sight-in-code-186dd7cdea88" target="_blank" rel="noopener nofollow">https://medium.com/@matryer/line-of-sight-in-code-186dd7cdea88</a>