.NET Naming Guidelines (C#)

Can anyone guide me what is wrong with the naming conventions
suggested below? I know that this is not recommended by many
(including Microsoft) but I need to know what exactly is the rationale
behind going for a different convention in .NET. The recommendations
do make sense (to me, at least but I may be wrong and would like
someone to correct me).

Scope Prefixes
Member Variable Prefix: Most of the people still use (and like the
idea of) prefixing member variables. Selection of prefix still remains
debatable. A lot of people use underscore to declare a member
variable. Use "m" as it also matches the convention generally followed
in VC++. Use of "this." in the code everywhere where a member variable
is used is clearly an overhead and there have always been a high
percentage of developers who tend to omit this causing standard non-
compliance. Hence this is not recommended.

Parameters Prefix: Length of a vast majority of functions in code
could easily go beyond 70 lines. Normal editors, viewers and IDE
support a maximum of 35 lines viewable at one time (at a resolution
1024 x 768). As one scrolls through lines of code (e.g. when reviewing
the code), it is important to readily identify if the parameter is a
local variable or is being passed in the function from outside. Use a
parameter prefix (e.g. "r" for inputs, "p" for out, ref).
It is also important to note that developers do not ALWAYS use Visual
Studio IDE to view / modify code hence IntelliSense cannot be taken
for granted. Examples where the code is viewed / modified outside IDE
is checking code file differences with Visual Source Safe (or other
such tools), doing code reviews, checking code files on deployment
machines and modifying ASP.NET code-behind files on deployment
machines to provide quick fixes.

Hungarian Notation / Type Prefix: This is now regarded as a bad
practice by Microsoft and many others. The full Hungarian Notation
(with every type having a unique type prefix) is impractical anyway.
However "Light" Hungarian, i.e. the use of Hungarian Notation only for
primitive types (i.e. a limited list; not for all types) still helps
to identify if a particular variable is being used appropriately (by
identifying its data type from prefix) and to check boxing / un-boxing
of variables without going back & forth between variable declaration &
usage.

Constants (not readonly fields) should be all uppercase with
underscore as separator (matches the convention for VC++ and Win32).

.

Relevant Pages

  • Re: .NET Naming Guidelines (C#)
    ... The recommendations ... Member Variable Prefix: Most of the people still use (and like the ... practice by Microsoft and many others. ... The full Hungarian Notation ...
    (microsoft.public.dotnet.general)
  • Re: How to name variables in a program?
    ... Ever since I picked up the book Windows programming book by Petzold, ... been using something called "Hungarian notation": ... this convention works with prefixes to indicate variable type. ... I use just the prefix, so unlike what philip states, I do get variable names ...
    (comp.programming)
  • Re: silent semantic changes with reiser4
    ... was just a style convention for metafiles, ... prefix with a subdirectory ... > that one could ls it to see all the builtins supported by a given ... applications) don't trip over this stuff, it is a moby nightmare security ...
    (Linux-Kernel)
  • Re: To Hungarian or not to Hungarian
    ... standard found at: ... The argument was "Hungarian notation is no longer the recommended practice". ... The prefix should either be 2 or 3 characters long. ... Counter variables can be i,j,k but anything else gets a word - TempString, IsEmpty, AnimalType. ...
    (borland.public.delphi.non-technical)
  • Re: Questions about components naming convention
    ... Should I use the same prefix for components which have the ... hungarian notation is not necessary as long as you give your variables ... TeamBUG support for UK-BUG ...
    (borland.public.delphi.language.objectpascal)