What should we name the files and variables?!

One of the simplest yet most crucial skills a programmer must learn is proper naming of files and variables.
Not only does it make the code more readable, but it also helps you think more clearly, make changes more easily, and collaborate more effectively.

But the key question is:
What name should you choose?


🧠 Principle 1: Go from general to specific

In English, compound names usually go from specific to general:

UserDeleteModal ← means a Modal for deleting a user

But in programming, it’s better to reverse the order:

ModalUserDelete ← we first say “Modal”, then “for user”, then “delete”

Why?
Because when you’re browsing through a list of files or variables, all Modals will be grouped together, as will all Configs.
It creates automatic categorization that saves your brain from unnecessary searching.

Real examples:

PurposeEnglish-style NameSuggested Programming Name
Delete User ModalUserDeleteModalModalUserDelete
Language ConfigLangsConfigConfigLang
Order Confirm ButtonOrderConfirmButtonButtonOrderConfirm

Rule:
[General Type] + [Subject] + [Action] ← structure from whole to part


✂️ Principle 2: Abbreviation is good; omission is not!

Shortening names is fine, but removing key concepts is a disaster.

✅ For example:

auto rv = getReturnValue();
auto cp = renderComponent();
C++

These are clear and understandable within their context.

❌ But:
If you name a file Form when it’s actually a component, one week later you won’t remember what it was.

So if you’re creating a component file for a form, write:

CpForm or ComponentForm

Never omit the type, especially in large codebases or team projects. It prevents confusion down the road.


📚 A Few More Golden Rules

  • Consistency matters more than style:
    If you use ConfigLang somewhere, stick to that structure—don’t switch to LangConfig or LanguageConfiguration.
  • Use nested folders over long filenames:
    Instead of ComponentFormLoginRegister, create a folder structure like:
    component/form/login_register
  • Respect abbreviations, but don’t abuse them:
    cfg, btn, usr are fine. But dltUsr instead of DeleteUser is confusing.
  • You should never look at a name and wonder: “What was this again?”

💡 Summary

Programming isn’t just about writing code; it’s about building a language to express your logic clearly and efficiently.
Naming is a core part of that language-building.

By following just a few simple principles:

  • Start from general to specific
  • Don’t omit types
  • Be consistent

Not only will your code be more readable and organized, but your own mind will stay focused on logic, not on chasing down confusing names.

Leave a Reply

Your email address will not be published. Required fields are marked *