I'd like to know, why would I want to have a special prefixes for a function arguments, like "p_name", "p_age", "p_sex"? On the one hand it helps to distinguish parameter from local variable or field further in the function body, but would it help? On the other hand, I didn't saw such naming recommendations anywhere including official Java language conventions. Please advise any reasons for using such naming policy

6 Answers
6

You are right, distinguishing variables from parameters and fields at a glance is pretty much the only motivation for doing this. And it isn't a very good one; if your method is so long that such memory hints are necessary, it is too long in the first place. There is a reason why it's strongly recommended to keep methods small enough that they can be taken in completely in one glance, and understanding the roles of all the variables involved is a large part of that.

IDEs will also often highlight fields differently than parameters and other variables (Eclipse does so at least). I'm pretty sure I get a warning as well if I for example in a setter try to set the parameter value rather than the field (this.p = p vs p = p)
–
SvishApr 16 '12 at 12:58

You should count on your IDE to provide means to distinguish parameters from other variables, either through intellisense hints or syntax coloring.

If you wish to further distinguish fields from local variables/parameters, you can prefix them with this.. I believe its use is up to discussion, however at least in case of Java it seems to be a widespread practice.

However, if it's an implemented coding standard in your project, you can question and discuss it, but in the end should abide by it, no matter how senseless it may seem.

I suspect the main reason is a mild form of OCD many programmers are afflicted with, which makes sorting or making things as separate that are already explicitly different feel "right" even when it carries little or no practical advantage.

Another common example for this is having the names of all enums prefixed with "Enum", and keeping them in a separate package named "enums".

However, this is a bad idea as programmers usually expect to access the values passed to the method. A naming convention might help to prevent accidental manipulation of parameters. But there is a better way: make the parameter final. The compiler won't let you assign to a final parameter and I don't see a reason why you should.

The only reason to keep up such a naming convention is consistency and thus readability. This of course requires that people are already used to the p_ prefix style. I personally believe that adding such a prefix decreases readability as these are two characters carrying very little information. These characters are much better spent in a good readable name.

BTW, such assignments won't have an effect outside of the method execution as Java uses call by value semantics for primitives and object references.

I wouldn't mind that if one could declare a field in such a way as to require the use of this with it, always. I think it's icky having an unadorned identifier sometimes refer to a field, and sometimes to a parameter, depending upon which method happens to be using it. Using distinct names will help avoid any questions of whether a programmer's use of a parameter was intentional, or whether the programmer intended to use the field but forgot this.
–
supercatMar 27 '14 at 21:34

For most Java programmers, the answer would have to be "No, there's no reason to do this." Especially the "p_" prefix - you'll find few proponents for that (and those that do use it tend to do so because of habits from other languages).

Having said that, I personally (ab)use Eclipse's feature of adding a method parameter prefix ("a") to fall back to coding habits from Smalltalk (which can't be beaten in terms of readability), where method arguments are typically prefixed with the article "a" or "an" to indicate their more transient nature (as opposed to class or instance variables). Examples are aString (because the method operates on a String that is passed in, not on the slightly more permanent instance variable one, anElement, or 'someAccounts' (for a collection), etc. Obviously most non-Smalltalkers would probably neither condone nor understand this idiosynchrasy ;-) but it does add readability if used correctly and, if you're used to it, it helps to tell method parameters apart from other types of variables (yes, I know most IDEs do that for you, but you can't always rely on code being viewed in them).

Note that I'm not posting this answer to convert all non-Smalltalkers but simply to offer a left-field alternative to using this way of naming arguments that may be interesting to some.