The Array Prototype Naming Convention

Charles Stover
9 min readMar 21, 2022

This article is an opinion piece about a code style for a function naming convention. This article does not intend to be a source of truth for all teams, but you yourself or your team may choose to adopt or enforce this pattern if you so desire to experiment with or document your team’s code style.


Function names based on array prototype methods are self-documenting and encourage correct abstractions. They can be understood without prior knowledge of the overall system, because they focus on what is being done instead of how it is being done, by focusing and limiting the naming convention to (1) the input data structures, (2) the action performed on them, and (3) the output data structures. Defining the input, the action, and the output enforces that functions do one thing and do that one thing well. The addition of additional actions to a function encourages the creation of a new function matching that action’s naming convention.

When it comes to abstractions, this naming convention is not coupled to the idea the DRY (Don’t Repeat Yourself) principle or WET (Write Everything Twice) principle. Your team may choose to continue being DRY or WET. In both cases, this naming convention encourages reusable and testable function design.

Why array prototype methods?

Array prototype methods assign verbs on common actions. There are rarely predefined functions or action verbs for changing single inputs. That’s left as a challenge to the engineer, and exactly what we’re trying to name by writing such functions ourselves. There are, however, action verbs already defined in the JavaScript language for applying said function to an array of inputs. We base our verb nomenclature on these array methods, because it offers self-documenting familiarity for the reader. It is also surprisingly common to need to use apply these functions to arrays.

Naming conventions


The method takes an item as input and returns a different interface as output. The call signature for such a function is (item: T) => U or in rare circumstances (item: T, index: number) => U.

The naming convention of map functions is mapXToY, where X and Y describe the input and output interfaces respectively.

An example of this naming convention follows: