[Proj] Code style in Proj

[Dan Crosby]

Hi Kurt,
 
If you want a few nit-picks (based on my personal preferences admittedly, and with no reference to any standards but my own):
·         I hate the dangling brackets – it makes the code asymmetrical, how can you stand to look at it? (Ok, I prepared to concede, this might just be me!)
·         I like to avoid single line if statements (i.e., with no brackets). Apart from it being inconsistent with other if statements, it can be easy to misread the code if it isn’t properly spaced and indented.
·         I find that method of switch indenting hard to parse. I would do this, and always bracket the whole case expression for consistency (which is variable in your example):
 
switch (thing)
{
    case C1:
    {
        // Code part
    } break;
 
    case C2:
    {
        // More code
    } // fallthrough
 
    default:
    {
        // Code
    }
}
 
·         There are some minor inconsistencies in the  use of spaces around commas and operators (again, my preference being for more space!):
if (0==P)                   vs            if (0 == P)
XY xy = {0.0,0.0};          vs            XY xy = {0.0, 0.0};
(lp.lam+P->lam0)            vs            (lp.lam + P->lam0)
 
·         Unless tools demand it, why the horizontal restrictions (or is this an artefact of github) ?
This is easier to read:
            lp.phi = aasin(P->ctx,cosc * Q->sinph0 + xy.y * sinc * Q->cosph0 / c_rh);
 
 
I just hope list reformatting doesn’t ruin my points J
 
Dan
 
 
From: proj-bounces at lists.maptools.org <proj-bounces at lists.maptools.org> On Behalf Of Kurt Schwehr
Sent: Tuesday, 1 May 2018 07:45
To: PROJ.4 and general Projections Discussions <proj at lists.maptools.org>
Subject: Re: [Proj] Code style in Proj
 
Thanks for the proj_coord().  I meant to look that up, but got interrupted by a poopy diaper.
 
I would be happy to create a draft document for people to comment on.  It will be slow going as I only get little bits of time here and there for the next week.
 
I do have to say that I don't like removing the math.h from the main file.   The cost is small and it frees you to refactor other headers without wide ranging changes each time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20180501/17c36893/attachment.html>