[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [omr-dev] our coding standard
|
+1 and thanks Charlie.One of the things I'd like to see in that issue is
to preview the entirecode base with WebKit and then look at some specific
areas to see how wellit deals with deep conditional statements.From:
Charlie Gracie <charlie.gracie@xxxxxxxxx>To:
omr developer discussions
<omr-dev@xxxxxxxxxxx>Date:
2016/10/05 11:46 AMSubject:
Re: [omr-dev]
our coding standardSent by:
omr-dev-bounces@xxxxxxxxxxx
I believe I see the most votes for WebKit as the format
of choice. I think there are some tweaks we may want to make but
I think we should go forward with this approach. I will open an Issue
on GitHub to track the work.CharlieOn Wed, Sep 7, 2016 at 6:05 PM, Xiaoli Liang <xsliang@xxxxxxxxxx>
wrote:My 2 cents...
I prefer LLVM as well. Other than reasons already stated by others earlier,
I also like the fact that curly braces are placed more consistently with
the LLVM style than WebKit, i.e. together with the previous line of code.
Thanks!
Xiaoli (Shelley) Liang
Java JIT Compiler Group
IBM Toronto Software Lab
Tel.: (905)
413-3989
Fax: (905)
413-4854
xsliang@xxxxxxxxxx
Mark
Stoodley---09/07/2016 01:30:02 PM---Agree with all that, though I still
(am losing with the :) ) vote for LLVM. I think
From: Mark Stoodley/Toronto/IBM@IBMCA
To: omr developer discussions <omr-dev@xxxxxxxxxxx>
Date: 09/07/2016 01:30 PM
Subject: Re: [omr-dev] our coding standard
Sent by: omr-dev-bounces@xxxxxxxxxxx
Agree with all that, though I still (am losing with the :) ) vote for LLVM.
I think
having our own line wrap setting is an easy thing for us to adjust (slippery
slope
to having our own format, but length of line is a pretty innocuous difference
and
feels unlikely to hit some corner case bug in the tool).
The technical arguments will sound pretty obvious, I'm sure.
I suppose tab characters save some bytes when uncompressed, but I'm not
sure anyone
is counting bytes in source files so carefully. I guess it's less typing
for anyone
that actually hits the space bar multiple times. Your space bar might wear
out less
often (though I confess it's never been a problem for me :) ).
Arguments against tabs would be scenarios where alignment requires less
than a full
tab stop (whatever a tab stop means, which is exactly the problem). Even
alignment
of comments becomes troublesome (I know, we shouldn't be trying to align
anything :/).
Most viewers by default, including GitHub code review, will show 8 space
tabs which
wastes lines for anyone who wants less than 8 spaces (I do). Alternatives
exist
ranging from browser extensions to manual URL mangling: all somewhat dissatisfying.
There are probably other technical arguments on both sides, but I doubt
any of them
will conclusively drive our entire community one way or the other.
I favour a consistent look and feel no matter whose computer I'm looking
at. I do not
value the flexibility that tabs offer. I know I'm not alone; I know others
disagree.
My vote remains: LLVM and spaces.
--mark
From: Charlie Gracie <charlie.gracie@xxxxxxxxx>
To: omr developer discussions <omr-dev@xxxxxxxxxxx>
Date: 2016/09/07 10:11 AM
Subject: Re: [omr-dev] our coding standard
Sent by: omr-dev-bounces@xxxxxxxxxxx
Sorry about joining the conversation a little late.
I really like the idea of having a tool auto-format the code so no one
has to worry about that during reviews. I think it will be a great move
forward for the project, especially if it reduces our coding standard to
a statement which says run the tool.
Matthew thank you for taking the time to put together all of the branches
showing the different versions we may want to choose from.
After spending a few hours digging through different files for each format
I feel the most comfortable with WebKit. The two things I am not sure about
are the use of spaces instead of tabs and the short column width before
wrapping. The line wrapping just feels like a waste of vertical space.
I would be much happier with WebKit if we turned that off.
The lines vs tabs seems more like a philosophical discussion. Does anyone
have any technical reasons why one is preferred over the other?
Charlie
On Fri, Sep 2, 2016 at 11:49 AM, Luc des Trois Maisons <lmaisons@xxxxxxxxxxxxxxxxxx>
wrote:
On 09/02/2016 02:36 AM, Daniel Heidinga wrote:
The lines are unnecessary short. Most people have large monitors, no need
to wrap lines.
This has been said at least twice now by various people.
I found the shorter lines significantly improved my ability to read / ingest
the code. I have plenty of horizontal screen real estate, however my working
visual memory isn't great, and for whatever reason, long lines tax it more
heavily than multiple short ones.
I also get the intuitive sense that it makes diffs easier to parse, but
have no strong evidence for this.
Now, I'm happy to cede this point if it maximises our collective utility
to do otherwise, but I seek to have us to make that decision with a reasonably
complete appreciation of the consequences.
Luc
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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