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

Thu Sep 10 09:51:42 EDT 2015

ITK and VTK are not tightly coupled so I don't see why we need to sync on
the decision to change the coding style. It is hard enough to make these
decisions in one community. I can't imagine trying to coordinate with other
communities. If someone reading this would like to float the idea by the
ITK community, please feel free to refer to this thread and the support
this has gotten so far.

ParaView and other projects like it that tightly couple with VTK would
follow without any problems. They don't usually have their own independent
coding styles anyway.

On Wed, Sep 9, 2015 at 7:13 PM, Steve Pieper <pieper at isomics.com> wrote:

> Has anyone raised the idea of changing the ITK or ParView styles?  I
> suspect as separate projects they would have their own discussions.
>
> -Steve
>
> On Wed, Sep 9, 2015 at 6:41 PM, Andras Lasso <lasso at queensu.ca> wrote:
>
>> I would not worry too much about Slicer extensions. For example in our
>> extensions we already use the usual indentation instead of VTK’s.
>>
>>
>>
>> Note that ITK, Paraview, etc. would need to be updated to the same style,
>> too.
>>
>>
>>
>> Andras
>>
>>
>>
>> *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On
>> Behalf Of *Steve Pieper
>> *Sent:* September 9, 2015 6:27 PM
>> *To:* David Gobbi <david.gobbi at gmail.com>
>> *Cc:* VTK Developers <vtk-developers at vtk.org>; Brad King <
>> brad.king at kitware.com>
>> *Subject:* Re: [vtk-developers] PROPOSAL: Changing VTK's indentation
>> style
>>
>>
>>
>> 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
>>
>>
>>
>
>
> _______________________________________________
> 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/20150910/2dc09a11/attachment.html>