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 Cameron Brunner <cameron.brunner@gmail.com>
Full name Cameron Brunner <cameron.brunner@gmail.com>
Date 2006-09-21 06:53:32 PDT
Message On 9/21/06, Ron Rademaker <r.rademaker@virt​ualbuilding.nl> wrote:
> 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)

svn blame, but agreed, author for the class and then if the author
isnt the same for the function then it should be on the function as
well, same rules for since

> - 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.

ug, no, i HATE this, people rely on it for more than 1 line of code
below the if too often, we should blow this out of existance!

> - I'd like to suggest always giving } an entire line, so:
>
> if (..) {
>
> }
> else {
>
> }
>
> instead of:
>
> if (..) {
>
> } else {
>
> }

ummmm, that just looks weird to me... i would also say we should add
elseif rules, personally elseif as 1 word, not 2

if ( $something == 1 ) {

 // ...

} elseif ( $blah == 2 ) {

 // ...

} 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