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 was discussing with a senior developper coding conventions to apply to our projects (mainly Java/JEE projects). I disagreed with one convention he proposed:

Instance variable names should start with "_", local variables with "loc", and method parameters with "par", so it would be easy to identify a variable origin and scope.

While he put forward arguments for short-term memory and readability, I disagreed on the fact that it rather decreases readability, IDEs like Eclipse format variables differently depending on their type, and this problem would be avoided with a good class and method design.

Do you have any opinion, arguments or studies that supports my point (or opposes it)?

share|improve this question
You say that you disagreed on "the fact that it rather decreases readability." I'm not saying you're wrong, but what evidence did you provide to support that claim? I'm not aware of any research that says it will decrease readability (I studied cognitive at graduate school psychology before becoming a developer, so this is an area of interest for me.) –  AdamJonR Jan 2 '12 at 9:00
I meant it as it is cluttering. But I don't have any evidence other than my personal opinion –  H-H Jan 2 '12 at 9:16

2 Answers 2

As Wikipedia says on the subject - Rules for naming of java,

Local variables, instance variables, and class variables are also written in lowerCamelCase. Variable names should not start with underscore (_) or dollar sign ($) characters, even though both are allowed. Certain coding conventions state that underscores should be used to prefix all instance variables, for improved reading and program understanding.

According to my experience with coding standards, Instance variable names start with "_" is not much good as wikipedia standards say.

local variables with "loc", and method parameters with "par", as you said it would be easy to identify a variable origin and scope, but it should be for you, not the other programmers who may go through your code for maintenance someday.

As per the Clean Code specification about the methods these should be short as much they can you do for readability and variables names should should not be mind mapped, they should be relevant to your operation that your method perform.

Member/Scope Prefixes, You also don’t need to prefix member variables with m_ anymore. Your classes and functions should be small enough that you don’t need them. And you should be using an editing environment that highlights or colorizes members to make them distinct.

public class Part {
private String m_dsc; // The textual description
void setName(String name) {
m_dsc = name;

public class Part {
String description;
void setDescription(String description) {
this.description = description;

Besides, people quickly learn to ignore the prefix (or suffix) to see the meaningful part of the name. The more we read the code, the less we see the prefixes. Eventually the prefixes become unseen clutter and a marker of older code.

share|improve this answer

This is largely a matter of preference, and as such there is no 'correct' answer. So, this question might actually be closed. But before it does, let me tell you that I totally agree with you. Prefixes decrease visibility as far as I am concerned. Let alone the fact that if there are to be any prefixes, they should be used for more useful stuff, like the original intention of the Hungarian Notation, and not for things that your IDE can provide highlighting for anyway.

I use SentenceCase for instance data (whether variables or constants) and lower_case for parameters and local variables, since there really is very little, if any, difference between the two. I never, ever use headlessCamelCase because it is lame: a single-component identifier looks like lowercase, even if it was intended to be headlessCamelCase.

share|improve this answer

Your Answer


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

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