Re: [omr-dev] our coding standard

["Kim T Briggs" <briggs@xxxxxxxxxx>]

I'll add here that a complete reformatting of the source at any point in time will make comparisons of any reformatted file with an earlier version that preceded reformatting a challenge. As an intrepid code archaeologist I'd suggest that reformatting be done just after a major milestone (eg, Java 9 release).

Kim

Mark Stoodley---08/23/2016 09:42:18 AM---Robert <rwy0717@xxxxxxxxx> writes: > As well, are we talking about running the formatter on the enti

From: Mark Stoodley/Toronto/IBM@IBMCA
To: omr developer discussions <omr-dev@xxxxxxxxxxx>
Date: 08/23/2016 09:42 AM
Subject: Re: [omr-dev] our coding standard
Sent by: omr-dev-bounces@xxxxxxxxxxx

---

Robert <rwy0717@xxxxxxxxx> writes:
> As well, are we talking about running the formatter on the entire
> codebase and committing the result? Are we interested in just running
> the formatter on new contributions? If we wanted to run clang-format
> only on new commits, it looks relatively easy to set up. Check out the
> bottom of http://clang.llvm.org/docs/ClangFormat.html

I guess we can debate that, but if we have a coding style that's
completely automated, then I see little reason to not use it on our
existing code base for uniformity. Of course, we would probably want to
do that in pieces and over time rather than as a single massive commit.

I also like the idea to run it on new commits, again for uniformity and
to get coding standard concerns out of the review process.

--mark




From:        Robert <rwy0717@xxxxxxxxx>
To:        omr developer discussions <omr-dev@xxxxxxxxxxx>
Date:        2016/08/22 09:14 PM
Subject:        Re: [omr-dev] our coding standard
Sent by:        omr-dev-bounces@xxxxxxxxxxx

---

Matthew Gaudet <magaudet@xxxxxxxxxxxxxxxxxx> writes:
> On 8/22/2016 1:47 PM, Mark Stoodley wrote:
>
>     I would like to propose we move to a completely different coding
>     standard that can be automatically applied by a tool like
>     clang-format: maybe something like LLVM or WebKit. With a tool
>     automatically applying the formatting, the risk of new bugs being
>     introduced is low whereas the benefit of a unified, consistent,
>     and automatically enforced coding standard is high
>
> Just a +1 to the idea of adopting an existing style.

+1. Adopting an existing standard can only help OMR's accessiblity.

You can take a look at the built in clang-format configs with:

   clang-format -style=<STYLE> -dump-config

build in styles are: LLVM, Google, Chromium, Mozilla, WebKit.

I'm just going to list a few thoughts about the LLVM style:

* #include ordering should match the OMR guidelines, ie system headers
  first, then OMR headers, all alphabetized. This might need tweaking.

* Our style is to indent using tabs. All built in styles use only
 spaces. Maybe this is something we want to adopt?

* Our style is to wrap braces in function/class/enum/etc definitions.
 Most (save Mozilla) leave braces on the same line.

* Are we willing to give up our punctuation-first initializer-list
 style? (vote for yes)

As well, are we talking about running the formatter on the entire
codebase and committing the result? Are we interested in just running
the formatter on new contributions? If we wanted to run clang-format
only on new commits, it looks relatively easy to set up. Check out the
bottom of http://clang.llvm.org/docs/ClangFormat.html

-  Robert
_______________________________________________
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



_______________________________________________
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