Best Practices for Function Naming in Programming

In 2013 a poll of 4,522 developers asked which programming task they found hardest; surprisingly, the top answer was naming functions and variables, highlighting the hidden difficulty of a seemingly simple activity.

1. Common Function Naming Styles

The two most widely used styles are camelCase (first word lower‑case, subsequent words capitalized) and PascalCase (each word capitalized). For example:

public void setUserName(String userName);

public void SetUserName(String userName);

Both are acceptable as long as a project or language convention is followed (e.g., Java prefers camelCase, C# prefers PascalCase).

2. The Highest Goal of Naming

The ideal is "seeing the function by its name" – the name alone should reveal the function’s purpose. A good name like appendCharacter clearly indicates that a character is added to the end of a string, whereas a vague name like addCharacter leaves the exact behavior ambiguous.

3. Best Practices

Rule 1: Choose Precise Verbs Verbs define the action a function performs. Common verb groups include:

Add/Insert/Create/Initialize/Load (add, append, insert, create, initialize, load)

Delete/Destroy (delete, remove, destroy, drop)

Open/Start (open, start)

Close/Stop (close, stop)

Get/Fetch/Read/Find/Query (get, fetch, acquire, read, search, find, query)

Set/Reset/Write (set, reset, put, write, release, refresh)

Send/Push (send, push)

Receive/Pull (receive, pull)

Submit/Cancel (submit, cancel)

Collect/Select (collect, pick, select)

Parse (sub, extract, parse)

Encode/Decode (encode, decode)

Compress/Pack (fill, pack, compress)

Clear/Unpack (flush, clear, unpack, decompress)

Increase/Decrease (increase, decrease, reduce)

Split/Join (split, join, concat)

Filter/Validate (filter, valid, check)

Rule 2: Use Domain‑Specific Nouns Nouns should reflect the objects being manipulated, e.g., capacity , size , length for collections, or config , settings for configuration. Avoid obscure terms.

Rule 3: Avoid Misleading Names A function named isExpired that also deletes the key hides side effects, violating the "name matches behavior" principle. Refactor either by removing hidden logic or renaming to deleteIfExpired .

public boolean isExpired(String key) {
long curTimestamp = DateUtils.nowUnixTime();
long storeTimestamp = getStoreTimestamp(key);
if (curTimestamp - storeTimestamp > MAX_EXPIRE_SECONDS) {
delete(key); // hidden side‑effect
return true;
}
return false;
}

public int deleteIfExpired(String key) {
long curTimestamp = DateUtils.nowUnixTime();
long storeTimestamp = getStoreTimestamp(key);
if (curTimestamp - storeTimestamp > MAX_EXPIRE_SECONDS) {
return delete(key);
}
return 0;
}

Rule 4: Use "by" Sparingly for Multi‑Parameter Queries Instead of chaining many "by" clauses (e.g., getByNameAndMobileAndAge ), prefer a single‑parameter object that encapsulates search criteria, or use a clear name like getByStudentId when searching by a primary key.

public List
getStudents(StudentSearchParam searchParam);

In summary, investing time in thoughtful function naming reduces future refactoring costs and makes code easier to understand for the whole team.