On 4/6/2014 6:14 PM, Ruben J=F6nsson wrote:
>> - with the while and tests in one function, with 'return failure'
>> >instead of the goto's; call this function from another function, which
>> >does the 'postprocessing.
>> >
>> >or
>> >
>> >- with 'status =3D failure; break;' at the goto's, and a single if at t=
he
>> >end which tests the status.
>> >
>> >Wouter
> I am not sure that I agree that this would be better written in this case=
.. The
> first option makes the code harder to read since I have to go and look up=
 the
> function to know what it is doing. I also have to pass along some variabl=
es
> and/or pointers and of course calling the function which introduces overh=
ead on
> the compiled code (not by much but still...).

[obligatory IMHO disclaimer]

Using GOTO in this case might be the only reason I do use it.
Passing the program flow to an intermediary variable makes it harder to=20
read.

If you're writing a function that performs some complicated multi-level=20
logic and you need to break out for errors (with common 'error' code)=20
then a GOTO makes it clearer.

A label at the end of your reasonably short helper function is obvious=20
and is distinct from if...else logic which is usually doing something=20
algorithmic rather than for the program flow.

Though one could probably argue that you should be use a state machine=20
with a switch-case if you have extensive multilevel if-else logic.

I haven't spent a lot of time thinking about this, but I wonder if=20
Python for embedded targets would be essentially like C without the=20
semicolons. A lot of the nice features of Python are too overhead hungry=20
for an embedded microcontroller target.

-
Martin K
--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.