nnxion

I wanted to know if anyone knows the C# Coding Standard from idesign and what one thinks of them.

I think they are kind of pushy on some things.
I also don't agree with their member variables having a name that starts with m_ . Underscores are not for OOP, this of course is my personal opinion, but I don't see any underscores in the API either.
I also don't agree that many assertions should be made, like it says:
This strikes me as odd, because I'd _always_ check for null, so I'd use:
if(someObject != null); instead of Debug.Assert().

I come from a C/C++, Java background so C# is easy, but can someone tell me if I should use the internal keyword and when I should use it instead of private or protected?

One last English question: Under "Naming Conventions and Style", #24 it says: Shouldn't that be on instead of in?

__________________
"Employ your time in improving yourself by other men's writings, so that you shall gain easily what others have labored hard for."
-- Socrates

Ooble

OK, let's see... my advice: take what ya like, and disregard or make up new rules when you don't like something. The best coding standards are ones you write yourself.

__________________
Me :: You :: Them

MBirchmeier

I appreciate this convention, and here's my reason why:

If private/protected variables are all given an m_ followed by a descriptive name you can use names for function arguments freely without having to worry that one might already be in use. It also prevents accidental masking of what should be standard names. This is the only place I use the '_' and IMO helps re-enforce OOP principles.

The debug.assert is used mainly for development time and not runtime. 'Release' builds generally ignore Debug class statements (more information here

I got the impression the internal keyword opened a function up to anything declared within the namespace, and nothing further I personally don't like to rely on this because frankly I don't like the idea. I either prefer to add it to an interface for use, or restrict it, just saying well i'm making this code so i'll make sure I don't fudge things up isn't a habit I want to get into.

It depends on if you see a line as a container for code, or a surface on which code resides ... it's all the same though.

-MBirchmeier

Kaja Fumei

To quote MSDN:
The main purpose of internal is if you are building a library, internal means only classes inside the library can access the method, field, class or whatever is delcared "internal". Therefore, classes in other "assemblies" (other libraries or programs) that use the library will not have access to anything in the library that is declared internal.

You can also use "protected internal" which is like internal but also allows access in any classes derived from the classes containing the internal data or methods.