[asterisk-dev] Line length restrictions in code changes

George Joseph gjoseph at digium.com
Fri Mar 17 07:30:48 CDT 2017


On Thu, Mar 16, 2017 at 2:35 PM, Kevin Harwell <kharwell at digium.com> wrote:

> On Thu, Mar 16, 2017 at 2:54 PM, Matthew Jordan <mjordan at digium.com>
> wrote:
>
>> <snip>
>>
>> Personally, I find this:
>>
>> if (a_good_variable_name->another_good_name &&
>> do_something_to_it(a_good_variable_name->another_good_name)) {
>>     // Do things
>> }
>>
>
> I prefer this to the alternative as well.
>

So don't indent wrapped predicates or is that just email formatting?


>
>
>> if (a_good_variable_name->another_good_name
>>     && do_something_to_it(a_good_variable_name->another_good_name)) {
>>     // Do things
>> }
>>
>
I actually prefer this one with the operators at the front but I'm fine
either way.


>
>> <snip>
>>
>> Questions than:
>> (1) Should there even be a line length rule?
>>
>
> I lean toward yes just to keep things sane (e.g. keeping someone extending
> a function definition to infinity and beyond). Also sometimes I split my
> editor's screen vertically and have multiple code views up. The vertical
> split reduces my column length and I either have to start scrolling or (in
> my current setup) the line gets wrapped. Both hurt readability for me.
>

This is where choice of editor or IDE comes into play.  I use Eclipse so my
left pane is a navigator, the center pane is the editor and the right pane
is search/outline/bookmarks.  Even with that, I have my column marker set
at 100 which works well (for me).  Still though, there's code, mostly
function prototypes or definitions, that make me nuts because they run well
beyond 100 characters.  Even more annoying are header files like
res_pjsip_session.h where both declarations and comments go out to 200
columns.


>
> (2) If there is a line length, what is a reasonable length given some
> of our function names? (Looking at things like
> ast_sip_get_mwi_disable_initial_unsolicited)
>
> I personally think the current length of 90 is reasonable. I'll add though
> that going a bit above this (say up to 100) in some cases should not
> prevent code submission. For instance if a variable name is going to extend
> an 'if' statement 4 more characters there is no reason to break that up.
>

My vote is 100.


>
> (3) Should we simply advocate for readability, with examples of what
> is readable and what is not?
>
> Readability should be first and foremost, and some examples would probably
> help with that.
>

+1000.  I can adapt and so can my editor but having real guidelines is key.



>
> --
>
> Kevin Harwell
> Digium, Inc. | Software Developer
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: http://digium.com & http://asterisk.org
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>



-- 
George Joseph
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20170317/d26ff6a2/attachment.html>


More information about the asterisk-dev mailing list