Question 1.
=========
I was doing some ws format work while watching TV last night, mainly
this kind of thing:
That's a level of awesome. :)
changing "for (i=0 ; i<N ; i++)"
to "for (i = 0; i < N; i++)"
according to the info in HACKING. Following the
white-space-around-operators rule one should change something like
this:
variable_Y[i*3+2]
to
variable_Y[i * 3 + 2]
but in some cases I was reluctant to do that because of the length of
the resulting _expression_ (especially on already long lines).
Any preferences? Or should one do it anyway?
The intent in HACKING was to make sure variable set statements (e.g., int a = b + c;) are neatly consistent and that for()/while() statements don't have gratuitous "padding" spacing. There have been multiple instances of "abuse" in the pase where statements are written rather unnecessarily stupid (int a=4+(bcd+((cda%dbd+3)-eef)/4-2)+3... what?). The more important stylistic case that tends to be a problem is where the parens and brackets are:
if (a || b || c) { // ok
if ( a || b || c) { // discouraged
if (a||b||c) { // discouraged
if( a || b || c ){ // discouraged
if (a || b || c){ // discouraged
if (a || b || c)
{ // discouraged
if (a<123412341234.1234
|| b>123412341234.1234
|| c<123412341234.1234)
{ // ok
There are nearly always exceptions too, so just use good judgement and nominally make files self-consistent.
Question 2.
=========
Long boolean statements (as well as long statements with other
operators) often should be wrapped but I see no guidelines about
wrapping and I see different styles. The standards I've seen in GNU
circles recommend wrapping so the operator begins the next line, but
having it end the line often makes alignment nicer.
I also see the need for some guidelines on statement lengths--there
are some VERY long ones lurking around.
Preferences?
Given three devs with three different monitor sizes, I don't think you'd come to an agreement about wrapping. It'll depend heavily on your coding environment. If you have a nice wide monitor or an editor that visually wraps for you, long lines are generally preferred because you can get more vertical logic into context. If you're not, though, and especially for some code editors that hide long lines offscreen (boo hiss), it can be difficult to read code. Either way, it's an efficiency loss for the other guy.
My general preference and advice: shorten the line. Many long code lines are set statements within expressions that can be reduced.
Sucky:
if ((fd=accept(fd, (struct sockaddr *)&frominet, &fromlen)) < 0) { ... }
Better:
fd=accept(fd, (struct sockaddr *)&frominet, &fromlen);
if (fd < 0) { ... }
Where it really is a complex boolean that doesn't break up well, I've been using the GNU method you mention and it works well but requires the brace on the following line:
Long:
if (screen_xlen <= 0 || rle_dflt_hdr.ymin > screen_height || rle_dflt_hdr.ymax < 0 || (screen.ylen > 0 && rle_dflt_hdr.ymax > 0)) {
Wrapped:
if (screen_xlen <= 0
|| rle_dflt_hdr.ymin > screen_height
|| rle_dflt_hdr.ymax < 0
|| (screen.ylen > 0 && rle_dflt_hdr.ymax > 0))
{
For functions declarations and definitions, long lines are preferred because they don't contain logic. That said, if a line is going to be wrapped then one argument per line is generally easiest to read with arguments starting on the second line. That said, we have plenty of code that fails consistency simply because of the preference contentiousness.
Thanks and best regards,
Great questions. I applied a patch to astyle which was just merged last month that should make it possible to create an astyle definition that closely matches our style. A complete astyle definition will help automate formatting consistency but I have some more testing to make sure we get something reasonable.
Cheers!
Sean
------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev
_______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
