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.

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.

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.

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.

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