C# Coding Standards by Lance's

re: C# Coding Standards by Lance's

Robert — Tue, 16 Dec 2008 14:21:26 GMT

In our coding experience, we found it incredibly useful and important to be able to instantly distinguish between a class level field and a local function level variable. using the same naming guidelines for both (ie, camel casing) can be confusing. Prepending the _ onto the field level variable instantly identifies it as a such.

Rob

Interesting Finds: 2008.10.12

gOODiDEA — Sun, 12 Oct 2008 02:24:00 GMT

.NET ASP.NETMVCandthenewIIS7RewriteModule

My10commonmistakesinASP.NET

C#CodingS...

re: C# Coding Standards by Lance's

JV — Fri, 10 Oct 2008 15:29:56 GMT

@mohanbrij: I understand the reasoning why to use prefixes, but my most important argument is that you can also easily see that something is a private variable without the underscore (Even without using intellisense and syntax highlighting). The same arguments for enums,classes etc fit for those private variables. Even in notepad it's easily distinquisable when you use the approriate casing (Which is also defined in the document).

But I do think it's a minor thing (I don't even wanna call it an issue/problem). It's a good document :). It's just something I see in lots of guidelines, but whenever I confront the author with it, it always ends up in: "I prefer/like to do this this way" (Nothing wrong with that) or legacy reasons. So I'm always intrested in the thoughts behind it :)

re: C# Coding Standards by Lance's

AndrewSeven — Fri, 10 Oct 2008 13:02:35 GMT

That seems to have improved since that last time I looked at it, but all the same, I would suggest using the "Framework Design Guidelines" as the starting point for any coding guideline.

If you want to be strict, you can use Style Cop, but it has several rules like spaces vs. tabs that some of us don't like.

From the Framework Design Guidelines:

"DO name Generic parameters with descriptive names, unless a single-letter name is completely self-explanatory and a descriptive name would not add value"

"Consider using T as the type parameter name for types with ONE single-letter type parameter"

"Do prefix type parameter names with T"

"Consider indicating constraints placed on a type parameter in the name of the parameter"

re: C# Coding Standards by Lance's

mohanbrij — Fri, 10 Oct 2008 12:16:18 GMT

Hi JV,

In Line 2.1.16, When he said avoid adding redundant or meaningless prefixes or suffixes, it means when we are defining enums, we already know this is enum, so it looks redundant when we name something like ColorEnum, similarly for Struct, Class, etc.

Also in Section 1.4.1 and 2.2, accordint to microsoft coding standards its good practice to prefix the private variable (field, constant, static fields) with _underscores, similarly in section 2.2 please see he is using only the private variables with _usderscores.

What I found good in this document is it covers almost everything, section 5 also explains the important Object Model and Design API in very few words. Which is all we need very often.

re: C# Coding Standards by Lance's

JV — Fri, 10 Oct 2008 11:43:43 GMT

Nice guidelines indeed, however it does contain some contradictions. Eg 2.1.16 says "Do not use public enum ColorEnum" (avoid redundant or meaningless prefixes and suffixes), but in 1.4.1 and 2.2 he does use redundant/meaningless prefixes (the "_") several times. Those are not necesary at all in C# and the goal when you use them is the same as using suffixes for ColorEnum.