Unifying code formatting

[RaulPPelaez]

We could enforce some agreement on formatting throughout the code using an automatic tool, such as clang-format for C++ and black for Python. A .clang-format at the root of a project is recognized automatically by most IDEs (VS code, vim, emacs...) . It can also be integrated as a git pre-commit, although this can be a nuisance for a contributor so we could just make it a guideline. Finally, the clang-format binary can simply be called from the cli. From working through the OpenMM and OpenMM-torch codebases I have crafted a .clang-format file that leaves most of the current code untouched:

IndentAccessModifiers: 'false'
AccessModifierOffset: -4
IndentWidth: 4
PointerAlignment: Left
AllowShortFunctionsOnASingleLine: 'None'
ColumnLimit: 200
BreakBeforeBraces: Custom   
BraceWrapping:
    BeforeCatch: true
SortIncludes: false
SortUsingDeclarations: false
IndentPPDirectives: 'BeforeHash'
Standard: 'Cpp11'

To give you some examples, these lines:

template <typename scalar_t> __device__ __forceinline__ scalar_t sqrt_(scalar_t x) {};
template<> __device__ __forceinline__ float sqrt_(float x) { return ::sqrtf(x); };
template<> __device__ __forceinline__ double sqrt_(double x) { return ::sqrt(x); };

Turn to this:

template <typename scalar_t> __device__ __forceinline__ scalar_t sqrt_(scalar_t x){};
template <> __device__ __forceinline__ float sqrt_(float x) {
    return ::sqrtf(x);
};
template <> __device__ __forceinline__ double sqrt_(double x) {
    return ::sqrt(x);
};

While these lines:

    if (box_vectors.size(0) != 0) {
        TORCH_CHECK(box_vectors.dim() == 2, "Expected \"box_vectors\" to have two dimensions");
        TORCH_CHECK(box_vectors.size(0) == 3 && box_vectors.size(1) == 3, "Expected \"box_vectors\" to have shape (3, 3)");
        double v[3][3];
        for (int i = 0; i < 3; i++)
            for (int j = 0; j < 3; j++)
                v[i][j] = box_vectors[i][j].item<double>();

are left untouched. What do you think?

[raimis]

I think that we choose one of the existing formatting styles and adapt it (even if it needs reformating the existing code). For Python, it could be black. For C++, it could be LLVM.

[RaulPPelaez]

I am all in for adapting an established format. AFAIK when the option BasedOnStyle is not present, like in the above, the LLVM style is selected. So my config is LLVM except for what is present in those options.

Would a big commit reformatting all the code cause conflicts in existing pull requests or interfere with stuff like git blame?

[mikemhenry]

One big commit is best, see https://docs.github.com/en/repositories/working-with-files/using-files/viewing-a-file#ignore-commits-in-the-blame-view for how to make the web ui ignore the commit with blame (and how you can do the same locally)