Skip to content

contributing_naming

Rafael Corrêa Chaves edited this page Jul 18, 2021 · 1 revision

When creating a variable, you must think critically, since it can evolve into a mistery later on in development, making anyone that sees it take more time wondering than actually coding. Below are some keypoints to consider when naming a variable.

Context

Variables should always consider the context they belong to, you do not need to describe that the id belongs to a user model if it's inside it's model. That can end up taking way more characters than necessary and slow down reading processing, mainly when the name ends up being so long that you forget what you were reading in the beginning of it.

// Do this
const id = "";

// Not this
const id_loggedSessionUserClientData = "";

Type

A variable should describe what type they are if it's not a common word or if the name of the variable is the actual type. For example, a type id should not be worried about telling that it's an id (id_id), it's simply id.

Dates

Prefix your variable with date_

Boolean

Prefix your variable with is_, or are_

Relations

Prefix your variables with the primary key and a underscore, (ex: id_user)

The underscore and the camel case

You probably have already seen that we mix underscore with upper letters, but when to use which? Underscores serve to separate types and contexts and camel case when dealing with names that belong in the same context, for example:

//type_name
id_uberClient
userName
is_user

Why type before value

Just like when declaring a table, the underscore would serve as a wall between both, being the type important to make sure you know what you are dealing with.

Clone this wiki locally