[asterisk-dev] Improvement of coding practices

[SF Markus Elfring]

> Designers? hmmm...
>
> This is a free software. Thus terminology is a bit different. chan_zap
> is a heavily patched code, that was probably not well-designed in the
> first place.
>   
I imagine that all interested parties can meet somewhere in the middle 
to achieve a consensus.
http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design#Computer_science


> One thing I can think of is the configuration parser. But this can
> happen only once my patch to remove most of the configuration-related
> globals should get accepted:
> http://bugs.digium.com/view.php?id=7877
>   
I am curious on the far reaching consequences of your report on the 
topic "reload does not initialize configuration values".


> I can't think of other areas.
>
>   
>>> It has tons of static (globals).
>>>       
>> Can any of them be grouped into more independent modules?
>> http://en.wikipedia.org/wiki/Refactoring
>>     
>
> I bet they can. See, e.g., my patch above.
>
>   
>>> It has a very complex state machine with functions that range over 
>>> hundreds lines.
>>>       
>> Are any presentations or graphs available to review transitions and 
>> dependencies?
>> http://asterisk.org/developers/getting-started
>> http://en.wikipedia.org/wiki/State_diagram
>> http://en.wikipedia.org/wiki/Petri_net
>> http://en.wikipedia.org/wiki/Business_Process_Modeling_Notation
>> http://is.tm.tue.nl/research/patterns/patterns.htm
>>
>> The links point to material that might be relevant in the discussed 
>> context, don't they?
>>     
>
> well, if nobody even reviews a patch such as mine, reviewing even
> greater changes will become a chalange.
>   
I hope that some interesting "key words" will invite more developers to 
help in this challenge.

> Note that some people must have been counting on buggy behaviour in the
> code (even unknowigly), so even fixing bugs breaks some people's
> systems. And with chan_zap you usually need a hardware most people don't
> have to test the situation.
>   
Are there any chances to make the unpleasant dependencies configurable?
http://en.wikipedia.org/wiki/Adapter_pattern
http://en.wikipedia.org/wiki/Virtual_function

> However if you're going to take on into this, I can promise to at least
> review your changes and try them on our systems (we mostly deal with
> analog Zaptel devices, and we have plenty of those)
Are specific software techniques appropriate in this use case?
http://en.wikipedia.org/wiki/Computer_simulation
http://en.wikipedia.org/wiki/Virtual_machine

Does it make sense to move each function from the current implementation 
into its own source file?
Is progress possible by independent and small clean-up steps?
Will such a refactoring increase the chances for distributed work and 
participation on improved design and coding?

Regards,
Markus