Printable View
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.
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 ;)Quote:
Originally Posted by darwen
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.
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.Quote:
Originally Posted by Zeb
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.
15 classes in 1 file ?Quote:
So, if another developer would like to use this class, I can simply give him one file and not fifteen
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.
Grr....I only get coffee here...life is sad... ;)Quote:
Originally Posted by darwen