On Tue, Nov 17, 2015 at 3:35 PM, Brad King <brad.k...@kitware.com> wrote: > Hi Folks, > > For reference, the current CMake indentation style is: > > https://en.wikipedia.org/wiki/Indent_style#Whitesmiths_style > > but with 2 space indentation instead of 4 as shown on that page. > The style was popular when CMake started (year 2000) but is not > very widely used anymore. > > For Emacs, see attached file (that comes from VTK folks that also > use the style. For Vim one can use something like: > > set tabstop=2 shiftwidth=2 expandtab > set cindent cinoptions={1s,l1,g0,c0,t0,(0,W1s > > Since the style is not very popular anymore I don't know whether > other editors can be configured for it. For this reason I've > been thinking about proposing use of clang-format for a while. > We could also consider switching to a more widely-used indentation > style outright and using clang-format to define it formally. > > On 11/17/2015 04:29 PM, Daniel Pfeifer wrote: >> On Tue, Nov 17, 2015 at 10:12 PM, Robert Dailey wrote: >>> How did you guys want to approach reformatting inconsistently >>> formatted source files? >> >> I would say: As a byproduct. >> >> Adding a .clang-format file to CMake would be greatly appreciated. It >> can be used to ensure that refactorings and new contributions follow >> exactly the predefined style. However, changing existing code simply >> because it does not match the style is something that should be >> refused. > > I think we could do a one-shot conversion of existing sources. This > was done in our CMakeLists.txt and *.cmake files a while ago to update > capitalization style. We recorded the commit as done by a robot user > instead of a specific developer's name. It is not that hard to > re-invoke `git blame` to see past any blame poisoning such a commit > might introduce. For that cost, we gain consistency in the code > and simplicity for patches.
So I'd like to propose first of all that we explore a new coding standard. Let's make the changes we want to make. In the meantime, I will reflect that discussion into a clang format file. I'll provide it as an attachment here, along with some samples of conversions of existing files in the code base so we can get an idea of how it looks. I agree with Brad about a mass one time conversion. BTW you can instruct git blame to ignore whitespace changes; this would effectively ignore the "whitespace robot" commit entirely (so you don't even have to use a robot user if you didn't want to, but it's still a great idea and doesn't hurt). To get some discussion going, take a look at the BasedOnStyle option in clang format: http://clang.llvm.org/docs/ClangFormatStyleOptions.html There are a couple of predefined formats you could use here. Obviously choosing one of those as a base and then fine-tuning it to your needs would probably be the best approach. Mozilla's standard looks reasonable. Honestly all of this is a matter of taste, I don't expect everyone to agree on every little detail. I think the goal should be to strive for something a little more modern (determined by general consensus in the open source community) and most importantly enforce it. No matter what style you choose, consistency is what matters the most. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
