Re: [omr-dev] our coding standard

["Daryl Maier" <maier@xxxxxxxxxx>]

Thanks for posting samples of several alternatives Matthew.

+1 for LLVM

..daryl

Mark Stoodley---08/29/2016 05:03:04 PM---Matthew was good enough to point out the following relevant articles that I thought everyone would f

From:        Mark Stoodley/Toronto/IBM@IBMCA
To:        omr developer discussions <omr-dev@xxxxxxxxxxx>
Date:        08/29/2016 05:03 PM
Subject:        Re: [omr-dev] our coding standard
Sent by:        omr-dev-bounces@xxxxxxxxxxx

---

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

_______________________________________________
omr-dev mailing list
omr-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/omr-dev