Re: [omr-dev] our coding standard

["Mark Stoodley" <mstoodle@xxxxxxxxxx>]

Matthew was good enough to point out the following relevant
articles
that I thought everyone would find interesting:

> MongoDB Engineering have written up a series
of
> [three](https://engineering.mongodb.com/post/succeeding-with-clangformat-part-1-pitfalls-and-planning/)
> [blog](https://engineering.mongodb.com/post/succeeding-with-clangformat-part-2-the-big-reformat/)
> [posts](https://engineering.mongodb.com/post/succeeding-with-clangformat-part-3-persisting-the-change/)
> about reformatting a large codebase using clang-format.


Has anyone had a chance to review the auto formatted
versions
of OMR that Matthew thoughtfully put together for
us? For your
convenience:

* LLVM      https://github.com/mgaudet/omr/commits/clang-format-llvm
* Webkit    https://github.com/mgaudet/omr/commits/clang-format-webkit
* Mozilla   https://github.com/mgaudet/omr/commits/clang-format-mozilla
* Chromium  https://github.com/mgaudet/omr/commits/clang-format-chromium
* Google    https://github.com/mgaudet/omr/commits/clang-format-google

I would like to decide by the end of the week, if
possible. My vote is
for LLVM.

What do you think?

--mark





From:      
 Mark Stoodley/Toronto/IBM
To:      
 omr developer discussions
<omr-dev@xxxxxxxxxxx>
Date:      
 2016/08/26 09:07 AM
Subject:    
   Re: [omr-dev]
our coding standard

---

Charlie Gracie, Dan Heidinga and I had a phone
conversation yesterday
to discuss the coding standard topic. I have summarized
our discussion
below:

First, Mark asked to limit the conversation to code formatting as
opposed to coding standard (which also includes many
rules that are not
about code formatting). 

None of us would really like to have different code formatting through
the OMR project; we all see value in having a consistent
look to the OMR
code base.

Since the OMR code base does not have substantial history (since that
was thrown away when IBM contributed this part of
its J9 code base to
Eclipse OMR), Dan isn't too concerned about the forensic
loss to auto
formatting the entire code base if we can come to
an agreement on the
code format to use. Dan's earlier comment about J9's
code standard
wasn't taking into account that the remaining J9 code
base is going to
be open sourced (which probably means history loss
in that code base
too). We all agreed that, for us, the best state to
be in would be for
all of the open source J9 (including Java JIT) and
all of open source
OMR (including OMR JIT) having a single code format.
Of course, that's
not something we could expect from any other users
of OMR, but it's
something for us to strive for in these particular
code bases.

To help make the choice of coding standard more tangible, we suggested
to create some branches in personal forks of OMR to
show how the code
would look under one or two open source code formats
using clang-format.

As you will have noticed from Matthew's post yesterday
afternoon, that
part happened before I managed to get this summary
sent out.

We also discussed auto formatting on code commits.

Charlie first raised a concern that using an auto format tool with an
existing code standard could cause problems if the
community setting
that format decided to change it. Mark proposed we
store a particular
definition of the code format in our source tree so
that the OMR project
format is determined solely by us. That has the added
benefit that we
can add some fine tuning if we absolutely want to
at our discretion and
by taking into account the impact the change would
have on our code base.

Given that, Charlie and Mark are in favour of formatting code commits
automatically, so long as the reformat happens before
any CI testing
is initiated and before the merge request is presented
to reviewers.
That puts code formatting issues mostly out of the
reviewers' minds,
and tests the code that will actually be committed
if the merge request
is accepted. Some contributors may choose to run the
auto format tool
themselves 

Dan is less positive (but didn't say no :) ) due to his prior experience
with code formatting tools reducing the clarity of
more complicated code
snippets. But he agreed to keep an open mind and to
take a look at the
results of auto formatting the OMR code base before
making up his mind.

So, please take a look at those samples and tell us
what you think!
Anyone who wants to promote a particular code format
is welcome to use a
branch of their personal fork to help the community
decide. Just let us
know where to check it out!

--mark