[vtk-developers] PROPOSAL: Changing VTK's indentation style

[Steve Pieper]

I'd personally vote for:

int func( int arg )
{
  // this code looks gorgeous!
  if ( condition ) {
    statement;
  } else {
    statement;
  }
}

But I'm also used to VTK's "unorthodox" style and don't really mind it.  To
be honest it makes it very clear when I'm looking at VTK code and when code
has been written by novices vs old hands (and yes, sometimes I form
opinions about likely code quality from that).

I'd also like to point out that in Slicer our explicit style [1] is to copy
VTK style for any code that inherits from VTK objects.  So if VTK changes
Slicer will have to also, and by implication all Slicer extensions should
also change.  This will create extra maintenance work and probably some
confusion for our community (and I suspect other projects will have similar
issues).

Is the motivation for this change really worth introducing some busywork
and confusion for people who use VTK?  If yes, then +1.

-Steve

[1]
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/Style_Guide



On Wed, Sep 9, 2015 at 6:05 PM, David Gobbi <david.gobbi at gmail.com> wrote:

> Hi Brad,
>
> Even though I slightly prefer the inline "if () {" style, I can offer some
> arguments against it.
>
> 1) it doesn't work well for multi-line conditionals:
>
>     for (std::vector<typeWithLongName>::iterator iter = vec.begin();
>           iter != vec.end();
>           ++iter) {
>       statements;
>     }
>
> versus
>
>     for (std::vector<typeWithLongName>::iterator iter = vec.begin();
>           iter != vec.end();
>           ++iter)
>     {
>       statements;
>     }
>
> 2) it's inherently inconsistent.  This is demonstrated by the following
> Java-styled code that actually applies the style consistently:
>
>     int myfunc(int x) {
>       if (x == 0) {
>         statements;
>       }
>     }
>
> Most C++ programmers (like myself) think the above is ridiculous, but
> really, why should a definition block be treated differently from a
> conditional block?
>
> In my opinion, putting the brace on the following line is nice because it
> is a simple, consistent rule that produces easily readable code.
>
> I'm a fan of compact code, but only when it is compactified according to
> my own tastes.  Otherwise the compactification loses its value ;-)
>
>  - David
>
>
> On Wed, Sep 9, 2015 at 3:29 PM, Brad King <brad.king at kitware.com> wrote:
>
>> On 9/9/2015 3:41 PM, Brad King wrote:
>> >   if (...) {
>> >     ...
>> >   } else {
>> >     ...
>> >   }
>> [snip]
>> >   if (...)
>> >   {
>> >     ...
>> >   }
>> >   else
>> >   {
>> >     ...
>> >   }
>>
>> There seems to be agreement that either of these is an improvement
>> but that we should choose now which one to use.  I'm sure one can
>> find endless debates across the web about which one is best.  Here
>> are the main reasons I prefer the former over the latter:
>>
>> 1. Uses less vertical space.  This is important when the content
>>    within the blocks is short.
>>
>> 2. The start and end of each logical block is aligned horizontally
>>    and can be matched vertically with nothing in the way:
>>
>>      if (...) {
>>      ^  ...
>>      |  ...
>>      |  ...
>>      |  ...
>>      |  ...
>>      v  ...
>>      } else {
>>      ^  ...
>>      |  ...
>>      |  ...
>>      |  ...
>>      |  ...
>>      v  ...
>>      }
>>
>>    This is important when the content within the blocks is long.
>>
>> 3. Distinguishes conditional and unconditional blocks:
>>
>>      if (...) {
>>         // conditional block
>>      }
>>
>>      {
>>        // unconditional block
>>      }
>>
>>    Contrast this to the latter style where both look the same:
>>
>>      if (...)
>>      {
>>        // conditional block
>>      }
>>
>>      {
>>        // unconditional block
>>      }
>>
>>    In the latter style one must read a line above the "{" to see
>>    whether it is a condition.  This could be tricky if there is
>>    an unrelated f(...) call there.
>>
>> The former style is widely used in many projects and well-supported
>> by editors.
>>
>> -Brad
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20150909/4ee5bc8d/attachment.html>