FxCop

  • Thread starter Thread starter cmay
  • Start date Start date
C

cmay

I am getting a messages that I am getting. Maybe someone can help
explain some of these.


Parameter names should use complete words

Type: ParameterNamesShouldHaveCompleteWords

Cause: A parameter in a public or protected method has a parameter that
meets one of the following criteria:

Rule Description
By convention, parameter names do not use abbreviations or Hungarian
notation. Naming conventions reduce the learning curve required for new
software libraries because, for very specialized types, the intended
usage is apparent from the type name. Also, naming conventions provide
a common look and feel for libraries that target the common language
runtime.



My question about this code is:

1) If I remember correct there are lots of APIs (Win32, VB etc) that
have Hungarian notation right?

2) When writing code, Hungarian notation is used to help the person
writing/reading the code to understand the type of the variable. If
you have a function that takes parameters of (Name, Value, File) then
for the entire procedure, you will be using a variable named "Value",
unless you were to first create another variable "iValue" and assign
the parameters to the new variables.

Does this make sense?
 
The new Microsoft standards discourage Hungarian notation. Basically, the
reasoning is that modern IDE's have such good code insight that it is
superfluous to indicate a variables type in it's name. You can just hover
over it for a tooltip giving you that and more. So yes, whilst much old MS
code has Hungarian notation, the latest stuff doesn't (at least .NET
doesn't).

In addition, there's one other slight advantage to not using Hungarian
notation: when you change a variables type (e.g. from int to long) you don't
have to go and search for all instances of the variable to change it to the
new name. Admittedly this isn't a huge advantage with all the refactoring
tools around.
 
Sean,
Thanks for the info.

Does the discouragement of Hungarian notaion extend to normal variables?

In other words is:
Dim iValue as integer
supposed to be
Dim Value as integer

Do you know if Microsoft have a doc out there explaining their standards as
it pertains to this?

Thanks again



Chris
 
Yep, I have found however that having one naming standard for your
parameters and one for your variables is quite a pain, so I've tended to
follow the same scheme in naming my vars. Personally, I use pascalCase for
my params and vars, and a leading underscore for class fields. The only real
reason for that is to allow me to use the same name for a param and a field:

public MyClass {
int _age;

public Class(int age) {
_age = age;
}
}
 
Sean Hederman said:
Yep, I have found however that having one naming standard for your
parameters and one for your variables is quite a pain, so I've tended to
follow the same scheme in naming my vars. Personally, I use pascalCase for
my params and vars, and a leading underscore for class fields. The only real
reason for that is to allow me to use the same name for a param and a field:

public MyClass {
int _age;

public Class(int age) {
_age = age;
}
}
Click to expand...
In more recent years some of the C++ community moved to the
trailing underscore as library vendors have had the habit of
using the underscore prefix for library
specific/non-portable variables, function names and macros.
So in some books from the 1990s you'll see:

m_age (short for member variable "age")

which later transforms to

_age (lazy typist I guess)

to

age_ (avoiding any potential interference with
vendor libraries).

You really don't need it as you can write:

this.age = age;

however the lazy typist in me still prefers

age_ = age

plus I think there is some value to identifying an instance
variable at a glance without being forced to write
"this.age" everytime (Which begs the question: should you
distinguish between instance and class variables
("static")?). However seeing code like

age_.ToString()

may take some getting used to.


'Any fool can write code that a computer can understand.
Good programmers write code that humans can understand.'
Martin Fowler,
'Refactoring: improving the design of existing code', p.15
 
Back
Top