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

[Steve Pieper]

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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20150909/3e05c905/attachment-0001.html>