+1 for Webkit
--
Leonardo
On 29/08/16 05:02 PM, Mark Stoodley
wrote:
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
|