RussellMc wrote:
> The line IS far more readable "at a glance" for the purposes of
> conveying the primary function. But, what it does in the process is
> hide information which may be valuable either generally, or in some
> cases as part of troubleshooting or understanding some behaviour. The
> fine detail still has to be provided and dealt with somewhere (which
> bits, which mask etc) and, as the detail is hidden here, it needs to
> be explicitly revealed somewhere else. In the case of a macro the
> "revealing" will be done in the listing following the macro, if this
> level of detail is enabled, and in the case of a function call or
> subroutine the "detail", if required to be known, may need to be
> extracted with extra user effort. The extraction is liable to be far
> more difficult than 'just reading it from the code line' as is
> possible in the first version.

Good point, I hadn't thought of it quite that way before.  This way of
thinking argues clearly for the second of the two examples instead of the
third.  If you look at it this way, the second is really a superset of the
third.  It shows the details in the code so someone who needs the details
doesn't have to go chasing after a macro definition, but it also gives you
the same higher level information in the comments that the third line does
in the code:

>>> c = pak.iphdr.saddr & 192; //mask upper bits to get network class
>>> netclass = pak.iphdr.saddr & 0xC0; //get network class
>>> netclass = GET_NETWORK_CLASS(pak);

The winner might not be so clear if GET_NETWORK_CLASS expanded to a more
complicated function or the third line had a comment indicating the next
higher up information, like why we need the network class.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist