Hi Scott, On 6 July 2017 at 22:20, Scott Kostyshak <skost...@lyx.org> wrote:
> > - Now (before release) would be a good time to start using clang-format > > Why? One reason is that it might make it easier to backport fixes from > master to 2.3.x. This was my reason, as comparison of code becomes easier through 2.3.x. Other than that we can certainly do it at a later stage. > A reason against such a change is that the benefit is > more long-run than short-run, as there is always the risk that unwanted > functionality could change. We should certainly consider the risk of changed functionality, but we are actually quite safe: - With one exception (see below) clang-format is designed to only change "whitespace" of the source code, i.e. adding/removing whitespace. - We can compare the built executable before and after running clang-format, the executables should be identical. - The one exception is if clang-format is allowed to sort the order of "includes". But we disallow this (SortIncludes: false), so it won't happen. Note: Good source code should not depend on the order of the includes, but ... - Strictly speaking the behaviour of the program can change through a macro like __LINE__, if we have some crazy code that depends on a piece of code being located at some specific line number. Otherwise we're talking about that line numbers in a possible log output might be different. Just as if someone had manually added or removed a few source code lines. - If other programs read the LyX source code and depend on certain things being located on certain lines, or at certain indentation levels, this could affect the overall functionality. So Doxygen would need to be checked that it still works - if we actually use it for anything? > Even if no functionality is changed in > theory, we could somehow expose a compiler bug (this is true even if > just changing whitespace). > I'd expect this to in practice be covered by binary comparison of the executable. In theory we could of course still be hit by a compiler bug on a platform where we don't compare the executable. Also, anyone doing the same whitespace change manually would trigger such a bug... in theory the removal of trailing whitespace from lines could trigger it. What do others think? I'm attaching a file that should be saved as ".clang_format" in e.g. src/ or a in a higher directory. This will then automatically be used by clang-format. To apply clang-format to all files in src/, run: cd src clang-format -i *.cpp *.h Note: The same would have to be done for source code in the subfolders as well. Note: From within Emacs you can do 'M-x clang-format-buffer'. Note: I've tested with clang-format version 4.0. I don't know what the minimum required version number is for the configuration settings I'm using. Note: I created the attached .clang-format to try and minimise the number of changed source code lines. This configuration should be seen as a first step, to let people see what we're talking about. In particular, it's currently typically not fixing lines that are to long. /Christian PS. As I see it, after we're using clang-format, a next step could be to use 'clang-tidy' to do some static analysis.
clang-format-custom
Description: Binary data
