How to Write High‑Quality Functions: Naming, Parameters, and Implementation Practices

Naming

First, naming is the first step to improve readability. Choosing accurate and elegant names for variables and functions is a common pain point, especially for non‑native English speakers.

Adopt unified naming conventions

Before naming, it is essential to have a unified naming rule. This is the most basic guideline for code readability.

PascalCase and camelCase are the two popular conventions. Different languages may adopt different styles, but the key is to keep the team and personal style consistent.

1. PascalCase: When a name consists of multiple words, each word starts with an uppercase letter. Example:

In C#, PascalCase is commonly used for classes, properties, functions, etc.; in JavaScript it is recommended for constructor functions.

2. camelCase: Similar to PascalCase, but the first word is all lowercase and subsequent words start with an uppercase letter. Example:

camelCase is usually used for fields, local variables, function parameters, etc.; in JavaScript functions also often use this style.

The choice of convention is not absolute; the most important thing is to follow team agreements and language specifications.

Describe all actions the function performs

Short function names may look concise but tend to be abstract. The function name should describe everything the function does to avoid misunderstandings.

For example, when adding a comment and returning the total count, a descriptive name is preferable.

This is a simple example; in real development many more complex cases arise. While the Single Responsibility Principle should be followed, when a function cannot be single‑purpose, its name should still describe all its responsibilities.

Use precise descriptive verbs

Improving this ability mainly requires expanding vocabulary and reading good code.

Avoid overly generic verbs such as "get". Instead, analyze the specific operation:

1. Simple data return

2. Fetch data from remote source

3. Load data from local storage

4. Compute data

5. Search data in an array

6. Generate or obtain data from some source

These examples illustrate that expanding vocabulary and reading excellent source code are key.

Below is a collection of common verb pairs for reference.

Define naming rules per project and requirement

Different projects may require different naming conventions. A common rule is verb‑object structure (verb first, noun after). Some teams use noun‑verb order for data interfaces, e.g., ProductsGet, which quickly indicates a product‑related data API.

Function Parameters

When callers invoke a function, they must strictly follow the defined parameters; this is crucial for usability and testability.

Number of parameters

More parameters generally reduce usability because callers must provide them in order, and a mistake can cause unexpected results.

However, fewer parameters are not always better. Consider the following example:

The function calculatePrice uses global variables unitPrice and count, which is convenient but can cause bugs and hinder unit testing. Passing price and quantity as parameters avoids these issues.

Code Complete recommends limiting parameters to 7 or fewer. When more than 10 parameters are unavoidable, group related ones into a class.

For a hotel filter function, many parameters (city, dates, price, stars, wifi, breakfast, sort, page, etc.) can be encapsulated into an object to simplify the signature.

Avoid boolean parameters

Using a bool parameter like getProduct(true) is unclear without comments. Better approaches are to split the function into two (e.g., getFinishedProduct and getUnFinishedProduct) or replace the bool with a meaningful enum (e.g., getProduct(ProductStatus)).

Do not modify input parameters

Modifying input parameters inside a function can cause hidden bugs and surprise callers. Parameters should be used only for the function call; if modification is unavoidable, it must be documented.

Avoid output parameters

Output parameters indicate the function does more than one thing and can confuse callers. Prefer splitting the logic into separate functions that each have a single responsibility.

Writing Function Body

The function body implements the core logic and is the most critical part of a function.

Group related operations together

Example: calculating room price and breakfast price separately and then adding them leads to scattered logic. Refactoring to group related calculations makes the code clearer and easier to refactor.

Minimize code nesting

Deep nesting (more than three levels) makes code hard to read. Techniques include early returns, using maps/dictionaries instead of long if‑else chains, and extracting inner blocks into separate functions.

If‑statement nesting

Early return example:

Refactored version moves the false condition to the front, reducing nesting to a single if.

Replacing multiple if‑else branches with a map simplifies the code and makes future extensions easier.

for‑loop nesting optimization

Limit nesting to two levels, extract inner loops into functions, and give loop indices meaningful names instead of generic i, j, k.

Extract complex logic and make it semantic

Complex conditions should be extracted into well‑named helper functions to improve readability.

Summary

The article discusses function naming, parameters, and implementation, summarizing key points:

1. Use accurate and consistent naming for variables and functions. 2. Avoid duplicate logic. 3. Keep function length roughly under 20 lines (as a guideline). 4. Reduce nesting depth.

Readers are encouraged to share experiences and improve code quality together.