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

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 2

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 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

You should follow general guidelines for how to name parameters as you would for other variables (names should be clear, accurate, specific, consistent, and usually 8-20 characters long).

As for the prefix, I would recommend the opposite: leave the parameter unmarked, and mark anything that you do with the parameter in the function as a separate variable. For example:

function upperCase($title) {
    $upTitle = ucfirst($title);
    return $upTitle;
}

In my example, I use a bare parameter, $title. After I transform the input, I call it something else to indicate that it is now in a transformed state, $upTitle. That way I know that it is no longer just the function parameter. Merely calling your parameter $pTitle does not give you quite the same advantage as this consistent approach.

If you think about it, your method marks all the parameters on the interface, which is not the best level. If you look at the API of your program, all your function parameters are marked with $p meaning parameter, which is redundant. You are saying, all of my parameters are parameters, which we already know since they are part of the API. So I would recommend dropping the prefix for the parameter and instead using a series of semantic prefixes that denote what you have done to the parameter to transform it within the function, as in my example.

I disagree with the previous suggestion that you should just make your code more clear. Having clear code does not remove the need for having clear naming conventions.