Guidelines for naming your codebase effectively

One of the parts that are tricky for our labor as a software engineer is to give names of the components of your code, in different levels sometimes we spend time finding the proper name of the class, variable of package, and more. The difficult part is to try that a class, variable, or method fits with the proposed design and the convention followed by the stack language and the rest of the team.?

Between the standards exists several ways to name your code like Snack case, Lower case, Camel case, Pascal case, and others depending on the stack.?

An interesting research study “To camelcase or under_score ” revealed that camel case increases the readability over underscores, it really all depends on the consistency that you implement in your code. Is not recommendable to have some parts of your code in camel case and others in snack case, with time your code lost quality in this aspect.?

Guidelines for naming your code independently of the stack

Do not use names that are impossible to pronounce or do not belong to the context of the project.?

Probably we can find variables with names like arithmeticTITXCUse, ValueIFForMatter, and so on. Those variables’ names seem like are not related to the words between them or really do not makes sense.

Those kinds of variables are super hard to at least pronounce and much harder to remember it. Instead of it use summarizedBill, valueOfWorkBookSheat.?

Use camelCase.

As we see the paper “to camelcase or underscore” the results are more than evident.?

This is a naming convention that uses capital letters for the first letter of each new word in a variable or function name. For example, the variable name "myFirstVariable" would be written in camelCase. This convention makes it easy to read and understand code, and it is also widely used in the programming industry

Use the vocabulary of the client.

In the phase of gathering, requirements are super important to keep the consistency in the requirements vocabulary, any discrepancies or unclear synonyms used should be removed, to make sure the things the client talk you can implement that behavior in your code. This means using the same words and phrases that the client uses to describe their needs. This will help to ensure that the code is understandable to the client and that it meets their expectations. For example, if the client is a financial institution, you might use terms like "account," "transaction," and "balance" in your code.

The name of the class should be substantive

When naming classes, use names that represent a concept or entity in the problem domain. The class name should clearly indicate its purpose and content. For instance, if you're creating a class to represent a car, a suitable name could be "Car" rather than something abstract like "ObjectManager."

Methods always be verbs?

To make your code more understandable and intuitive, name your methods using verbs that describe the actions they perform. For example, if you have a method that calculates the total price of items, a good name would be "calculateTotalPrice()" instead of something like "totalPriceData()".

If a method returns a boolean, the name should be isNameOfTheMethod

When a method returns a boolean value (true or false), it's helpful to prefix the method name with "is" to indicate its purpose. This naming convention makes it clear that the method is checking or evaluating a condition. For example, if you have a method to check if a user is logged in, a suitable name would be "isLoggedIn()" instead of just "loggedIn()".

Avoid using names like list1, list3, m.

It's better to use more descriptive names for variables, as it improves the readability and maintainability of your code. Names like "list1," "list3," or single-letter variables like "m" do not provide much context or convey the purpose of the variable. Instead, consider using meaningful names like "userList," "orderList," or "message" to make the code easier to understand.

A constant is in upper case NAME_VARIABLE

Constants are values that remain fixed throughout the execution of your program. To distinguish them from regular variables, it's a convention to write constant names in uppercase letters, with words separated by underscores. For example, if you have a constant representing the maximum number of retries, a suitable name would be "MAX_RETRY_COUNT" instead of "maxRetryCount."

variables with one letter, only i,j,k for FOR loops.

While using single-letter variables like "i," "j," or "k" is acceptable for loops where they represent loop counters, it's generally better to use more descriptive names for variables outside of loop contexts. Using names that reflect the purpose or content of the variable, such as "index" or "counter," can make your code more understandable to others.

Use hardcoded values sparingly

It's generally not recommended to hardcode specific values directly into your code. Instead, consider storing values in variables or configuration files. This approach makes your code more flexible and easier to maintain because you can modify the values without changing the code itself. Hardcoding values should be reserved for exceptional cases where the value is unlikely to change.

Abreviatures do not well know or acronyms malformed. Use international abbreviators

When using abbreviations or acronyms, make sure they are widely recognized and understood within the project's context or the development community. Using unfamiliar or obscure abbreviations can lead to confusion and misinterpretation. It's best to stick to well-known and internationally recognized abbreviations to ensure clarity and effective communication, for instance, you can have abbreviations like CEO, OMS, FTP, or someone that are well-known, instead TTC, UUIC, WDIC, or something similar.?

Variable with a super generic name: DataObject, object, studentData.

Using descriptive and specific variable names is essential for code readability and maintainability. Avoid using generic names like "DataObject," "object," or "studentData" as they don't provide enough information about the variable's purpose or content. Instead, use names that accurately describe the data or its role within the program. Something like “result”, “response”, “partialResult” and so on.?

Do not use funny names or obscure ones.

While coding can be fun, it's important to maintain professionalism and clarity in your codebase. Avoid using funny or obscure names that might confuse other developers or make it harder for them to understand your code. By using clear and meaningful names, you create a more inclusive and collaborative coding environment. Believe it or not but I found variable names like “sh*t”, “f*ck”, “highMemorial” and much more. Please do not do that.?

Another painful aspect of the programming is finding proper names for classes, packages, and namespaces in general, the codebase should be organized in function of the client’s requirements but not much coupled with it, should be more flexible to change, but obviously, we are not implementing something without design it first on paper, right??

Here are a few approaches I was using in my entire career to finding classes, packages, modules?names?

Abbott approach

Find all substantives and verbs from the requirements. If a name does not meet that rule create a class name with things like Management, or even events like Click. You can find more information about in this link .

Other strategies or examples to find category names:

• Things, tangibles objets: cars, sensors
• Concepts, non-tangibles ideas: reimbursement, contracts
• Events: request, response
• People: humans, roles, politicians.?
• Organizations: University, Institute, Company?
• Places: Laboratory, Garden.?
• Devices
• Another extern system.?
• Ask for help from the domain expert, the user that uses the system, then they will explain how the system works.
• Draw the classes with the behavioral, and their attributes. All methods are important to put in the class box. The responsibilities matter.
• Find the possible scenarios using diagram uses cases.

Here are the things I use when I start creating a project from scratch or adding any module, or package for an existing project. In terms of development not needing to be added directly to a code, the analysis stage is a good thing to start off on the right foot.

Thanks for reading!?