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) {</code>
<code>    long curTimestamp = DateUtils.nowUnixTime();</code>
<code>    long storeTimestamp = getStoreTimestamp(key);</code>
<code>    if (curTimestamp - storeTimestamp > MAX_EXPIRE_SECONDS) {</code>
<code>        delete(key); // hidden side‑effect</code>
<code>        return true;</code>
<code>    }</code>
<code>    return false;</code>
<code>}

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

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<Student> 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.