Repository navigation
contributing_naming
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.
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 = "";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.
Prefix your variable with date_
Prefix your variable with is_, or are_
Prefix your variables with the primary key and a underscore, (ex: id_user)
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
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.
Copyright (c) 2021 APO Softworks. All rights reserved. Use of this source code is governed by a BSD-style license that can be found in the LICENSE file.