Coding standards

Personally I like Hungarian notation for C#, because I like it for C++.

I have read in Microsoft coding standard articles that Hungarian notation for C# is bad.

I've also read that for member variables you should use '_'.

e.g.

Code:

---

// bad according to Microsoft coding standards
class MyClassBad
{
    private string m_sString;
    private int m_nInteger;
}

// good according to Microsoft coding standards
class MyClassGood
{
    private string _theString;
    private int _theInteger;
}

---

Any thoughts ? I still like Hungarian notation - it's easy to understand and you always know what type the variables are.

And C# is so close in syntax to C++ then why not use Hungarian notation ?

Darwen.

hi
Microsoft also suggest that using _ infront of a variable is bad as well.
__property they may just come up with _property the next time and then we all have to change our code.
I also think Hungarian notation is good, but it looks very messsy
like
MyCar* m_pMyCar // that is fine
PineApple* m_pPineApple //that looks ugly
instead
MyCar* m_myCar // camel casing
PineApple* m_pineApple
then there the thought of how do we know its a pointer or a member variable
well intellisence can help, also reading the code will the you
m_myCar.GetName();
my_myCar->GetName();
what you think

Just my opinions:

Compiler doesn't take care about variables names. If you obey syntax of C# for compiler, all other aspects of your code are for human readability. You should write the code like you were writing a story. You write "John eat an apple", not "Man-John do-eat fruit-apple." In other words, I agree that Hungarion notation is obsolete.

To underscores (_) - only one argument I have heard for using is that if you use it, you can see all fileds together in intellisence. I strongly disagree with writing code for IDE instead for developer. If you want to distinguish between e.g. property and filed, you can use casing and this keyword.

I prefer to use hungarian... It makes me feel so clear when i am reading the code after 3-4 years :))

I use _ for globals and m_ for locals... works perfect...

Hungarian notion is obsolete and even though I used it for many years, I am moving away from it.

I use the following;

Code:

---

// Local variable
int thisIsAVariable;

//Member Variable
int thisIsAVariable_;

and for methods

void MyMethod();

---

but everyone tends to use a slightly different style, so you should just use what you feel happy with.

I also moved away from Hungarian notation since it does not make much sense in type-safe language any longer. Furthermore, it was never a really nice way in my eyes anyway just for the drawbacks it has (for example, it is not a type-safe system).

I am basically using the same scheme as Darka for variables, however I use some more '_' in it... ;) Nevertheless, one will never find any 'My' in my code...

Furthermore, one should usually avoid leading underscores since these are reserved for library implementers...at least they used to be in C++...

obviously MyMethod() was just an example :-)

Just my very private opinions :) :

1) Any coding convetion (CC) U use consistently is a good one!
2) If you plan to share code within a team you must make an agreement about CC with the rest of team (or with organization for witch U write that piece software).
3) If your code is open source somehow and U want that code more understandable for others - than U have to keep on standards (and Hungarian notation is pretty good :thumb: for that)

Now about c# CC:

I really disagree that "Hungarian notion is obsolete" - look for 3)

I agree with Andy Tacker (except that I prefer "_ " for privates and "m_" for public).

It is true that "Compiler doesn't take care about variables names" but peoples really do care ...:cool:

I've heard opinions that any Hungarian notation is obsolete since we have InteliSence and other goodies.... but how InteliSence will work on Notepad, Mail reader, or on printed materials (Documentations or books for example)?

Personally I like Hungarian notation for C# too. But I've made some slight modifications in it. So it is not strictly HN but HN like;) .

Best regards,
Krzemo.

PS: I came form C,C++ so it can affect my judgement :D .

I've never been convinced by Hungarian notation but then I've never had to do C++ in a large project. How does it help the developer? Or is it left over from the days when IDEs were nonexistent and you need all the help you can get when it comes to editing C++ code?

Coming from a Smalltalk background, using meaningful variable names and editing code in a good IDE has always been sufficient. The transition to C# has been relatively painless because of Intellisense. Without it I would probably spend more time in MSDN help then actually coding.

I have to agree that I like hungarian notation too, and I don't think it's obsolete either.

I like knowing what type the variables are.

I like using m_ for members too.

I suppose I've been using Hungarian for such a long time in C++ that I've just grown used to it. Writing C# without it really does feel a little strange.

However, hungarian notation breaks down in C++.NET (at least prior to the newest version on C++/CLR).

Since all classes are in fact pointers it doesn't really make a great deal of sense to have a function like

Code:

---

void SetString(System::String *psString);

---

Especially when they're viewed in the object browser in C#.

What I tend to do is use Hunarian notation in source files, but non-hungarian (or rather de-referenced hungarian) in the header files i.e.

Code:

---

// in .h
void SetString(System::String *sString);

// in .cpp
void MyClass::SetString(System::String *psString)
{
}

---

I just wondered what everyone's thoughts were. Thanks a lot !

Darwen.

Quote:

---

Originally Posted by darwen

I like knowing what type the variables are.

---

Which is exactly one thing where hungarian notation can fail badly...since that is totally up to the developer...if you have declared an 'short' two years ago, it would be named like

Code:

---

short sVar;

---

This variable has been used a several times throughout your application, passed to functions which takes a short etc.

Now....after two years, you realize that 2 bytes isn't big enough any longer and you need it to be an 'int' instead...so, you have to change every occurence of this variable as well as any affected function argument etc. in order to change from 'sVar' to 'iVar'. And many developers did not and simply left it with 'sVar'...and thus immediately had wrongly commented code...

Quote:

---

...so, you have to change every occurence of this variable ...

---

Search and replace? :)

Quote:

---

.. as well as any affected function argument etc.

---

U have to do that anyway (not Hungarian Conv. named vars too).

Quote:

---

And many developers did not and simply left it with 'sVar'...and thus immediately had wrongly commented code...

---

And how do we call them? Bad proggrammers :rolleyes: ?



Best regards,
Krzemo

Andreas Masur:

An example:

Code:

---


void DoSometing(int userid) //eg. 1234
{ ...}
void DoSomething(string userid); //eg. Smith
{ ... }
....

MyClass.DoSomething(uid);

---

"MyClass.DoSomething(uid);" Try to guess which one "DoSometing" is called...:cool: .Of course U can moving around a mouse :) and waits for InteliSence to explain ... But (as I said before) it could be printed on paper or that fragment could be sended to U by email...

But if U have HN variable than "MyClass.DoSomething(szUid);" helps U a litle bit, isn't it?

Of course - As I wrote before Hungarian notation is good as long as U use it consistently.

Best regards,
Krzemo.

I know that there is search and replace, however, bottom line is...it takes time. Time that I usually spent somewhere else. Furthermore, many developers simply don't do it, thus, if I have to look through their code I cannot rely on the correctness of the notation and thus, it is worthless to me.

Having said this (and all the above), I have never said that there is a wrong or right. Everybody is free to choose their own style...and thus, I will not discuss whether the hungarian notation is useful or not. For me it simply isn't...

As to your example....I usually don't care which function is being called aside from my intention. Whether or not is hungarian notation is being used or not does not help myself, since I both know the variables and the functions...the more important thing in my eyes is simply naming variables meaningful...if that is being done, I usually do not need any additional type info.

As I said, this is simply personal preference....you are free to use hungarian notation or any other as you like...

Quote:

---

Originally Posted by Krzemo

U have to do that anyway (not Hungarian Conv. named vars too).

---

Yes...but I would need to do this only at two place (declaration + defintion) whereas using hungarian notation, I would need to do it inside the function for every occurence as well...

Quote:

---

Originally Posted by Krzemo

And how do we call them? Bad proggrammers :rolleyes: ?

---

I never implied that neither mentioned it...

In actual fact manually going through the code to change a short's name to an int's name is in my opinion a really good idea.

You've got far more chance of picking up any places where the change could potentially cause problems.

Now obviously going from a short to an int shouldn't cause any problems anywhere, but doing the reverse certainly might.

And we don't tend to change types of variables very often anyway. At least I don't.

Darwen.

Ok, so we have had some good arguments on programming notation, but what about file seperation? What's the good rule of thumb for breaking an application appart?

Should you have global variables (i.e. Most of the variables used in the app are defined in a single AppDefinitions file, to support modularity and ease of upgrading)?

Should you split the application up by usage (i.e. xml class/namespace for xml operations, sql class/namespace for sql operations, etc)?

And what are you thoughts on nested loops and the limits on the number of tiers?

And anything else you wish to comment on!

One class per file, one task per class and no class greater than 300-400 lines.

Use namespaces to group classes together.

Namespace naming <company>.<large group name>.<sub group name>....

Group roots of namespace into seperate assemblies named the same as the namespace.

ie..

MyCompany.Application >> exe
MyCompany.General >> MyCompany.General.dll
MyCompany.Network >> MyCompany.Network.dll
MyCompany.Network.Sockets >> in the MyCompany.Network dll.

Darwen.

When you say one task per class, would you consider Reading from a database/file/other datasource and Writing to a database/file/other datasource different tasks, requiring different classes? I guess I am trying to find where to draw the line on grouping "tasks".

Potentially, yes. So you'd have a 'Data' class, a 'DataReader' class and a 'DataWriter' class - sound familiar ?

DataReader would accept a Data object to be read, and DataWriter would accept a Data object to be written.

If DataReader & DataWriter have shared data/methods (e.g. hard-coded headings of tables) they could potentially derive from a base class called 'DataSerializer'.

Bear in mind one task per class doesn't mean one method per class.

All of this of course is pretty subjective.

It's possible to come up with some truly elegant designs in C# which would take ages to realistically implement in C++. The events in C# are just one thing which makes this possible.

I find my object oriented designs in C# are considerably more fine-grained than in C++. But they are much better for it.

Darwen.

Quote:

---

Originally Posted by darwen

One class per file, one task per class and no class greater than 300-400 lines.

---

what about custom exceptions for a class? I personally would have them in the same file as the class that throws them. whats you opinion? also, for simple classes, i've been known to put myClass and myClassCollection in the one file also. Granted, if it isn't a simple class, I probably wouldn't, but then, as you imply, all classes should be simple ;)

and for the record, I don't use hungarian (in c#), because as Anreas said, c# is nice and type safe. but in VB6, it is nice because unless you turn Option Strict on you can get yourself into troubles if you don't know the variable type.

I would still argue for one class per file. Then you can find it easily in solution explorer. But it's just the way I do it. I just like having small files...

Presently the only time I have more than one class in a file is when I have a private class defined in a class : e.g. an IEnumerator.

However, with DevStudio 2005 you can have partial class definitions (i.e. class definitions spread over multiple files) and so you can even do these in seperate files too.

But it's just the way that I work.

Darwen.

Quote:

---

Originally Posted by Zeb

what about custom exceptions for a class? I personally would have them in the same file as the class that throws them. whats you opinion? also, for simple classes, i've been known to put myClass and myClassCollection in the one file also. Granted, if it isn't a simple class, I probably wouldn't, but then, as you imply, all classes should be simple ;)

---

I put them into the same header...however, I usually group related objects together into one file, thus, the class itself, the exceptions the class will use, any other helper class (like functors etc.) which work on the class etc.

So, if another developer would like to use this class, I can simply give him one file and not fifteen... ;)

Andreas, why not just give them an assembly ?

In C++ you have header files which determine the methods on a class.

C# is the equivalent to writing all code in-line in C++.

Finding your way around it is far easier (in my opinion) if the classes are seperated out into one cs file per enum, struct and class.

All my articles contain assemblies that people can just include in their projects if they wish without any changes.

I'd personally use an assembly (or in C# a class library project) rather than supplying just a single .cs file.

Quote:

---

So, if another developer would like to use this class, I can simply give him one file and not fifteen

---

15 classes in 1 file ?

And in the process make your code hugely more difficult to understand.

Heck, why don't you just write your entire application in one huge .cs file ? Then you can pass the entire application around in one file.

That's just taking your strategy to extremes of course - but whatever works for you.

I'll stick to giving assemblies to people.

I would ask : would you do this with C++ ? I.e. send 2 files with 15 classes in the .h file and 15 class implementations in a single .cpp file ?

And if they're using a source code control application like SourceSafe then it'd be easy to integrate your code if it's in an assembly.

Not so if you're putting the overhead of drawing out the classes from your .cs file.

In my mind, even 5 minutes overhead is too much if you don't really need to do it...

Darwen.

It's a shame that as developers we still have to worry about files. If the IBM VisualAge products had caught on then development in an OO project would be based on classes not files. Apparently the idea was too radical for it to catch on, too many developers preferred the flat file approach.

I know there is a class browser in Visual Studio but IMHO it's unusable, unless of course someone can tell me how to find a class if I only know its name (or part of it) and not its namespace. Currently I have to resort to a string search across all files.

Note though, that I did not say anything about C# and actually was talking about my C++ development. Nevertheless...I wouldn't create a library for just one class. Thus, my interfaces to a library consists of the necessary classes to deal with the library...that is usually the main class and the supporting structures, classes, exceptions etc.

I simply don't try to over-engineer the whole thing (which would be the one class - one file in my eyes). While looking through source code, I usually don't care whether it is defined within one file or many though...

I hope I didn't cause any offense. I'm just saying what I'd do.

I must admit coding for external sources (i.e. in a consultancy role) where you don't have access to the main code requires an assessment of the situation : in which case 1 class per file may very well be the best way of doing it.

However when working on a project where you do have total access to the main code (or rather the source control mechanism) then I far prefer 1 class per file in C#.

In coding C++ libraries, things are somewhat different. 1 class per .h is impractical. However, I do try to seperate out classes into 1 class per .cpp. And have 1 class per .h if they're private to the library.

This all is of course subjective : it really does depend on

(a) taste.
(b) coding standards of the company you work for.

Darwen.

No...you did not offend me...you should know by now that it is pretty hard to get me upset... :D

As with many other things, there is no right or wrong here either. I know people who actually doing it like you do...one class per file, clearly separated in header and implementation file. Usually they say for clarity and ease of use. That is probably a point...however, when I look at a regular class from me, it usually consists of the following:

• the main class
• the namespace for the class (if the class is inside a namespace, this point does not count of course)
• an average of 5 exception classes (heavily depending on what the class does and what level of recovery is intended)
• probably some helper structures used by the class

If I would follow the rule here...every single exception class (a simple three-liner most of the time) would go into a separate header file (and to be consequent the one function 'what()' would go into a separate implementation file)...having me to include many, many header files into my main class header, it simply does not seem that much practical to me....and that is where I think, this is a kind of over-engineered.

I know though, that C# introduced some kind of different coding-style and in the beginning it varied pretty much from doing everything in one file to separate everything. At the end it is of course somewhat personal flavour... :cool:

That's was I was saying : it's up to personal taste, what you're allowed to do inside of the confines of the company's standards (if your working) etc etc.

However I tend to group classes (if more than say about 3 or 4) which are related to one another using namespaces - not in the same file.

I think I've said just about everything I have to say on the subject now... phew. I can go have my beer now :)

Darwen.

Quote:

---

Originally Posted by darwen

I can go have my beer now :)

---

Grr....I only get coffee here...life is sad... ;)