Naming conventions for function parameter variables?

Question

Is there a naming convention or maybe some guideline on how to name function parameters?

Since forever, I have been doing it like this:

function divide( $pDividend, $pDivisor )
{ ... }

That way I'll always know which variables were passed as parameters.

(This one's PHP, but it should be applicable to most programming languages)

Is there one major reason against this?

Is there a better way to do this or is it probably best to just avoid such naming schemes?

Answer 1

I think taking the advice of Code Complete regarding naming -anything- would be justified it's whole chapter 11 is on naming variables properly):

• Don't name it j, k, i, m, n (unless it's just for an iteration) or "placeholder" or "test". When the "test" works, I often don't take the time to rename the variable wherever it's been listed.

• Call it a descriptive name that's separate from the code's function ie "EmployeeComments" not "XMLEmp_Comment_File" because a lot of that information (XML, external file) could change, but that the program's working with "Employee Comments" won't

• Keep it as broad and human readable as possible so you're coding in English (or your language) not $j=$k/sqrt($pi); or something equally unintelligible.

As for parameters specifically, I've never used the P notation. I like the idea, but if you named them right wouldn't it be clear they were the parameters for the function?

Answer 2

I have naming conventions for some variables, like member fields or static fields, because the declaration of the variable may be far away from the code where I use it. For parameters or local variables I do not use anything, as usually the variable definition is about ten lines away.

Especially in the all IDE camp people seem to get more and more to dislike any prefix or suffix, as "the IDE provides highlighting". Well, it doesn't help me, and I dislike having semantic information only available as color. However, I can see there point, as the variable name should make the most important information clear, and if it doesn't, nothing helps.

So, this is more about style. Good naming is more important than good prefixes. For the schemes: pick one, stick to it. This will help the poor maintenance developer. Yes, those are the people who usually also prefer { } around single statement blocks and so on, but it helps.

Answer 3

I've heard that some people will keep their function parameters one style, with the type of data a the first part of the variable (array = arr), and then capitalize the following words:

$arrFormData

where the rest of their variables are in a different style, where the words are all lower case, no type definition, and the words are separated by underscores.

$form_data

Personally, I tend to keep my variables the same as the rest of my variables, purely because on the first two lines of a function, I'm making sure that they are what I expect, or throwing an exception. After that, there shouldn't really be a difference between local variables and variables passed in. But, if it keeps your code clearer to type it one way, by all means.

Answer 4

Hi,

If :

1. your functions/methods are well written and short (as they should be)
2. the variable names are descriptive enough

This practice is not needed.

If you need this, it means that the code written is not readable enough (functions/methods too long), cryptic variable/function names, bad OO practices, shortcuts, code debts, etc. :)

So it would be a signal that the code needs to be refactored/improved.

Answer 5

The greatest chance for confusion for me is in member functions. If possible, I like to see differences in naming between:

• local variables: index
• class member variables: m_index
• class static variables: ClassIndex
• global variables: INDEX

This can make it easier to track down what's happening where. However, I agree with Toto that it's best to make your functions short enough so that these conventions don't make or break your ability to figure out what's going on.