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:58:56 PDT
Message Cameron Brunner wrote:
> 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!

Let's not start these kind of discussions... none have ever proven to be
useful :)

>
>> - 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 {
>
> // ...
>
> }

I totally agree on the elseif. The reason why I like the } on a single
line is quite simple, I've had a few occasions where I somehow read over
the } else { so I thought I was still reading the if. That's why I
started to put the else on a newline (but back in those days I also had
my tab set to 2 spaces... now I don't, so this practical issue might
have solved itself with that.).

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