Clean code tip: Use pronounceable and searchable names

Ok, you write code. Maybe alone. But what happens when you have to talk about the code with someone else? To help clear communication, you should always use easily pronounceable name.

Choosing names with this characteristic is underrated, but often a game-changer.

Have a look at this class definition:

class DPContent
{
    public int VID { get; set; }
    public long VidDurMs { get; set; }
    public bool Awbtu { get; set; }
}

Would you say aloud

Hey, Tom, have a look at the VidDurMs field! ?

No, I don't think so. That's unnatural. Even worse for the other field, Awbtu. Aw-b-too or a-w-b-t-u? Neither of them makes sense when speaking aloud. That's because this is a meaningless abbreviation.

Blah blah blah

Avoid using uncommon acronyms or unreadable abbreviations: this helps readers understand better the meaning of your code, helps you communicate by voice with your colleagues or searching for a specific field using your IDE

Code is meant to be read by humans, computers do not care about the length of a field name. Don't be afraid of using long names to help clarity.

Use full names, like in this example:

class DisneyPlusContent
{
    int VideoID { get; set; } 
    long VideoDurationInMs { get; set; }
    bool AlreadyWatchedByThisUser { get; set; }
}

Yes, ID and Ms are still abbreviations for Identifier and Milliseconds. But they are obvious, so you don't have to use complete words.

Of course, all those considerations are valid not only for pronouncing names but also for searching (and remembering) them. Would you rather search VideoID or Vid in your text editor?

What do you prefer? Short or long names?

👉 Let's discuss it on Twitter or on the comment section below!

🐧

code4it

Ciao! I'm Davide Bellone, a .NET software developer! Let's keep in touch on Twitter!