Re: Managing a project as it scales

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Alexander wrote:

Thank you for taking the time to elaborate on these topics, Joe.

The last few days have been very interesting. I've read a number of the
articles on your site as well as others that I've found on the Code
Project. I'm still processing all this information, but it is clear
that I have made some obvious and not-so-obvious coding mistakes.

One of the problem areas I have is in error handling, which I basically
ignored (i.e. exceptions) or dealt with in a rather inconsistent
manner. I can address the later but I still have difficulty
understanding the appropriate use exceptions. I mean, even CString can
throw an exception. If I were to try and catch all feasible exceptions
the code would bloat enormously. Or worse, I could implement a
"catch-all" and then not be able to spot legitimate errors while in
development. So the questions is, when and where is a good idea to
acknowledge exceptions? File operations?

Another issue is the manipulation of controls from classes other than
its owner (say, a CDialog derived class). I now realize I shouldn't
pass pointers to controls or even to "this" and use SendMessage or, if
from a thread, use PostMessage. The thing is, how do you identify the
control? It seems you should at least have access to a dialog/window
handle (hwnd). Is that the appropriate method? Updating a progress bar
or a static control from a thread is a fairly common task I implement.
What's the correct approach?

I have also been subclassing to deeply and have ended up having to
populate the base class with scores of virtual methods. My thinking was
that intermediate classes would avoid duplicating code but I can see
how they have complicated the implementation a lot. A rewrite is in
order.

Documentation is an area where I have to start from scratch. I've
looked around and have found some tools (say, Doxygen) but it seems
that your commenting style does not follow a format I recognize. do you
use a documentation tool? If so, which? If not, am I to understand they
are not worth the effort?

Other questions pop to mind but I don't want to tax your patience.
Thanks again.

Alexander


Alexander:

Manipulation of Controls from other classes:

Just don't do it! Don't even tell the class containing the control to do it. Rather, tell the other class what happened, and let the other class decide what to do.

Documentation:

I started using Doxygen this year and I love it (and it's free!). I just annotate the header files, using /// for full-line comments before the item, and //< for end-of-line comments after the item. I do not write very much, but I make sure that all the methods have a simple description and a specification of the parameters and return value, and that each member variable has a brief description of what it is (this is where I use //<).

In the implementation file I don't do as much as I should (I just use simple C++ // comments on their own line or at the end of the line). But one of the greatest programming books I ever read is "Refactoring" by Martin Fowler. One thing he says is something like: "If you see a piece of code with a comment, take that code out into its own (private) method and give the method a name that looks like the comment; then the comment becomes superfluous." Basically, if you use short methods with good names, the code is self-describing. The examples in the book are all in Java, but you know C++ you don't need to know Java in order to follow them. Just a fabulous book!

David Wilkinson
.

Relevant Pages

  • Re: Managing a project as it scales
    ... >understanding the appropriate use exceptions. ... You don't identify the control. ... A second keystroke puts the the REQ#, ... I also introduced a bug, an a week or so later, I fixed the ...
    (microsoft.public.vc.mfc)
  • Re: Real life cost of using exceptions for control flow?
    ... > I know that my view may seem a bit extreme, but it actually works very well. ... > yourself from using exception for flow control. ... I am not at all against throwing exceptions. ...
    (microsoft.public.dotnet.framework.performance)
  • Re: MP, tools & algs
    ... What did Doug in, one of the things, if you read Markoff was that Doug ... Arrays, array handling and inconsistent array state likely also contributed ... exceptions are just alternate control states associated with data. ... "Exceptions" are only considered exceptions because there's traditionally only one flow of control, ...
    (comp.arch)
  • Re: MP, tools & algs
    ... People like to see control dependences as well. ... are juxtaposed in a program trace are juxtaposed in the code (using one ... I consider this similarity of code and trace the essence of structured programming. ... "Exceptions" are only considered exceptions because there's traditionally only one flow of control, ...
    (comp.arch)
  • Re: MFC future?
    ... all ILs assume the programmer wants less control ... ... when people look at IL-based systems today they tend to be thinking of Java ... In Java there can be serious resource management problems because the ...
    (microsoft.public.vc.mfc)