Paul Wilson's .NET Blog

I posted on this a little while back. I also have links to some other coding standards you might care to look at.
http://dotnetjunkies.com/weblog/darrell.norton/posts/550.aspx

Now that everything is an object, using hungarian notation is just too complicated.

Consider nCount - is that an Integer, an Int32, a class derived from integer etc.

Also it is instructive to run FxCop against some of the framework dlls - Microsoft don't always practice what they preach ;-)

Our team follows the Microsoft guidelines for all public elements (including method parameters), while using hungarian inside.

Roland

P.S. One reason why I use hungarian notation:
http://weblogs.asp.net/rweigelt/posts/21741.aspx

Earlier this year we went through the same process. We had a good number of VB6 developers and wanted to put together a standards doc for .NET development to ensure everyone was following the same (hopefully correct) practices. We ended up following most of the Microsoft recommendations. The reason for this was to ensure that our API's were consistent with all the other API's developers would work with in the .NET Framework. Introducing standards that conflicted with what developers would see when working with the framework would have only caused confusion.

While writing the doc I tried to get a lot of feedback from others in the group to make sure it was something they would and could follow. In the end things ended up pretty good. A couple people needed a little guidance during the transition (old habits are hard to break) but I think everyone is pretty glad we broke the old habits early in the process.

Best of luck!
- Steve

I made the transition a while ago from Hungarian to MS's recommended standards for .NET. No problems whatsoever. I advise you and your team to "just do so". My team is currently making the transition as well (from my companies own standards). From what I can observe here sitting behind my desk… they all seem to be smiling and having fun with .NET:

m_me vs. _me

Isn’t all that of a big change, again… just make the transition. The people on “your bus” experience this as another challenge in order to make your company successful in the .NET world.

An interesting comment that you make is that "I don't want to disrupt things too much". I understand that as the 'new kid on the block', that might be a problem, but to be trite:

a. That's what they hired you for. They needed a senior architect to implement standards.
b. The constant is change. If you are in tech, and you can't change, you might have chosen the wrong career.

Ok, that's the opinion part. Now for some other opinions:

I like this opinion, though there's no 'meat' here:
http://www.yafla.com/rants/quality/


The C++ FAQ has a decent take on setting standards:
http://www.fmi.uni-konstanz.de/~kuehl/c++-faq/coding-standards.html#faq-27.1


One last thing - when setting these standards, ask yourself not only what do they do for you today, but how do they allow room for growth?

Examples:
How will use hungarian effect future use of Generics?
Does your coding standard have room to allow for partial classes, etc?
Does your coding standard tie you to Win32 centric ideas? Do they tie you into a certain 'way of thinking', that may restrict the developer from seeing a solution another way? (OK, languages tend to do this more than coding standards, but I think that there is a point to be made here.)

Also, instead of enforcing silly things like 'number of spaces per tab', is a reformatting tool an option?

Don't be too harsh on standard issue. Standard is one, Productivity is the other. Those two things are not in linear relationship.

To me, All public type names, public member (field, property, method) names must go through reasonable reviews. Comments of them are mendatory required to be good enough by the time each associated item is "drafted". They are refined when the related item is refined. Unit test app is also generally mendatory to be completed by the time the type is completed. Weekly status meething is a good chance to go through weekly review on those issues (Hey, Agile).

As to private members and where the left bracket should go, I don't think the rule should be enforced, though general recommendation is good. As long as they are consistant, it is OK.

Dang it! You got me on a rant against Hungarian notation. It was too long for a comment, so I posted it to my blog (linked to my name above). Good luck with the job!

"purpose rather than their implementation"
A little quote from Richard Talent's "rant"

I work in a small team, when I said yesterday that Hungarian notation was not the prefered naming style in .Net, I was asked what I meant by Hungarian Notation...

It is hard to enforce good hungarian, and FXCop makes it quite easy to find and fix all kind of things.

description kya hai