Prev: OID_802_11_BSSID_LIST_SCAN
Next: get unicode character OEMTextOut
From: Robert Marquardt on 1 Jun 2005 02:05
Pavel A. wrote:

> ?? So where MS prefers a bad style? C++ is a standard language, you're free
> to format your code as nice as it gets....

USBVIEW for example.

if (!success)
{
OOPS();
return NULL;
}

and four other checks with only different if expression in sequence.
How about a simple helper function like oops() returning NULL?

if (!success)
return oops();

Then a longer expression for the if reduces the number of lines without
losing clarity.

Also goto is used often. goto is always a sign of bad programming style.

The DDK examples are the blueprint for many commercial projects. They
should teach a better style.
From: BobF on 1 Jun 2005 06:51
On Wed, 01 Jun 2005 08:05:04 +0200, Robert Marquardt wrote:

> Pavel A. wrote:
>
>> ?? So where MS prefers a bad style? C++ is a standard language, you're free
>> to format your code as nice as it gets....
>
> USBVIEW for example.
>
> if (!success)
> {
> OOPS();
> return NULL;
> }
>
> and four other checks with only different if expression in sequence.
> How about a simple helper function like oops() returning NULL?
>
> if (!success)
> return oops();
>
> Then a longer expression for the if reduces the number of lines without
> losing clarity.

I've seen this - and seen it debated - a lot. One could argue that the
four successive if blocks make the code easier to follow. Everything you
need to understand is in front of you. 'return oops()' forces the reader
to some other place in the code, or even another file to figure out the
functionality.

I don't have a concrete number in mind, but I would much rather sift
through a small number of if blocks. 37 blocks would certainly be too many
....
From: Wan-Hi on 1 Jun 2005 07:22
i admit you are definitely right. i did not go through many cases in mind.
just one of many things that makes me just an amateur and you a pro. i will
keep in mind to expect exceptional use cases. thanks.

"Mark Roddy" wrote:

> Why on earth would you think that? What happens when a user pulls a
> flash drive out? Where's the volume then? Server systems are frequently
> attached to or contain storage enclosures that allow for hot
> insertion/removal of physical disk devices. Of course you have to test
> for errors.
>
> If an api can return an error you need to check for the error condition.
> However you do have a valid point regarding 'readablility' of the
> code. The error handling can certainly clutter up code with tests for
> conditions that are unlikely to happen. The problem of course is that
> 'unlikely' does not mean 'never'. Oh well.
>
> I tend to encapsulate common sequences of API calls in subroutines (or
> in C++ classes) which bury the ugliness in a cleaner interface.
>
> --
>
> =====================
> Mark Roddy DDK MVP
> Windows 2003/XP/2000 Consulting
> Hollis Technology Solutions 603-321-1032
> www.hollistech.com
>
From: Wan-Hi on 1 Jun 2005 07:33
the fact that excessive if block 'nesting' causes maintainance problems was
the very reason why i reconsidered my way of failure checks and asked you.

i don't really believe that it's generally caused by a bad algorithm.
logically

if (failure)
{
do clean up;
show error;
return;
}
else
{
if (nextFailure)
{
do clean up;
show error;
return;
}
else
{
...
}
}

is logically more correct than a code avoiding 'else' blocks. in my opinion,
functioning code avoiding 'else' blocks is a result and benefit of the
language specific 'code execution path'. so the algo is not that bad, but the
design is. this does not mean that i hold up the opinion to use 'else' if
unnecessary. i also second you that i should reconsider my design when i
encounter excessive if block 'nesting'.

"David Craig" wrote:

> If you are coding if blocks within if blocks more than three or so levels
> deep, you need to reconsider your algorithms and design. It is not
> necessary. It leads to bad results since the code becomes far more
> difficult to debug, understand, and maintain. Most bad code can be fixed
> with better algorithms and a redesign. That 'do once' block helps limit the
> depth to which you must nest 'if' statements. Version 1.0 of most programs
> and drivers can and should be discarded for a better design later.
> Commercial pressures make most of us keep the old code, so then you just
> have to improve it block at a time as you have the time or you need to
> modify or fix a particular area.
From: Robert Marquardt on 1 Jun 2005 07:50
BobF wrote:

> I've seen this - and seen it debated - a lot. One could argue that the
> four successive if blocks make the code easier to follow. Everything you
> need to understand is in front of you. 'return oops()' forces the reader
> to some other place in the code, or even another file to figure out the
> functionality.

You are wrong. A function oops() or a macro OOPS() are equivalent in
understanding the functionality.
What i dislike is the 4 lines needed (plus the empty line). With 5
blocks you get a staggering 25 lines where about 5 would be sufficient.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: OID_802_11_BSSID_LIST_SCAN
Next: get unicode character OEMTextOut