CHAPTER 03
Intermediate
Naming Conventions and Best Practices
Updated: May 16, 2026
20 min read
# CHAPTER 3
Naming Conventions and Best Practices
1. Introduction
"There are only two hard things in Computer Science: cache invalidation and naming things." This famous quote by Phil Karlton rings incredibly true. A variable name is the foundational building block of self-documenting code. Every time you name a variable, a function, or a class, you are leaving a message for the next developer. If that message is$data, you have failed. If that message is $activeUserAccounts, you have succeeded. In this chapter, we will master the agonizing, critical art of naming things. We will explore the rules for variables, the action-oriented nature of functions, and the absolute necessity of avoiding ambiguity.
2. Learning Objectives
By the end of this chapter, you will be able to:- Understand the critical importance of intention-revealing names.
- Apply distinct grammatical rules when naming Variables, Functions, and Classes.
-
Identify and eliminate ambiguous or generic names (e.g.,
$data,$info,Manager).
- Utilize searchable names to improve navigation in large codebases.
- Standardize terminology across a team.
3. Intention-Revealing Names
The name of a variable, function, or class must answer all the big questions: *Why does it exist? What does it do? How is it used?* If a name requires a comment, the name does not reveal its intent.-
Bad:
int d; // elapsed time in days
-
Clean:
int elapsedTimeInDays;
4. Naming Rules by Type
Different types of programming constructs should use different parts of speech.- Variables (Nouns): Variables hold data. They should be Nouns or Noun Phrases.
-
*Bad:*
$calculate,$is
-
*Clean:*
$customerRecord,$totalPrice
- Booleans (Questions): Booleans are true/false. They should read like yes/no questions.
-
*Bad:*
$status,$read
-
*Clean:*
$isActive,$hasReadPermission
- Functions/Methods (Verbs): Functions *do* things. They must be Verbs or Verb Phrases.
-
*Bad:*
function payment(),function data()
-
*Clean:*
function processPayment(),function fetchUserData()
- Classes (Nouns): Classes represent objects or concepts.
-
*Bad:*
class SendEmail,class ParseData(These are actions, not objects).
-
*Clean:*
class EmailSender,class DataParser
5. Avoiding Disinformation and Ambiguity
Do not leave false clues.-
Generic Words: Words like
Data,Info,Processor, orManagerare lazy. What is aDataManager? It tells the reader absolutely nothing. Be specific. Instead ofDataManager, useUserAuthenticationService.
-
Wrong Types: Do not name a variable
$accountListif it is not actually a List (array). If it's just a single string, the word "List" is disinformation. Call it$accountGroupingsor$accounts.
6. Searchable Names
In a codebase with 10,000 files, you must be able to hitCtrl+F and find what you need.
-
Single-Letter Variables: Avoid them completely (except for standard loop counters like
$i). If you name a variable$e, and try to search for it, you will get 50,000 results. If you name it$exceptionError, you will find it instantly.
7. Diagrams/Visual Suggestions
*Naming Architecture Matrix*
txt
8. Best Practices
-
Pick One Word per Concept: If you fetch data from the database, decide as a team what the verb is. Is it
get(),fetch(), orretrieve()? Pick *one* and use it exclusively across the entire project. Don't havegetUser(),fetchOrder(), andretrieveInvoice(). Consistency prevents confusion.
9. Common Mistakes
-
Mental Mapping (The "You Know What I Mean" Trap): A developer writes
$arr = [1, 2, 3]; foreach($arr as $a) { echo $a; }. The developer thinks, "It's obvious $a means the array item." Six months later, inside a 50-line loop, someone forgets what$astands for. Never force the reader to mentally translate your abbreviations.
10. Mini Project: Refactor Naming
Scenario: A developer wrote this confusing user verification check. Fix the naming. *Before (Messy):*
php
*After (Clean):*
php
11. Practice Exercises
-
1.
Critique the variable name
$flag. Why is it bad, and what are three better alternatives depending on the context?
-
2.
Explain why classes should be named using Nouns (e.g.,
ReportGenerator) rather than Verbs (e.g.,GenerateReport).
12. MCQs with Answers
Question 1
According to clean code naming conventions, which of the following is the most appropriate name for a function that retrieves a customer from a database?
Question 2
Why should developers strictly avoid using generic variable names like $data or $info?
13. Interview Questions
-
Q: During a code review, you notice a developer named a boolean variable
$email. How would you coach them to improve this name, and why?
-
Q: Explain the concept of "Intention-Revealing Names." Why is typing a long name (e.g.,
$daysSinceLastLogin) preferred over a short abbreviation (e.g.,$dsl)?
-
Q: "Pick one word per concept." Explain this rule. What happens to a codebase when a team mixes
fetchData(),getInformation(), andretrieveRecords()randomly?
14. FAQs
Q: Is it okay if my variable name is 30 characters long? A: Yes! A long, descriptive name like$maximumAllowedLoginAttempts is infinitely better than a cryptic short name like $maxLogAtt. Modern IDEs have autocomplete, so typing long names is no longer a valid excuse for poor naming.
15. Summary
In Chapter 3, we tackled the hardest problem in Computer Science: naming things. We established that every name in our code is a message to the future. We learned to use clear Nouns for variables, decisive Verbs for functions, and interrogative questions for booleans. We declared war on ambiguous, lazy terms like$data and $manager. By treating naming as a critical communication tool rather than a minor typing chore, we lay the groundwork for a deeply expressive, self-documenting architecture.