| Re: [omr-dev] our coding standard |
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@xxxxxxxxxxMark 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
_______________________________________________ https://dev.eclipse.org/
omr-dev mailing list
omr-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visitmailman/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