Software Reuse In Embedded code

On 28/06/2011 05:17, Don Y wrote:
> Of course, unlike your 88%RH, we're sitting at something like *seven* %.

Ah.

Where are you?

Steve
(Will respond to rest of hugely interesting/challenging post when/if I 
get time.)

-- 
http://www.fivetrees.com

On 28/06/2011 05:41, Arlet Ottens wrote:
>
>  > I suspect you're fairly new to this game (which I'm not)
>
> Yeah, I guess 25 years is fairly new.

Ah. Consider humble pie consumed ;).

I should know better. I'm working with a chap (hi, Mike!) whose work I 
respect hugely. His code and my code will likely never approve of one 
another ;).

Steve

-- 
http://www.fivetrees.com

On 6/28/2011 4:02 PM, Steve at fivetrees wrote:
> On 28/06/2011 05:17, Don Y wrote:
>> Of course, unlike your 88%RH, we're sitting at something like *seven* %.
>
> Ah.
>
> Where are you?

Arizona, USA.

> Steve
> (Will respond to rest of hugely interesting/challenging post when/if I
> get time.)

never mind that -- get back to WORK!!!  (slacker...)  :>

On 6/28/2011 4:05 PM, Steve at fivetrees wrote:

> I should know better. I'm working with a chap (hi, Mike!) whose work I
> respect hugely. His code and my code will likely never approve of one
> another ;).

[fanfare]

*Core Wars*!!!

On Jun 28, 12:41=A0am, Arlet Ottens <usene...@c-scape.nl> wrote:
> On 06/28/2011 02:33 AM, Steve at fivetrees wrote:
>
>
>
>
>
> >> I use goto whenever it results in clearer and more readable code. Usin=
g
> >> "goto error" in a function that ends like this:
>
> >> error:
> >> cleanup_stuff();
> >> return retval;
> >> }
>
> >> is easy to understand. The 'error' label makes it clear what the purpo=
se
> >> is, even without reading any further, and it helps to keep the mainlin=
e
> >> code free of error handling. It may be possible to rewrite the code to
> >> avoid the 'goto', but if that doesn't result in any tangible benefits,
> >> why bother ?
>
> > There are any number of ways of avoiding this. One is to have an error
> > flag; set it if you need to do cleanup (not great). Another is to retur=
n
> > FALSE early if errors are encountered (see below; preferred).
>
> Except that 'return FALSE' doesn't work in the case above where you also
> need to call 'cleanup_stuff()' unless you duplicate the cleanup code,
> which is even uglier than error flags.
>
> >> I never worry about simplifying the logic, unless it helps readability=
.
>
> > Friend, I lost you right there. *Simplifying the logic can only help
> > readability*.
>
> Sometimes simplying the logic can help to increase readability,
> sometimes it doesn't. For the same reason, I sometimes write
>
> if( p )
>
> and at other times I write:
>
> if( p !=3D 0 )
>
> Sometimes I write: if( a && b ), and sometimes I write:
>
> if( a )
> =A0 =A0 if( b )
>
> It all depends on the circumstances, and "how it reads". It's not
> necessary the case that the simplest logic is the easiest to read,
> although usually it helps, and in that case I obviously simplify the logi=
c.

ha, I deal with those "simplifiers" everyday, simplifying sometimes
removes much insight and physical meaning to the algorithm your trying
to implement. A algorithm that natually has 8 logical steps to it
should be left with those 8 steps, even if it can be reduced to 4
cryptic steps and still give you the same answer. Because when that
algorithm needs to be modified or debugged those 4 steps are going to
have to unrolled into those 8 steps. I believe it's a carryover from
the olden days when saving every byte of source code counted. C
language itself is a perfect example of that mentality, trading too
much simplification for readability.

On 01/07/2011 21:28, steve wrote:
> ha, I deal with those "simplifiers" everyday, simplifying sometimes
> removes much insight and physical meaning to the algorithm your trying
> to implement. A algorithm that natually has 8 logical steps to it
> should be left with those 8 steps, even if it can be reduced to 4
> cryptic steps and still give you the same answer. Because when that
> algorithm needs to be modified or debugged those 4 steps are going to
> have to unrolled into those 8 steps. I believe it's a carryover from
> the olden days when saving every byte of source code counted. C
> language itself is a perfect example of that mentality, trading too
> much simplification for readability.

I can only agree.

I'm not arguing for logic reduction for its own sake; if it hinders 
readability, fergin fergit it.

However, I see code (regularly) that is *way* more complex than it needs 
to be, simply because of a lack of factoring - there's loads of 
duplicate code (and testing) because the coder is looking for conditions 
within conditions within conditions, and then those same conditions 
within conditions within *other* conditions, all of which could have 
been reduced to a few *clearer* set of tests by way of e.g. a bit of 
thought and a Karnaugh map...

Steve

-- 
http://www.fivetrees.com

Hi Steve,

On 7/1/2011 1:28 PM, steve wrote:

> ha, I deal with those "simplifiers" everyday, simplifying sometimes
> removes much insight and physical meaning to the algorithm your trying

It depends on *how* (and what) you are simplifying.  For example:

    if ( (man)
      || (woman && pregnant) )

*clearly* is as easy to understand as

    if ( man || pregnant )

If you look at a lot of conditionals, particularly, you can
see where the person writing it just didn't *think* about what
he was doing.  It's as if he laid out each individual possibility
"in a vacuum" without concern for the stanza of code immediately
preceding, etc.

Granted, some compilers can remove this redundancy.  But, it's
presence increases the chance of typographic errors creeping in
(e.g., "if (sex = MAN)" instead of "if (sex == MAN)" or
"if (sex != WOMAN)", instead) as well as adding a lot to clutter.
I *really* wish we had multicolored parens (no, not *colorized*
but actually inherently different "characters" -- like brace, bracket,
etc.) to make it easier to write and parse complex conditionals.
[which is why I resort to the style of the first example]

> to implement. A algorithm that natually has 8 logical steps to it
> should be left with those 8 steps, even if it can be reduced to 4
> cryptic steps and still give you the same answer. Because when that

Agreed.  Unless those steps are obvious in the resulting
code.  E.g., foo += 4 vs four instances of foo++;

> algorithm needs to be modified or debugged those 4 steps are going to
> have to unrolled into those 8 steps. I believe it's a carryover from
> the olden days when saving every byte of source code counted. C
> language itself is a perfect example of that mentality, trading too
> much simplification for readability.

I always found:
   "Make everything as simple as it can be -- but no simpler"
an amusing axiom.  (on a par with "You always find the thing
you seek in the *last* place you look")