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

[Berk Geveci]

I am still against your proposal John. For reference, it was this:

> I would like to reserve the right to use my own coding style on the
contributed class(es)

It was not changing VTK's style to something different. Looking at that
thread, it also looked like everyone that contributed to it except you were
against it. Also looking at this thread, it sounds like many people are
still against mixing multiple styles in the same codebase.

Best,
-berk


On Thu, Sep 10, 2015 at 2:49 AM, Biddiscombe, John A. <biddisco at cscs.ch>
wrote:

> +lots
>
>
>
> Like the Scottish who say “Anyone but England”, I would like to
> emphatically vote in favour of changing VTK’s code style to “Anything, but
> what we have now”, it certainly can’t get worse.
>
>
>
> Yours
>
>
>
> JB
>
> PS. It feels like 2006! I made my views felt then (and many times
> previously), and Berk has criticised my views on it for the last 10 years,
> so I shan’t say any more!
>
>
> http://vtk.1045678.n5.nabble.com/vtk-Coding-style-Proposed-change-td1251702.html
>
>
>
>
>
> *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On Behalf
> Of *Berk Geveci
> *Sent:* 09 September 2015 15:09
> *To:* VTK Developers
> *Subject:* [vtk-developers] PROPOSAL: Changing VTK's indentation style
>
>
>
> Hi folks,
>
>
>
> What would you think of changing VTK's indentation style from:
>
>
>
> if ()
>
>   {
>
>   // ..
>
>   }
>
>
>
> to
>
>
>
> if ()
>
> {
>
>   // ...
>
> }
>
>
>
> ?
>
>
>
> Our current style (modified Whitesmiths I am told) is used only by very
> few projects,
>
> mostly related to VTK ones (ITK, CMake). It is poorly supported by some of
> the newer editors
>
> that are widely popular (Sublime, TextMate etc.) and IMO foreign to the
> new generation
>
> C++ developers.
>
>
>
> The style I propose is modified Allman style - with indentation changed
> from 4 to 2 spaces.
>
> It is much more common.
>
>
>
> If approved by the community, we would change VTK wholesale. This should
> not be
>
> an issue for history as git blame/annotate can be told to skip white
> spaces.
>
>
>
> Best,
>
> -berk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20150910/1f9a68a3/attachment.html>