Re: mfc pitfalls
- From: Joseph M. Newcomer <newcomer@xxxxxxxxxxxx>
- Date: Thu, 01 Feb 2007 16:40:24 -0500
On Thu, 01 Feb 2007 19:32:52 GMT, "jmarc" <jmarc@xxxxxxxxxxxxxxxxxxxxx> wrote:
There are many styles of programming.****
Each may vary a lot from one to another,
but not because one or the other is badly
implemented.
But there are practices that are just wrong. You should see some of the outsourced device
drivers I've had to review! Pure crap, written by people who should not be allowed to
program, let alone deliver products. So there ARE bad styles of programming, and they are
very obviously bad.
****
*****
You should have defined the programming
style you want, or those you'l be easy with
afterward, before contracting the outsource.
Writing a specification of what is forbidden (e.g., my "n Habits of Highly Defective
Windows Programs" might be a good start) is also important.
*****
*****
A source code may be very well implemented,
but hard to be understood by someone who
don't know much about MFC tricks.
What is scarier is the programs which show the programmer did not have a clue as to how
MFC works. The code is not only hard to understand, it is hard to understand because it
is wrong. But it is so hard to understand that only someone really familiar with MFC can
see that it is written by someone totally clueless and that ti doesn't actually work. Or
worse still, gives the temporary illusion of working but fails to lock thread-shared
variables, properly free memory, or any of a dozen blunders.
*****
****
Finally, my opinion is that you should be
able to understand the design of the imple-
mentation the outsouce have been followed.
To achive that, I really think the outsource
should be able to provide you at least few
UML diagrams.
UML diagrams are often used as a substitute for thinking, and definitely as a substitute
for proper design. My experience in this has been fairly consistent. I've seen code
delivered with massive UML diagrams that accurately reflect what the code does;
unfortunately, the code is wrong, so the UML diagrams are wrong. But they are impressive,
and they satisfy someone's requirement that the code have UML diagrams.
When I was first learning to program, back in 1963, we were told that flowcharts were
essential. You wrote your flowchart and all you had to do was translate it to code. The
flowcharts fell into three categories: (a) high-level diagrams which we would now call
'workflow diagrams' but which had nothing to do with actual coding (b) detailed code-level
flowcharts that, once coding started, became irrelevant and obsolete and (c) detailed
flowcharts built from the code, which accurately reflected every error in the code.
Ten years later, I was asked to give a talk at a local college about professional
programming. One student asked me about flowcharts. I pointed out that I hadn't done one
in at least seven years, and that they were an intellectual crutch that rarely had any
value, and they were largely a waste of time and effort beyond your first year of
programming. This so thoroughly pissed off the professor, who treated flowcharts as a
religious experience, that I was pointedly never invited back. But I can now say that I
haven't done a flowchart, except some high-level decision trees for teaching, in about
four decades. I see UML as being the modern substitute for flowcharts.
Last year someone sent me a question about one of the programs on my Web site. He wanted
the DFDs. I had no idea what a DFD was. I had to do a google search. It turns out it
was a flowchart. I explained that I would not waste time writing one of these for a
trivial 15,000-line program, and for larger programs (those in the range of
100,000-200,000 lines) there was no point in wasting time with them because of the large
scale. My message: they're useless for small programs, and they're useless for large
programs, so what good are they, exactly?
What really matter are data structure diagrams to show the relationships of the
information. This is ultimately the only thing that matters. Flowcharts don't help
because they describe process, not information. But I got a program back after five
years, and it was full of "ASCII art" of the data structures; without that, I could not
possibly have added all the new features they wanted.
UML, at least the forms I've seen, define either high-level dataflow diagrams (not overly
useful for programming) or pretend to do detailed analysis...in one case, analyzing the 18
possible states of the state machine (we came up with around 40 states necessary to
represent the problem, but since they'd analyzed "all possible states" the code handled
them perfectly. All the bugs were in the states they didn't analyze! But since there
were UML diagrams everyone knew the code was perfect...)
Well-designed and well-implemented code usually doesn't need UML diagrams (which we tend
to refer to as "software voodoo")
****
... all the class he does implement should be*****
covered somewhere..
For my part, I also like controling all the
graphical resource ID numbers defined in
a project, and their naming, at all time
during the implementation.
It might be surprising, but I also avoid the
use of warning popup, and never use
Try and Catch method. I try to build
applications to stay up and running all
the possible time.
Designing apps that never use popups is an interesting challenge, and I've done it a
couple times. Alas, the file dialog, which in an intelligent world would be an ActiveX
control embedded in a dialog, is a real pain. I should be able to do any of the "standard
dialogs" just by embedding the associated control in whatever window you want. I had to
create my own file dialog, a real pain to get right. I made it a tabbed dialog page in
the master program.
****
****
I highly prefer using a Logger in my framework,
(all situation should be handle), along with a
good Tracer that can be unlock to catch
problems in the field later, if any still undiscovered
during the test phase.
Take a look at my Logging ListBox control ... it appears in every serious app I write.
****
Joseph M. Newcomer [MVP]
.. At least.. Uncommented code might be
a very good hint about that outsource!
jmarc..
"telepet9" <telepet9@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:32AD356D-F048-4798-9CF6-DA5709CCD092@xxxxxxxxxxxxxxxx
Hi,
I need to review code from our outsourcing.
I have some experience with MFC but not to the extant that I can easilly
identify potential problems.
So, can you give me some pointers on what from your experience should be
avoided while programming using MFC. ( We trying to make the outsourcing
to
provide us code that will be easy to maintain/debug )
Thank you in advance.
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.
- Follow-Ups:
- Re: mfc pitfalls
- From: jmarc
- Re: mfc pitfalls
- References:
- Re: mfc pitfalls
- From: jmarc
- Re: mfc pitfalls
- Prev by Date: Re: To Read .mlc Extension Files
- Next by Date: Re: CChildView, a derivative of CWnd
- Previous by thread: Re: mfc pitfalls
- Next by thread: Re: mfc pitfalls
- Index(es):
Relevant Pages
|
Loading
