[chbot] return value or status from function

[Charles Manning]

I think there are three things worth considering

1) Which gives you correct answers.

2) Which is easier to use/maintain

3) Which is most efficient.

 The readSomePin();, now read value from somePinStatus variable idea is
terrible because it splits the operations. If different threads (including
interrupts) call readSomePin() and later (even in the next instruction) you
read the extern variable, you have lost the context. This thus fails the
"correctness" test because you don't know when the read occurred.

Secondly you have to coordinate the use of the read and the variable check.
That makes it hard to do things like doing if/while code and requires more
code (and thus more chances to mess up).

Lastly, it forces the use of memory accesses (can't be registerised) and is
therefore potentially slower and uses more memory

The read(*valpointer) mechanism is at least better in that the operation is
"atomic" and you know when you read the value.

However, it still means you have to check the value after reading it.

It also forces the use of memory (since you're using a pointer) and is thus
potentially slower.

By bet would be using the return value where you can.  value= readPin();

This has all the good stuff we're looking for:
It is "correct"
It is easy to read/maintain.
It is efficient since it can be fully reegisterised.

Also if you write code like

/* Check for three button salute */
If (button1_pressed() && button2_pressed() && button3_pressed()) ....

then only the tests that are required will be performed. If button1 is not
pressed, then the if(...) will not check button2 or button3.


However.... there is never a one-size-fits-all answer and discretion is
advised.

I severely detest code that returns structures. Use pointer passing for
structures.

If a function returns a value and maybe also other "out of band" info such
as status etc, then consider using a structure for the status stuff and
making it optional.

eg.

int button1_pressed(int *time_since_previous_press)
{
     if (time_since_previous_press)
       *time_since_previous_press = now - last_press_time_stamp;
     return current_button)state;
}


Now you can get that extra data or just call with button1_pressed(NULL) if
you don't care.

Also, bear in mind the types you are using. On ARM it is generally better
to use 32 bit values than 8 bits or 16 bits, but again that's not a hard
and fast rule.







On Sat, Feb 6, 2016 at 12:37 AM, Robin Gilks <robin at gilks.org> wrote:

>
> > Good day all,
> >  What is the opinion of this esteemed group on the best/proper/whatever
> > way
> > to get the measured value from some external input from a micro in C.
> > By measured value I mean something like ADC, OW temp sensor, I2C sensor
> > state etc.
> >  I am considering the following three scenarios in increasing order of
> > goodness:
> > 1) function returns the measured value indicating error by out of range
> > result (i.e 0xFF for  8 bit int)
> > i.e:
> > ...
> > unit8_t readSomePin(void); // 0xFF indicates error
> >
> > 2) function returns the measured value indicating status of measurement
> in
> > another extern. variable
> > ...
> > extern uint8_t readSomePinStatus;
> > unit8_t readSomePin(void);  // Status in readSomePinStatus
> >
> > 3) function returns status, the value is stored in an argument variable:
> > ...
> > unint8_t readSomePin(uint8_t *returnedValue);
> >
> > So, what is best? Is there a better way? This could no doubt also be done
> > with Structs, but seems like overkill to me.
>
> I'd go for option 3 as the function prototype provides all the information
> about the size and sign of the parameter as well as the function itself
> giving the result of success or failure which will make the code more
> maintainable.
>
> --
> Robin Gilks
>
>
>
> _______________________________________________
> Chchrobotics mailing list Chchrobotics at lists.linuxnut.co.nz
> http://lists.ourshack.com/mailman/listinfo/chchrobotics
> Mail Archives: http://lists.ourshack.com/pipermail/chchrobotics/
> Meetings usually 3rd Monday each month. See http://kiwibots.org for
> venue, directions and dates.
> When replying, please edit your Subject line to reflect new subjects.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ourshack.com/pipermail/chchrobotics/attachments/20160206/557df1c8/attachment.html>