Naming conventions for function parameter variables?

Question

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

Since forever I do it like this:

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

That way, I will always know which variables were passed as parameters.

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

Is there one serious reason?

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

Answer 1

If:

• your functions / methods are well written and short (as it should be)
• variable names are clear enough

This practice is not needed.

If you need it, it means that the written code is not readable enough (functions / methods are too long), mysterious names of variables / functions, incorrect OO methods, shortcuts, code debts, etc. :)

Thus, it will be a signal that the code should be reorganized / improved.

Answer 2

I think that accepting Code Complete's recommendations regarding naming-anything would be justified if all of Chapter 11 were correctly indicated in the names):

• Do not call it j, k, i, m, n (unless it is for iteration) or "placeholder" or "test". When the "test" works, I often do not spend time to rename the variable where it was specified.

• Call this descriptive name, which is separated from the code function, that is, “EmployeeComments” and not “XMLEmp_Comment_File”, because most of this information (XML, an external file) can change, but the program working with “Employee Comments” will not

• Keep it as broad and human-readable so that you can code in English (or in your language) not $ j = $ k / sqrt ($ pi); or something just as incomprehensible.

As for the parameters, I never used the P notation. I like this idea, but if you call them correct, would it not be clear that they were parameters for the function?

Answer 3

I heard that some people will keep their functional parameters in the same style, and the data type is the first part of the variable (array = arr), and then the capital letters of the following words:

 $arrFormData 

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

 $form_data 

Personally, I try to ensure that my variables are the same as the rest of my variables, because in the first two lines of the function I am sure that they are what I expect, or throwing an exception. After that, there really shouldn't be a difference between local variables and the variables that are passed. But if it keeps the code more understandable, enter it in one direction, by all means.

Answer 4

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

Regarding the prefix, I would recommend the opposite: leave the parameter unmarked and check all that you do with the function parameter as a separate variable. For instance:

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

In my example, I use the empty parameter $title . After I convert the input, I call it something else to indicate that it is now in a converted state, $upTitle . Thus, I know that this is no longer just a function parameter. Simply specifying the $pTitle parameter $pTitle not give you the same benefits as this sequential approach.

If you think about it, your method marks all the parameters of the interface, which is not the best level. If you look at the API of your program, all of your functional parameters are marked with a parameter value of $p , which is redundant. You say that all my parameters are parameters that we already know, since they are part of the API. Therefore, I would recommend abandoning the prefix for the parameter and instead use a series of semantic prefixes that indicate what you did with the parameter in order to convert it inside the function, as in my example.

I disagree with the previous sentence that you just need to make the code more understandable. Having clear code does not eliminate the need for clear naming conventions.

Answer 5

I have naming conventions for some variables, such as member fields or static fields, because a variable declaration can be far from the code in which I use it. I do not use anything for parameters or local variables, since usually the definition of a variable is about ten lines.

Especially in all IDE camps, it seems that more and more do not like any prefix or suffix, because "the IDE provides a selection." Well, that doesn't help me, and I don't like it when semantic information is available only as a color. However, I can see that period, since the name of the variable should make the most important information clear, and if not, nothing helps.

So this is more about style. Good naming is more important than good prefixes. For schemes: choose one, stick with it. This will help the poor service developer. Yes, these are people who usually prefer {} around individual blocks of statements, etc., but that helps.

Answer 6

The biggest chance for confusion for me is member functions. If possible, I like to see the differences between the names:

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

This can make it easier to keep track of what is happening where. However, I agree with Toto that it is best to keep your functions short enough so that these conventions do not or do not violate your ability to figure out what is happening.

Answer 7

You can follow the PHP coding standards or php coding standard , which is proposed to be introduced in the main php.

Answer 8

So, after looking at all this, I decided to go with:

ClassName methodName propertyName function_name (meant for global functions) $variable_name

Answer 9

There are many ways to name variables (as you can see from the answers)

But, as a rule, they should be called such that it’s clear that just looking at the variable, what it does and what it is used in, right there and don’t need to go through thousands of lines of code to find out, and not just for those who still need to troubleshoot later, but if your code will be thousands of lines for your own good, if you yourself must fix the problem later

AND THE SAFE CONVENTIONS THAT YOU CHOOSE AGREEMENT THROUGH YOUR CODE - this cannot be repeated enough :)

Personally, I use the following:
the first part of the variable is that it is the second part is intended for what it does / is used for
and for variables needed outside a function, class, etc., the third part is for a function, class, etc., it comes from

Example:
I want to name the variable for the video thumbnail on the first page:
so I start by saying that this (lower_case) - thumbnail
then I add what it is used for (the first letter upper_case) - Video
and since I need this on the first page outside of the function that I end up with the function from which it came (shared under_score) - getVideoAll

Giving me $ thumbnailVideo_getVideoAll

That way, no matter where I look at a variable in any part of the code (HTML, PHP, etc.), I know ...
ah this is a thumbnail for the video that I am trying to show, and if for some reason it doesn’t work, I first do not need to go anywhere to check spelling, and secondly, I know exactly what function, class, which he called (getVideoAll) and can just go there for troubleshooting

If I instead called it $ tnVid, I could personally have a vague idea of ​​what it is, but someone else who looked would not know what tn means (t) humb (n) ail, etc. d.
therefore, to troubleshoot, they will have to first look at the surrounding code to perhaps conclude that this is a likely variable for a thumbnail, and the second - thousands of lines of code to find which function, class, etc. it happened - and that the hours of operation just find what you need, even start troubleshooting - instead of 5 seconds it takes to view thumbnailVideo_getVideoAll and go - oh this is a thumbnail for the video, and I need to go to the getVideoAll function to troubleshoot