Naming your methods and fields while programming can be hard at times, But not impossible and since, there is no concrete guideline about the naming, I made up my own.
You can use these guidelines in your codebase to make the code more readable and avoid mental breakdowns for a maintenance programmer.
Avoid misleading words
Avoid naming your variables data, process, run, do. These words do not mean anything. Literally, any variable in your codebase can be called data, since you are ultimately doing something with data. These words do not correctly inform what they are supposed to do. In such cases, think about it for a few moments and figure out what can be a suitable name for your method or a variable. The generic idea would be avoiding common prefixes that could mislead someone or even you after some months.
You also should avoid names like processData. Think about what is this method supposed to do. Then name it accordingly. For an example, You can name a method processRecentPosts instead of processData?
Follow the existing patterns
Okay, let’s assume that you have various type of objects describing something. Observable, Completable etc. Follow this pattern for the rest of the types. Don’t worry if it sounds awkward and has awkward cases.
Generally, it is better to have those awkward cases than to have a few exceptions lying here and there. Make same mistakes everywhere so that it is easy to identify it everywhere and fix it later if needed. To understand it better,
observe JSONObject that follows neither camel case nor Pascal case. However, on the other side JsonObject has a proper case. Stick to the one and use the same everywhere.
Don’t be afraid of long names
Abbreviations are nice, I agree. However, if something is a document, do not call it doc. Just call it document.
If some method is processing a csv to make transpose of data, call it something like transposeCsvDocument()nottransposeDoc().
Use same names
Call the same variables same thing if you pass them to and fro. For an example, If you have a boolean isActive, while passing it to another method, call it isActive only. Using a different name should have a proper reason.
Moreover, avoid reassigning variables. An assignment like var isActiveForThisBlock = isActive. It does not make any sense and has no clarity. Reassign if the type of data and value for isActive changes and needs a proper new name.
Do not name internal modules
Do not name the internal modules of the whole project or infrastructure after Star-Wars, Different birds or Greek gods.
Just name those modules what they do. Creative names for such modules are nice and funny, but it can be annoying when you are onboarding someone. Even worse when you have to maintain a cheat sheet for what the modules are for. For an instance, if there is a module which handles message queue, name it message-queue and get done with it. Do not name it white-pigeon or such.
When something gets refactored, Change names
After refactoring how a method or class works, change the names. Staring at the code and see if the method definition justifies its name. For an example, there is a method that renders PDF files, But now it just sets up the data for another method which will be rendering the PDF. In such cases, if you do not refactor the names, It will be misleading for someone and waste a couple of hours figuring out what the hell is going on if the codebase is complex.
Always remember, when your naming game is strong, you can completely rely on names. You look at some random method in your codebase, and you can guess what is really does. Choosing a good name is time-consuming, but at the end, It is time well spent for you and your team members.