[Kamailio-Devel] Use of goto

[Daniel-Constantin Mierla]

Hello,

On 01/28/2009 12:05 PM, Henning Westerholt wrote:
> On Tuesday 27 January 2009, Johansson Olle E wrote:
>   
>> I've been spending some time going through the mi_* modules for
>> doxygen and other format changes, as well as checking spelling of log
>> messages and docs.
>>
>> I see a lot of code with goto's that isn't needed and can be changed.
>> Most common is "goto error" where error just is one line that returns
>> an error code. This can simply be changed so that the "goto error" is
>> replaced with "return <errorcode>;"
>>
>> I don't know your code guidelines, but this code would not be approved
>> in Asterisk. We're trying to simplify code paths as much as possible
>> to make things easier to understand and follow. Overuse of goto
>> doesn't make code easy to read, in my opinion...
>>     
>
> Hi Olle,
>
> in my opinion the use of 'goto' should as much avoided as possible, exactly 
> because the same reason, making the code easier to understand. If the goto is 
> only used to return one error code, it could be changed. It make more sense 
> when the error handling is more complex, e.g. freeing more then two instances 
> of allocated memory, unlocking of resources or similar. Then it makes the 
> code more compact, as the cleanups only happens in one place.
>
> The other arguments for gotos like breaking out from several innner loops, or 
> performance in _really_ hot code paths are valid, but probably applies really 
> rarely.
>   
probably making complex goto-based programming is a nightmare. But 
sometimes, as some of you expressed, it makes the code cleaner. I tend 
to use goto for two cases:
- error handling - where some cleanup is required, also helps if the 
return code needs to be updated
- processing done - for the reason of cleanups (lock releasing) and 
having one return statement in order to spot quickly the return code in 
case of ok.

Anyhow, probably is (will be) the developer choice, as long as it has no 
big impact, code beautifications are always subject of taste.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://www.asipto.com