# Zig Code Smells

**URL:** <https://ziggit.dev/t/zig-code-smells/2928>\
**Category:** Explain\
**Created:** [January 19, 2024, 5:37pm UTC](https://ziggit.dev/t/zig-code-smells/2928 "2024-01-19T17:37:14Z")\
**Posts on this page:** 1\
**Showing post:** 1

<div class="post-metadata">

**Author:** ![AndrewCodeDev](https://ziggit.dev/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@AndrewCodeDev](https://ziggit.dev/u/AndrewCodeDev)\
**Post date:** [January 19, 2024, 5:37pm UTC](https://ziggit.dev/t/zig-code-smells/2928/1 "2024-01-19T17:37:14Z")

</div>

Code smells - every language has them and some times they’re unavoidable.

Sometimes, a code smell can indicate a choice that causes something to be more awkward than it needs to be. However, much like the stench of mold, a code smell can be an indicator that something is rotten in the foundation of a design.

What do you think is a Zig code smell?

What do you think the code smell indicates and do you have any suggestions?

* * *

I’ll kick it off with error handling:

- Using `try` statements but never actually handling errors.

This code smell applies to applications more so than library code. Users of said library may want to handle those errors themselves, but there are legitimate times where a library can run afoul of this.

Zig provides errors as values, but if you never do anything with those values and just let them bleed through main, you might as well have used a `@panic`.

Using errors to signal deallocations, form error messages, close resources, and attempt recoveries are good uses of errors. This is a code smell because there are valid cases for using `try` and letting things percolate through main (such as hello\_world.zig), but in larger applications it can give the false pretense that errors are being handled.

Try to think about whether something is actually recoverable or not - it can greatly simplify your code.

---

_[View the full topic](https://ziggit.dev/t/zig-code-smells/2928)._