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

[Moreland, Kenneth]

The braces on the same line or on its own is a six-or-half-dozen argument. There are reasons for both, and none of the reasons are compelling.

I suggest leaving the braces on their own line simply to minimize the changes that will impact all of the VTK code. It looks like most if not all of us agree there is a big win shifting all the braces over two spaces to the left. There is a strong benefit to the move and a small impact to the history of the code (even considering blame). I am not seeing convincing reason and support to moving the braces to new lines, which is a very different visual look and has a much larger impact on the history.

-Ken

From: vtk-developers <vtk-developers-bounces at vtk.org<mailto:vtk-developers-bounces at vtk.org>> on behalf of David Gobbi <david.gobbi at gmail.com<mailto:david.gobbi at gmail.com>>
Date: Wednesday, September 9, 2015 at 4:05 PM
To: Brad King <brad.king at kitware.com<mailto:brad.king at kitware.com>>
Cc: VTK Developers <vtk-developers at vtk.org<mailto:vtk-developers at vtk.org>>
Subject: [EXTERNAL] Re: [vtk-developers] PROPOSAL: Changing VTK's indentation style

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<mailto: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<http://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/ddb332f0/attachment-0001.html>