POV-Ray : Newsgroups : povray.off-topic : Visual C# .net (and XNA) first impressions : Re: Visual C# .net (and XNA) first impressions Server Time
5 Sep 2024 01:18:10 EDT (-0400)
  Re: Visual C# .net (and XNA) first impressions  
From: Warp
Date: 9 Oct 2009 11:59:30
Message: <4acf5de2@news.povray.org>
scott <sco### [at] scottcom> wrote:
> One little niggle I had to start with was that when you define a class, you 
> need to write the code for all the methods of that class in the definition 
> too (in C++ I would usually put the actual method code in a separate file). 
> Actually after a few days of coding it doesn't really bother me now, I got 
> into the habit of "collapsing" the code in the IDE using the +/- icon so 
> that there is just a list of methods.  If you want to view or edit the code 
> for a certain method you can just expand it temporarily.  I'm even 
> contemplating that this is actually a better way to manage classes than 
> always having two separate files for each class that must be kept in sync 
> (eg to add an extra parameter to a function you always have to change it in 
> both files).

  You can do pretty much the same thing in C++, by implementing the methods
in the class declaration. Of course this is recommended only for small
classes. With large classes you'll end up with a megaclass which will be
hard to understand and maintain, so it will cause more trouble than it's
worth.

  While not very common, sometimes classes become quite large, not necessarily
in the amount of public member functions and private member variables, but
in the sheer amount of code required to implement the class. It becomes even
larger if the class has inner classes and other such types. These inner
classes have to be implemented somewhere as well, naturally.

  Sometimes it's useful to be able to separate the implementation of such a
big class into two or even more files. I have done that in practice with
some such classes. This can happen when the class is more like a big module
(which has to be instantiated, perhaps several times, so a simple namespace
won't do) which has quite a large amount of functionality inside (even if
its public interface is relatively small).

  For example in one work project I had such a class-module. Internally the
functionality of the class could be divided into separate, more or less
independent parts. Thus it was only logical and natural to implement those
parts in separate files (thus I had one header file and several source files),
which kept the individual source files under manageable sizes. Also inner
classes could be implemented in their own separate files, which helped in
lessening the amount of clutter in the "main" source file for the class.

  At the university here they had the rule of thumb that 1000 lines of code
is a good upper limit for a single source file (of course this is a very
soft limit). I have tried to obey that rule of thumb, and I have found it
a rather sound advice. If source files grow significantly larger than that
(eg. 2000 lines or more), they become quite hard to manage.

-- 
                                                          - Warp


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.