Prev: OID_802_11_BSSID_LIST_SCAN
Next: get unicode character OEMTextOut
From: David Craig on 31 May 2005 14:16
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.

"Wan-Hi" <WanHi(a)discussions.microsoft.com> wrote in message
news:837701A9-C56D-43B6-90AD-8414314E84D8(a)microsoft.com...
>i understand your point of viewas a professional, but you should consider
>the
> possibility that there are some amateurs among the professional majority.
> i
> for myself deal with the field of device io just for fun and know no
> senior
> programmer i can ask.
>
> coding in a clean style is not the problem. what bothers me are cases like
> if blocks in if blocks in if blocks and so on, just because the api
> function
> i call *might* return a failure code (i assume in some cases this could
> only
> happen if i passed a nullpointer for example). but for the sake of
> robustness
> i live with the thousand ifs in ifs because i can never be sure if a
> different circumstance causes a failure.
>
> i think it's good to hear different point of views from the pros to weight
> the arguments and find an own way how to deal with things.
>
> "David J. Craig" wrote:
>
>> ... If you can't code it clean and easy to follow, you need to go back to
>> school
>> or find something other than a programming job. No one will live
>> forever,
>> much less stay in the same job, so be nice to those who follow and write
>> maintainable code.
>> ...


From: Pavel A. on 31 May 2005 14:49
"Wan-Hi" <WanHi(a)discussions.microsoft.com> wrote in message news:D2CA4989-7791-46FC-8935-DA124B309607(a)microsoft.com...
> I think this is very over-secure code because volumes and disc type devices
> should always be present. therefore no failure should happen.
>
> the second example leaves out failure checks because a condition is
> fulfilled which should make it impossible to fail further API calls:

Ok, if your app is not very mission-critical, and the error is unlikely,
how do you like following "style":

CHECK( some_call );
CHECK( another call );
CHECK( yet_another call );
.......

where CHECK is defined as:

inline bool Check_helper( BOOL retcode ) {
reurn retcode ? true: false;
)

inline bool Check_helper(HDEVINFO h) {
return h != INVALID_HANDLE_VALUE;
}


#define CHECK( expr ) if( !Check_helper(expr) ) return false

or throw exception instead of return.

--PA



From: Pavel A. on 31 May 2005 14:54
"Robert Marquardt" <marquardt(a)codemercs.com> wrote in message news:#TSRLUaZFHA.3732(a)TK2MSFTNGP10.phx.gbl...
> Wan-Hi wrote:
>
> > 2) error checking:
> > SetupDiGetClassDevs and many other functions return a specific value if they
> > fail. so should i check for failure although such case is impossible? e.g.
> > SetupDiGetClassDevs with GUID_DEVINTERFACE_VOLUME should never fail. i ask
> > because useless failure checks make the code unreadable.
>
> The error checks only make the code unreadable because MS prefers a
> *really* bad style. Excessive return and goto is about as bad as it can
> get. A clean if else style and a proper indentation solves that.

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

--PA



From: Mark Roddy on 31 May 2005 22:19
David J. Craig wrote:
> Have you run PC-Lint on that construct? It is not valid K&R semantics in
> that the terminating condition is fixed. I don't necessarily agree with the
> rules, but it is what they gave us. I know many who use it, but I prefer
> clean lint output and will avoid constructs that upset it. I also use the
> maximum warning level, too.
>

I turn off warning C4127. For some reason I dislike for(;;), always
have. I'm not really that fond of do()while(0) either. TRY/LEAVE/FINALLY
implemented as macros that avoid SEH and c++ exception handling work,
and solve the 'inner break' problem, but they don't nest, only one per
function, and they use the dreaded goto.


> "Mark Roddy" <markr(a)hollistech.com> wrote in message
> news:usiBxbdZFHA.2076(a)TK2MSFTNGP15.phx.gbl...
>
>>David J. Craig wrote:
>>
>>>Here is a freebie for those trying to do error checking and avoiding
>>>goto's.
>>>
>>>K&R say the only legal 'DO ONCE' is done using the for command.
>>>
>>>for( ; ; )
>>>{
>>> break; // If OE or ??? warps this, it should be four lines
>>>with this line indented.
>>>}
>>>
>>>You can then do tests and do a 'continue' or a 'break' as needed to exit
>>>or restart the loop. You will forget the terminating break especially
>>>when beginning, but it is legal and works. You can add a __finally to
>>>handle terminating cleanup, but I just usually initialize all locals and
>>>return variables before the 'for' block. Then a test and the appropriate
>>>cleanup can be done to free memory, close handles, etc. after exiting the
>>>block or before returning.
>>>
>>>If you can't code it clean and easy to follow, you need to go back to
>>>school or find something other than a programming job. No one will live
>>>forever, much less stay in the same job, so be nice to those who follow
>>>and write maintainable code. You can add comments to the 'for' loop to
>>>tell anyone looking that this is a 'do once' block and not to get
>>>confused.
>>>
>>>"Robert Marquardt" <marquardt(a)codemercs.com> wrote in message
>>>news:%23TSRLUaZFHA.3732(a)TK2MSFTNGP10.phx.gbl...
>>>
>>>
>>>>Wan-Hi wrote:
>>>>
>>>>
>>>>
>>>>>2) error checking:
>>>>>SetupDiGetClassDevs and many other functions return a specific value if
>>>>>they fail. so should i check for failure although such case is
>>>>>impossible? e.g. SetupDiGetClassDevs with GUID_DEVINTERFACE_VOLUME
>>>>>should never fail. i ask because useless failure checks make the code
>>>>>unreadable.
>>>>
>>>>The error checks only make the code unreadable because MS prefers a
>>>>*really* bad style. Excessive return and goto is about as bad as it can
>>>>get. A clean if else style and a proper indentation solves that.
>>>
>>>
>>>
>>or:
>>
>>do {
>>
>> error = stuff();
>> if (error) {
>> ...
>> break;
>> }
>>
>> error = morestuff;
>> if (error) {
>> ...
>> break;
>> }
>>} while(0);
>>
>>
>>or the try/finally/leave stuff, although it has overhead.
>>The for and while one pass models break down (pun intended) over the
>>semantics of 'break'.
>>
>>
>>I vote for single/entrance single/exit coding style every time.
>>
>>--
>>
>>=====================
>>Mark Roddy DDK MVP
>>Windows 2003/XP/2000 Consulting
>>Hollis Technology Solutions 603-321-1032
>>www.hollistech.com
>
>
>


--

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com
From: David J. Craig on 1 Jun 2005 01:45
The latest PC-Lint flags goto as depreciated. I remember trying to avoid
them even in Cobol. I have been linting some old large code bases and
finding lots of interesting stuff. Most are just style type issues and of
course there are so many functions that return values, but you can't check
because you have no answer to the question of what to do if it fails. Very
few people like to use (void) to show an intentional omission.

This is just so much fun especially when you add drvfast, code coverage,
bounds checker, and much more. Hard shakedowns are necessary. I remember
my times at Iomega where Bernoulli drives were hooked up to a Mac. They
were strapped on to a plastic tray that lifted up to about 45 degrees and
then fell. The drives weren't done until that could run for several weeks
without a single unrecoverable error.

"Mark Roddy" <markr(a)hollistech.com> wrote in message
news:uCpFjBlZFHA.1040(a)TK2MSFTNGP10.phx.gbl...
> David J. Craig wrote:
>> Have you run PC-Lint on that construct? It is not valid K&R semantics in
>> that the terminating condition is fixed. I don't necessarily agree with
>> the rules, but it is what they gave us. I know many who use it, but I
>> prefer clean lint output and will avoid constructs that upset it. I also
>> use the maximum warning level, too.
>>
>
> I turn off warning C4127. For some reason I dislike for(;;), always have.
> I'm not really that fond of do()while(0) either. TRY/LEAVE/FINALLY
> implemented as macros that avoid SEH and c++ exception handling work, and
> solve the 'inner break' problem, but they don't nest, only one per
> function, and they use the dreaded goto.
>
>
>> "Mark Roddy" <markr(a)hollistech.com> wrote in message
>> news:usiBxbdZFHA.2076(a)TK2MSFTNGP15.phx.gbl...
>>
>>>David J. Craig wrote:
>>>
>>>>Here is a freebie for those trying to do error checking and avoiding
>>>>goto's.
>>>>
>>>>K&R say the only legal 'DO ONCE' is done using the for command.
>>>>
>>>>for( ; ; )
>>>>{
>>>> break; // If OE or ??? warps this, it should be four lines
>>>> with this line indented.
>>>>}
>>>>
>>>>You can then do tests and do a 'continue' or a 'break' as needed to exit
>>>>or restart the loop. You will forget the terminating break especially
>>>>when beginning, but it is legal and works. You can add a __finally to
>>>>handle terminating cleanup, but I just usually initialize all locals and
>>>>return variables before the 'for' block. Then a test and the
>>>>appropriate cleanup can be done to free memory, close handles, etc.
>>>>after exiting the block or before returning.
>>>>
>>>>If you can't code it clean and easy to follow, you need to go back to
>>>>school or find something other than a programming job. No one will live
>>>>forever, much less stay in the same job, so be nice to those who follow
>>>>and write maintainable code. You can add comments to the 'for' loop to
>>>>tell anyone looking that this is a 'do once' block and not to get
>>>>confused.
>>>>
>>>>"Robert Marquardt" <marquardt(a)codemercs.com> wrote in message
>>>>news:%23TSRLUaZFHA.3732(a)TK2MSFTNGP10.phx.gbl...
>>>>
>>>>
>>>>>Wan-Hi wrote:
>>>>>
>>>>>
>>>>>
>>>>>>2) error checking:
>>>>>>SetupDiGetClassDevs and many other functions return a specific value
>>>>>>if they fail. so should i check for failure although such case is
>>>>>>impossible? e.g. SetupDiGetClassDevs with GUID_DEVINTERFACE_VOLUME
>>>>>>should never fail. i ask because useless failure checks make the code
>>>>>>unreadable.
>>>>>
>>>>>The error checks only make the code unreadable because MS prefers a
>>>>>*really* bad style. Excessive return and goto is about as bad as it can
>>>>>get. A clean if else style and a proper indentation solves that.
>>>>
>>>>
>>>>
>>>or:
>>>
>>>do {
>>>
>>> error = stuff();
>>> if (error) {
>>> ...
>>> break;
>>> }
>>>
>>> error = morestuff;
>>> if (error) {
>>> ...
>>> break;
>>> }
>>>} while(0);
>>>
>>>
>>>or the try/finally/leave stuff, although it has overhead.
>>>The for and while one pass models break down (pun intended) over the
>>>semantics of 'break'.
>>>
>>>
>>>I vote for single/entrance single/exit coding style every time.
>>>
>>>--
>>>
>>>=====================
>>>Mark Roddy DDK MVP
>>>Windows 2003/XP/2000 Consulting
>>>Hollis Technology Solutions 603-321-1032
>>>www.hollistech.com
>>
>>
>>
>
>
> --
>
> =====================
> Mark Roddy DDK MVP
> Windows 2003/XP/2000 Consulting
> Hollis Technology Solutions 603-321-1032
> www.hollistech.com


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: OID_802_11_BSSID_LIST_SCAN
Next: get unicode character OEMTextOut