I would +1 Webkit and Chromium, and -1 llvm, mozilla, and google. Why? The first two favour having more code on the screen vertically that then latter three.
The more code I can see on my screen the easier it is for me to understand it. I also don't believe that limiting code to an 80 column width is necessary with today's display capabilities.
for (i = 0, frame = threadInfo->callstack; frame != NULL;
frame = frame->parent_frame, i++) {
----- Original message ----- From: Leonardo <leob@xxxxxxxxxxxxxxxxxx> Sent by: omr-dev-bounces@xxxxxxxxxxx To: omr-dev@xxxxxxxxxxx Cc: Subject: Re: [omr-dev] our coding standard Date: Tue, Aug 30, 2016 8:29 AM
+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:
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!
_______________________________________________ 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
