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

[Utkarsh Ayachit]

Steve,

As far as ParaView is concerned, whatever VTK decides, ParaView will
follow. For the most part, a ParaView developer is a VTK developer too,
hence it's safe to assume that he/she is following this discussion and can
voice his/her concerns, if any.

Utkarsh

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/d8bae631/attachment-0001.html>