The Array Prototype Naming Convention

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.

Benefits

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…