Login | Register
My pages Projects Community openCollabNet

propel
Reply to message

* = Required fields
* Subject
* Body
Attachments
Send reply to
Topic
Author (directly in email)
Please type the letters in the image above.

Original message

Author Ron Rademaker <r.rademaker@virtualbuilding.nl>
Full name Ron Rademaker <r.rademaker@virtualbuilding.nl>
Date 2006-09-21 06:47:09 PDT
Message A few thoughts:

- On the comments before a function. How about always adding a @since
with the date the function was added and an @author who added the
function (makes finding the appropriate person for bugs / questions /
suggestions a lot easier than going through svn logs)

- Personally, I like if styles like this:

if ($something)
    return "something";

Two lined if's without {} that is, current coding standards don't tell
me if I can use them.

- I'd like to suggest always giving } an entire line, so:

if (..) {

}
else {

}

instead of:

if (..) {

} else {

}

Ron

Cameron Brunner wrote:
> First draft, feel free to update...
>
> On 9/21/06, Hans Lellelid <hans at velum dot net> wrote:
>> Hi Cameron,
>>
>> Ok, sounds good. I agree with you on standards, though I've [obviously]
>> been a bit lax at enforcing them. I think we agree then on not turning
>> away code, but that we will ensure that releases adhere to standards.
>>
>> You're suggestions are fine. For phpdoc, I personally like the PEAR
>> style:
>>
>> /**
>> * One line description.
>> * More content
>> * @param string $p1 Desc of param
>> * @returns boolean Desc of return
>> */
>> public static function myFunc($p1) {
>> // ...
>> }
>>
>> I think there is a coding style page on the wiki. Feel free to update
>> that with your suggestions, etc.
>>
>> Hans
>>
>> Cameron Brunner wrote:
>> > I'm for accepting patches with wrong coding rules only for us to come
>> > along later and fix them up however i would state that we should
>> > enforce a RELEASE version of propel to be fully compliant with the
>> > coding standards. I'm also for getting strict with the rules. I am
>> > actually looking into using php code sniffer (check pear) to do this
>> > for us (including notifying us of the generated code problems).
>> >
>> > Tabs - agreed, set it to 2 4 or 8 depending on your own preference
>> > class and function {}'s - opening on the same line as the definition
>> > extra whitespace often - if ( $blah == $blahblah ) not
>> > if($blah==$blahblah)
>> > extra linebreak after { and }
>> > extra linebreak in anything in the same function that is for anything
>> > too different ($query stuff then $criteria stuff should be broken
>> > apart)
>> >
>> > Thats just a few things id like to see personally off the top of my
>> > head. Anyone got any comments about these? What rules for phpdoc
>> > comments?
>> >
>> > On 9/21/06, Hans Lellelid <hans at velum dot net> wrote:
>> >> Ok, I agree. (And I -- or at least my editors -- are probably
>> partly to
>> >> blame for inconsistencies.)
>> >>
>> >> - Definitely unix line endings should be standard (there I know that
>> >> I'm at fault for having misset defaults at some point in PHPEdit.)
>> >> - I personally prefer tabs for whitespace, though I'm open to
>> >> discussion on that.
>> >> - I do most of my editing in GUI editors (like PHPEdit or
>> Eclipse), so
>> >> I also don't like editor-specific markup in the files (I guess I'm
>> >> thinking of vim).
>> >>
>> >> I'm very fine with having coding guidelines, but I don't want to
>> >> overstep that line where the coding standards are just arbitrary
>> rules
>> >> to enforce or use as a basis for rejecting contributed work (e.g.
>> PEAR).
>> >>
>> >> Other thoughts?
>> >>
>> >> Hans
>> >>
>> >> Cameron Brunner wrote:
>> >> > After delving thru the codebase i have been seeing functions use
>> >> > spaces for indentation (4space) and tabs used half way thru
>> (tabs set
>> >> > to 8 on my vim), can we start to enforce some sort of coding
>> >> > standards? I'm even happy enough to go thru every file myself and
>> >> > setup the standards we agree on.
>> >> >
>> >> >
>> >> > Cameron
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>