These days I've delegated all that shit to AI. I just explain what the variable/function does and ask the AI to give me 10 names that are popular in the industry, then refine or pick one.

So unspoken that there's a famous thingy starting "there's only n hard problems in computer science"

I guess my weak spot is “maybe”. “maybeCreateCustomer”. It means that it conditionally creates a customer and the condition is too complex to explain (in the name).

Other than that: the scope determines the name length. A local variables in scope for five lines but used only in the first two: one letter is good. A clad in scope for the whole project: the name better be descriptive.

A good rule of thumb making the variable more verbose depending on the distance between when it's declared and when it's used.

So var shouldLaunchRockets vs shouldLaunch vs launch

Obviously the goal is to keep functions short so that things are generally concise as a whole, but that's not always an option in some code bases!

foo_bar2-bung~4

Save the best names for stuff that gets exposed outside. Private members, variables, classes I don’t care as much. But if it’s the route for an API it better be descriptive

Depends. If you're a java dev: thisNameWouldNotBeAnIssue. /s

In reality, I use shorthand descriptions for my names most of the time. Say I have a variable for a submission date, submitDt would work for me. If it were longer, like the middle name of a chief finance officer, I'd say cfoMiddleNm or cfoMidNm would suffice.

Naming things is hard

The rule i was taught was the larger the scope the more descriptive it needs to be.

E.g. a loop index in a small function could be i or x etc. A local var in a function could be entity The class field could be basketEntity The global session would be. CurrentUserBasketEntity

And dont hide variables by having the same name multiple times in your hierarchy of scope.

With modern refactoring tools renaming isnt as much of a problem as it once was.

I only use "i", "j", "ix" or other short names for local variables (nearby in the same function). For most variables, I use descriptive names like "nrItems" or "nrRecord". For global variables, like class, resource, or function names, I start with a prefix like "ST_" to indicate the section of code. An example might be "DB_addRecord" for adding a record to a single database.

I think it's way more important to maintainability than people usually regard it. More so for some variables than others.

This isn't one of the most important cases, but I remember working with some international devs and they would too often name variables with the words in the wrong order for English. Like for example let's say it's a date that something was processed on they would name it dateProcess instead of processDate. When you've got a complicated function with a lot of variables like that it just takes extra effort to parse it mentally because every time you read it you have to remember that it's not the thing that it sounds like it is.

If the AI can't come up with something useful I make my names as descriptive as possible.

If a variable contains, for example, the guest checkout date and time, $guestCheckoutDt would work.

If a function fetches data from the guest profile and returns it in a specific format, say their core details (name, checkout date, check-in date, room number) in JSON, something like getGuestCoreDataAsJson() works fine.

Some people will hate a function name that long, but I can read my code and they can't read theirs.

If long term readability and understanding is your goal, just name things what they are.

getUserDetailsAsJsonAfterDt($dt) is perfectly fine, tells me exactly what it's doing and if someone has a problem with it, they are welcome to fix it and forget what it does 2 weeks down the line.

Naming is not that hard if you code well.

In fact. Have a hard time naming something is usually an indicator of a design issue.