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

  • 8
    it's a version off hungarian notation that is as useless as systems hungarian for the pretty much the same reason (intellisense) Commented Apr 16, 2012 at 8:00

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.

  • 6
    + Modern IDEs really to remove the need for this. Commented Apr 16, 2012 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
    Commented Apr 16, 2012 at 12:58
  • Syntax coloring replaces Hungarian Notation.
    – user1249
    Commented Jun 4, 2012 at 10:57

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.

  • 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 Commented Apr 16, 2012 at 8:02

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


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.


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.

  • 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
    Commented Mar 27, 2014 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.