Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

share|improve this question
7  
it's a version off hungarian notation that is as useless as systems hungarian for the pretty much the same reason (intellisense) –  ratchet freak Apr 16 '12 at 8:00
add comment

6 Answers

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.

share|improve this answer
6  
+ Modern IDEs really to remove the need for this. –  Martijn Verburg Apr 16 '12 at 8:01
2  
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) –  Svish Apr 16 '12 at 12:58
    
Syntax coloring replaces Hungarian Notation. –  user1249 Jun 4 '12 at 10:57
add comment

Such a scheme makes little sense for two reasons:

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

share|improve this answer
1  
for point 2 it is also advised to always use getters (in java at least) so the only variables addressed dirrectly are locals and parameters –  ratchet freak Apr 16 '12 at 8:02
add comment

Java allows you to assign a value to formal parameters, e.g.

public int sum(int a, int b) {
    a = a + b; // valid but evil!
    return a;
}

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.

share|improve this answer
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

There is no reason to use such prefixes, since Java uses shadowing of class fields. Use the this keyword and your code remains readable.

I personally prefer to add a "_" prefix to every parameter. Useful with auto completion. When i type _ it filters the list to only parameters.

share|improve this answer
    
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. –  supercat Mar 27 at 21:34
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.