Be a Thinker First, Then a Doer
Coverage Topic
- Underscore(_) or not underscore with the private member variable
- Golden Hammer - Anti-Pattern
- Personal Preference vs. Best Practice
- Best Practice Guidance
- Shouldn't use var everywhere
- When to use 'var'
- When 'var' can't be used
Let's Drill Down the Basic Concept
The Problem
Adam Rusch is my colleague and he is working as "Dot-Net C# developer" in a team. Code-review is the part of his job responsibility. So, during code review, he was confused about the coding standard for the private member variables. He means, some people use underscore with private variables and some peoples use camel case with private variables. Another issue he knows about is why var was introduced; but now people are using “var” everywhere as a data-type. He is considering C# as a programing languages and .NET as a development platform.
Naming Convention for Private Member Variables
Question
Adam asked me, which convention is standard with underscore or without underscore according to the best practice guidance?
Answer
I said, it depends on the personal preference of the developer; because some people don't follow the standard guidelines, they have their own preference.
But Adam was not satisfied with the answer. Because, if everybody follows his/her own preference then it's difficult to review and maintain for another person.
Investigation to Underscore or not to Underscore
Few programing languages are case-insensitive, for example, say, Visual Basic (old version). In the VB, there is no difference between pascal case (i.e., VariableName) and camel case (i.e., variableName). Therefore, they have to use underscore with the private member variable (i.e, _variableName).
C# is a case sensitive programing language and it knows the difference between pascal-case (VariableName) and camel-case (variableName).
Therefore,
- If C# is a case sensitive programing language, then why am I using underscore (_) prefix before private member variable?
- What is the extra benefit to use the underscore(_) prefix before private member variable?
- Am I a doer only? Few people are following an exceptional convention and so why am I using the same convention?
- Is it the beauty of readability?
- In the best practice guidelines, it is clearly suggested that using camel-case for the private variable, so then what is the problem to follow the general guidelines?
- If people use the underscore with the private variables, then this is an exceptional case. Exception is not an example for the best practice, then why aren't they thinking out of the box?
Solution
Be a THINKER first, then a DOER.
Real-life Investigation
- In C++, underscore was used for private variables. Hungarian notation(i.e, 'm_') was used as a prefix with member variables for MFC. But current practice states "Don't use underscores at-all".
- If I have the same name for the private variables and parameters, then I'm using underscore to avoid the problem. This is not a good reason to use underscore in C#. What happen if people start to use underscore with the parameters?
- Only use underscore, if you are writing unit testing methods. In BDD naming convention, underscore is used with test methods to make it more readable.
For example
Given_Zero_Values_As_Params_When_GetSum_IsCalled_Then_It_Should_Throw_Invalid_Argument_Exception.
- If I use any intelligence tool and if it doesn't have best practices as a default (say default is underscore with private variable), then there is an option to change the default settings.
- I know programing very well to solve any problem quickly. I have implemented hundreds of applications. But if I used to write code according to my personal preference, then it doesn't mean that I know all of the best practices.
Remember, tomorrow doesn't come; but tomorrow NEVER dies.
Underscore vs. this
- If I use same name for the private variables and parameters, then I have to use '
this
' with private variable. - This is good practice, if you use 'this' for all references of the private variables.
Underscore is a Thorn for Private Variable
- Doctor sometimes uses drugs as a treatment to the patient; but now if general people start to use the same drug for their pleasure, then this is illegal; because it is harmful for the human body.
- If I'm in the Amazon rainforest as a survivor game changer, then it's okay to eat some raw food because, there is no alternative option. It doesn't mean that - in my real life, every time I will eat that raw food.
Similarly, I'm writing code using VB (old) or C++. So, in VB, there is no difference between Pascal case (i.e, VariableName) and camel case (i.e., variableName). Therefore, I am using underscore with the private member variable (i.e., _variableName). It doesn't mean that this is the standard for all of the languages.
Therefore the most worst excuse,
- I'm used to use underscore with the private variable
- I personally believe that it is the best.
- I have self-explanation that it is easy to find out the private member variables or easy to read
- I don't need to write 'this' with private variables.
- I don't need to use 'this' when both private variables and parameters have the same name or bla- bla reasons.
Moral Points
I know, some programing languages use underscore. Because, they have some explanation for that.
- Now I want to fit the underscore everywhere. Even I know that C# doesn't have any limitation that it needs to use underscore with private variables. But I want to fit it by hook or by crook.
- This is my personal preference and I'm writing it only for me; in future, nobody needs to maintain it.
- I don't need to worry about the other team members or the best practice guidance.
- Even I am leading a team and I am advising the team members to do the worst practice like me.
These kind of immature thoughts are one kind of anti-pattern such as GOLDEN HAMMER.
I am not writing the code only for the machine or myself. If so, then it doesn't need modern languages, in general, it just knows only 0 and 1.
Remember, I am writing code for humans; so that different people can maintain it. If I write code for me only, then I don't need to follow any best practices. In these case, my personal preference is enough.
Golden Hammer - Anti-Pattern
"If all you have is a hammer, everything looks like a nail."
I'm using particular technology, tools, methodology or architecture to solve all kinds of problems; although I know that there are alternative and better solutions to solve that problem, only because, I'm familiar and used to it.
Personal Preference vs. Best Practice
Definition of best practices:
"A procedure or set of procedures that is preferred or considered standard within an organization, industry, etc."
Think, why do you need international language? Why aren't you communicating using your local or personal preferred languages to the world? We all know the answer, I'm avoiding it to make it short.
If you follow the best practice guidelines, then there is no question at-all. Although, there are some exceptions and they are used to it. They don't care about the best practice. But exception is not the best example to follow. If you follow that, then sometimes be ready to face "okay, but ...".
Best Practice
- Don't use Hungarian notation
- Don't use an Underscore prefix for private member variables.
- Do use camel casing for private member variables
- Do use 'this' for all references of the private variables.(For VB, use 'me')
Keep personal preferences aside, pick the best technique to solve the problem.
General naming convention from Microsoft - "Don't use underscore and Hungarian notation".
References
First Reference
Second Reference
Improper Use of 'VAR' Everywhere
Have Questions
- In the above example, is there the beauty of readability?
- Why am I using var for a simple declaration?
- Why can't I say that, these kinds of improper use, are an anti-pattern?
Investigation to var or not to var
'var' should not be used in simple declarations, as shown below:
When Must 'var' be Used
- Should be used in LINQ
- Should be used with anonymous types.
When Can't It Be Used
There is a restriction, declaring local variables within the method or property, including iteration variable in 'for' or 'foreach' statements.
- As a type of field
- As a type of parameter
- As a return type of method or property
- As a type parameter in generic type or method
Solution
First, be a thinker, then a doer.
Anti-Pattern using VAR Everywhere
Why was var introduced? It was introduced for LINQ, anonymous types, etc.
Now if I use it everywhere, then it is one kind of anti-pattern such as Golden Hammer. So, avoid the anti-pattern. Because, it is like a thorn for the software development. It is better to avoid type guessing.
PLease note:
I apologize, if I hurt your feelings. This is mainly a focus on the best practices in C# language. Few people who are used to their personal preference, this article is not pointing at them. This is general guidance for new developers.