FWIW that style guide is useless.
It's simplest to do what the existing code does. It's okay to adapt one
to a specific style inside of a library, but mixing styles inside the
same file is not very pleasant. For example, does it kill whoever likes
this:
if(expression)
to insert one space between the if and the paren? Now we have 1% of all
ifs different from all others. What good does that do?
Then we have of course
if( expression )
which accounts for about 10% of all ifs (looks like Sean and Don are
using that one) and finally the oddest of all:
if( expression)
I'd say at least if making small edits for one module it's common
courtesy to keep whatever style the module already had instead of
debating (and inconsistently inserting) the relative merits of different
styles.
Andrei
On 01/22/2011 10:16 PM, Jonathan M Davis wrote:
On Friday 21 January 2011 19:48:09 Andrei Alexandrescu wrote:
On 1/21/11 8:56 PM, Brad Roberts wrote:
<snip not-broken style issues -- not that I disagree, just partitioning
the discussion>.
I'd love to have a minimal stylistic checker upon checkin. For one
thing, I don't find any reason for two empty lines and I don't plan to
rearrange the monitor sideways for more vertical space.
By the way, the D style guide currently posted on the main site specifically
says
that you're _supposed_ to put two blank lines between function bodies. It also
claims that all submissions to Phobos are supposed to follow those guidelines.
So, if you _really_ don't want two blank spaces between function bodies, then
that page should probably be updated. I confess that I prefer that there be two
blank lines between functions, and I'm not sure that that page quite matches the
style that we want in Phobos anyway (though glancing at it, it looks pretty much
correct), but we might want to make sure that that page actually reflects what
we're actually trying to do in Phobos. At minimum, specifically testing with a
stylistic checker that something is _not_ done in code when the style page on
the main site says that it's _supposed_ to be in code wouldn't really look good
(not to mention, it would be confusing to anyone who actually paid attention to
both). I confess that I only noticed though, because someone on D.Learn was
wondering why various enums in Phobos don't follow the style guide - such as
Endian.BigEndian and FunctionAttributes.NOTHROW.
- Jonathan M Davis
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
