Re: [omr-dev] our coding standard

["Filip Jeremic" <fjeremic@xxxxxxxxxx>]

Another +1 for adopting an existing style
and auto-formatting new commits. With adopting an existing style we have
a tool that ensures we are 100% conferment and we can stop wasting time
on style in code reviews and focus on the quality.

>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

I suspect there will be many outsider
eyes looking at our codebase when OMR JIT (or J9) goes open. I would vouch
to say the earlier we bite the bullet and format the entire codebase the
easier it will be for any newcomers later on. Everyone likes looking at
a consistent codebase and with the OMR JIT already using a wildly different
coding style than OMR GC I propose this would be an excellent time to do
a full repository reformat (when the OMR JIT codedrop happens).

- Filip



From:      
 Kim T Briggs/Ottawa/IBM@IBMCA
To:      
 omr developer discussions
<omr-dev@xxxxxxxxxxx>
Date:      
 08/23/2016 10:25 AM
Subject:    
   Re: [omr-dev]
our coding standard
Sent by:    
   omr-dev-bounces@xxxxxxxxxxx

---

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