I often see projects (in Java projects and teams using Eclipse) that prefix function parameters with p.

For example

public void filter (Result pResult) ...

I personally don't see any benefit in this, but would like to know what the reasoning is. The best explanation I've heard yet is that it is to distinguish the name of identical named fields.I have my issues with that explanation but I can understand the point.


The practices of adding meaningful prefixes to symbols, such as the well-publicized Hungarian Notation, date back to the times when IDEs did not exist or were too primitive. Today, when finding a point of declaration is a mouse click away, there is no point in spoiling the most precious part of the name, its first few letters, by assigning a common prefix.

  • 10
    Systems Hungarian Notation is a terrible practice that should be avoided. On the other hand, some Apps Hungarian Notation can be useful (such as for preventing unsafe user input from getting misused). Aug 17 '12 at 14:34
  • 7
    @Darthfett: Even that sort of hungarian notation seems to be trying to implement an ad-hoc, manual type system directly in the variable names. Just use a good statically typed language and have a real type system track things like that for you automatically! Aug 17 '12 at 19:46
  • 1
    @WyattBarnett Systems Hungarian doesn't give a programmer any useful information with modern IDEs. Apps Hungarian can reduce headaches in code reviews when they are correctly enforced. Aug 17 '12 at 20:01
  • 2
    @TikhonJelvis Not all languages support typedefs that are strongly enforced (e.g. C++ typdefs). For the languages that do support it, you are quite right. Aug 17 '12 at 20:05
  • 4
    @Darthfett: In C/C++ you can just wrap it in struct/union with one element. Aug 17 '12 at 20:22

As you suspect, it is to avoid name collisions between the parameter name and either member or local variable names. Member variables are sometimes given a prefix for the same reason (e.g., m_result). Personally, I prefer to just use the this prefix for member variables if there's a name collision. It's built in to the language and everyone already knows what it means.

  • That is what I do. Not using a prefix also helps in Eclipse when calling the method. If you built your object tree and name the variables like the parameter names of the method you like to invoke, it works like a charm, but if the parameter names are prefixed this doesn't work.
    – oschrenk
    Aug 17 '12 at 14:27

I only use a parameter prefix when the parameter is intended to be assigned to a member variable, such as a constructor or a setter.

Paint (newColor) {
  color = newColor;

For me, I find that using a different variable name is more blindingly obvious than using the "this" prefix.

For other situations, I avoid using a parameter that could be easily confused with a member variable.

If a method or class is so big that it is hard to tell what the variables mean, the real solution is to break it up into smaller methods/classes. Using prefixes is a band-aid solution that does address the underlying problem.

  • Personally, I prefer to abbreviate the parameter name in that case (e.g., Paint (clr) { color = clr; }). ...There usually isn't much ambiguity, although color -> clr in particular may be an exception. Nov 27 '18 at 22:14

If you make a standard to use 'p' as a prefix with each method parameter name, you can easily recognize the method parameters in rest of the method body.

It saves your time to find the method parameters. You can debug your code easily.

  • 1
    If you are unable to tell what is a parameter and what isn't - your method is probably written badly. Maybe it is too long or use too many unstructured variables? Either way it seems like a different problem addressed by adding unnecessary prefixes.
    – jakubiszon
    Mar 19 '19 at 13:13

Short - This practice makes code harder to read.

Long - I will argue it is a bad practice only used to support other bad practices. Let's examine a couple reasons why using such prefixes could be considered helpful:

  • Avoiding collisions in variable names

    • Do your parameter names express exactly what the parameters are? If you have a parameter and class field which are "exactly the same" you do not need a parameter.
    • In this case it only makes sense to use prefixes for class constructors like the new* prefix described in Aaron's answer. It might also be useful for setter methods e.g.

    public void setHeight(int newHeight) { this.height = newHeight; }

  • Methods take a lot of params, declare a lot of variables and we could easily forget which one is a parameter.

    • As described above - the problem lies in the number of variables.
    • The program is probably not structured well. Check if all the variables are "independent" - perhaps they should be organized in structures or classes. Maybe the whole calculation or process should be wrapped in a separate class just to operate on such number of variables.
    • Even if you needed such number of variables - they should use meaningful names and the prefix is standing between you and the meaningful part.
  • Methods are very long and you need to use prefixes to keep track of what is a param.
    • The problem lies in the length of the methods - If a program is written well you should always see method header and its entire body on single screen.
    • Try splitting the method into smaller blocks.

Except some specific cases adding parameter prefixes only helps with symptoms and doesn't solve actual problems.


I'm a fan of iParam for in, and oParam for out parameters. I'd say cParam for change, but that's not acceptable

  • 2
    Could you explain why you are a fan of this prefixing, what do you gain by using it?
    – Peter
    Jul 22 '13 at 13:26

Not the answer you're looking for? Browse other questions tagged or ask your own question.