# Code Smell 65 - Variables Named After Types

> TL;DR: Don't name your variables with the accidental type

# Problems

* Declarative
    
* Design for Change
    
* Coupling to accidental implementation
    

# Solutions

1. Rename your variable according to the role.
    

# Sample Code

## Wrong

%[https://gist.github.com/mcsee/00c30c369fe7339e28d50f858392cf4c] 

## Right

%[https://gist.github.com/mcsee/91e3a3f2b1351fa0e09fb8c56a5c2779] 

# Detection

This is a semantic rule. We can instruct our linters to warn us from using names related to existing classes, types o reserved words since they are too implementative.

# Tags

* Declarative
    

# Conclusion

The first name we can across is related to an accidental point of view. It takes time to build a theory on the models we are building using our [MAPPERS](https://maximilianocontieri.com/the-one-and-only-software-design-principle). Once we get there, we must rename our variables-

# Relations

%[https://maximilianocontieri.com/code-smell-38-abstract-names] 

# More info

%[https://maximilianocontieri.com/what-exactly-is-a-name-part-ii-rehab] 

%[http://xunitpatterns.com/Intent%20Revealing%20Name.html] 

# Credits

Photo by [Sangga Rima Roman Selia](https://unsplash.com/@sxy_selia) on [Unsplash](https://unsplash.com/s/photos/name)

This idea came from this tweet

%[https://twitter.com/BelloneDavide/status/1377522389312008193] 

---

> Types are essentially assertions about a program. And I think it’s valuable to have things be as absolutely simple as possible, including not even saying what the types are.

*Dan Ingalls*

---

%[https://mcsee.hashnode.dev/software-engineering-great-quotes] 

---

This article is part of the CodeSmell Series.

%[https://mcsee.hashnode.dev/how-to-find-the-stinky-parts-of-your-code]