I usually don't like to stick my hand into fires such as these (went through this on various projects in the past and learned my lesson). But here I go again... (oh dear oh dear):
On Fri, Mar 17, 2017 at 7:30 AM, George Joseph <gjos...@digium.com> wrote: > > > On Thu, Mar 16, 2017 at 2:35 PM, Kevin Harwell <kharw...@digium.com> wrote: >> >> On Thu, Mar 16, 2017 at 2:54 PM, Matthew Jordan <mjor...@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. This is my preference as well. I like to see the operators at the front in case of long line lengths that get cut off (similar to Richard's reasoning). > >>> >>> >>> <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. I usually don't enforce line length at the editor level as well. Variable flexible terminal sizes take most of the pain away of alternative line lengths. >> (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. I'm good with either, stipulated with soft enforcement saved for when line length width is abused in egregious and non-readable ways. >> (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. I'm all for readability and good guidelines in favor of hard rules. :-) > > > +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 > > > -- > _____________________________________________________________________ > -- 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 -- Matthew Fredrickson Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA -- _____________________________________________________________________ -- 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