Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Re: [propel-dev] Coding Standards

propel
Discussion topic

Hide all messages in topic

All messages in topic

Re: [propel-dev] Coding Standards

Reply

Author Carl Parrish <cparrish at pcl-consulting dot com>
Full name Carl Parrish <cparrish at pcl-consulting dot com>
Date 2006-12-06 07:54:51 PST
Message Hans Lellelid wrote:
>
>
> Yeah, I tend to agree. My personal preference is a hybrid approach
> where functions are like
>
> public function myfunc()
> {
>
> }
>
> but if-statements are on same line:
>
> if ($foo === true) {
>
> } elseif () {
>
> } else {
>
> }
>
> But for the same of consistency, I'm willing to give up my functions
> with { opening on their own line :)
>
> For simplicity, we may just wish to adopt the PEAR coding standards,
> since they are ubiquitous in the PHP world.
>
> Hans
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>
I realize I'm *months* late on this thread but just wanted to add a me
too. This is my preferred style.

Re: [propel-dev] Coding Standards

Reply

Author =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com>
Full name =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com>
Date 2006-09-23 07:43:10 PDT
Message > David Zülke wrote:
>>
>> http://trac.agavi.or​g/trac.cgi/wiki/Codi​ngStyle if you guys need
>> some inspiration ;)
>>
> I like this. I think we can adopt this for Propel coding style.
> Maybe I'll just steal the page as a starting point ;)

Sure, go ahead ;) This 11-char-gap (longest PHPDoc keyword is 10
chars) was a pain to realize because I had to clean up every single
file by hand but it was worth it - everything is nice and tidy now. I
also use a similar rule to lign up the description for @return <type>
blocks (see array and string in the example), but that's a matter of
taste.

- David

Re: [propel-dev] Coding Standards

Reply

Author hlellelid
Full name Hans Lellelid
Date 2006-09-23 07:22:03 PDT
Message David Zülke wrote:
>
> http://trac.agavi.or​g/trac.cgi/wiki/Codi​ngStyle if you guys need some
> inspiration ;)
>
I like this. I think we can adopt this for Propel coding style. Maybe
I'll just steal the page as a starting point ;)

Hans

Re: [propel-dev] Coding Standards

Reply

Author =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com>
Full name =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com>
Date 2006-09-23 07:18:45 PDT
Message +1

http://trac.agavi.or​g/trac.cgi/wiki/Codi​ngStyle if you guys need some
inspiration ;)


Am 21.09.2006 um 16:03 schrieb Hans Lellelid:
> Yeah, I tend to agree. My personal preference is a hybrid approach
> where functions are like
>
> public function myfunc()
> {
>
> }
>
> but if-statements are on same line:
>
> if ($foo === true) {
>
> } elseif () {
>
> } else {
>
> }

Re: [propel-dev] Coding Standards

Reply

Author Ron Rademaker <r dot rademaker at virtualbuilding dot nl>
Full name Ron Rademaker <r dot rademaker at virtualbuilding dot nl>
Date 2006-09-21 07:46:43 PDT
Message Ok, quite clear.

Do have a new one though (which is the result of scrolling through some
code to manually merge some changes). Let's not keep commented code in
the classes, for example commented var_dumps.

Ron

Hans Lellelid wrote:
> I agree with Alan here. I mandate the {} in code we write at work too.
> So many bugs because people add code (like debug statements) and forget
> that they weren't in a {} block.
>
> Hans
>
> Alan Pinstein wrote:
>
>> I highly disagree with this one...
>>
>> I used to prefer this style too, but after hunting down bugs caused by
>> adding a 2nd line and forgetting {} I changed my tune.
>>
>> This issue gets WORSE in an open source project as someone might add a
>> line who's used to always having {} and introduce bugs.
>>
>> I think {} should always go with "if" no matter what.
>>
>> Alan
>>
>>
>>
>>> - 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.
>>>
>>
>> --------------------​--------------------​--------------------​---------
>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
>> For additional commands, e-mail: dev-help at propel dot tigris dot org
>>
>>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>
>

Re: [propel-dev] Coding Standards

Reply

Author hlellelid
Full name Hans Lellelid
Date 2006-09-21 07:42:40 PDT
Message I agree with Alan here. I mandate the {} in code we write at work too.
So many bugs because people add code (like debug statements) and forget
that they weren't in a {} block.

Hans

Alan Pinstein wrote:
> I highly disagree with this one...
>
> I used to prefer this style too, but after hunting down bugs caused by
> adding a 2nd line and forgetting {} I changed my tune.
>
> This issue gets WORSE in an open source project as someone might add a
> line who's used to always having {} and introduce bugs.
>
> I think {} should always go with "if" no matter what.
>
> Alan
>
>
>> - 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.
>
>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>

Re: [propel-dev] Coding Standards

Reply

Author Alan Pinstein <apinstein at mac dot com>
Full name Alan Pinstein <apinstein at mac dot com>
Date 2006-09-21 07:38:56 PDT
Message I do most of mine in VIM, so I am probably biased... but...

Having the vim formatting at the top of each file has the added
benefit of REMINDING EVERYONE OF THE PREFERRED SETTINGS regardless of
editor, and if you happen to use VI, then it's automatic. It's kinda
just a simple coding standard for documenting our preferred settings...

/* vim: set noexpandtab tabstop=8 shiftwidth=8 fileformat=unix: */

Also, I have not ever seen any other editor specific markup, so I am
wondering maybe if other editors support the vim format?

I won't cry if no one wants to do it tho :)

Alan

On Sep 21, 2006, at 8:44 AM, Hans Lellelid wrote:

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

Re: [propel-dev] Coding Standards

Reply

Author Alan Pinstein <apinstein at mac dot com>
Full name Alan Pinstein <apinstein at mac dot com>
Date 2006-09-21 07:36:02 PDT
Message Agree!

On Sep 21, 2006, at 10:31 AM, Even André Fiskvik wrote:

> The PEAR coding standards was established with PHP 4 in mind.
> Since Propel is targeted at PHP 5.x, which implements private/
> protected access modifiers, we don't really need to "emulate" this
> functionality by using underscores etc.
Attachments

Re: [propel-dev] Coding Standards

Reply

Author Alan Pinstein <apinstein at mac dot com>
Full name Alan Pinstein <apinstein at mac dot com>
Date 2006-09-21 07:33:25 PDT
Message I highly disagree with this one...

I used to prefer this style too, but after hunting down bugs caused
by adding a 2nd line and forgetting {} I changed my tune.

This issue gets WORSE in an open source project as someone might add
a line who's used to always having {} and introduce bugs.

I think {} should always go with "if" no matter what.

Alan


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

Re: [propel-dev] Coding Standards

Reply

Author =?UTF-8?B?RXZlbiBBbmRyw6kgRmlza3Zpaw==?= <even at lynweb dot no>
Full name =?UTF-8?B?RXZlbiBBbmRyw6kgRmlza3Zpaw==?= <even at lynweb dot no>
Date 2006-09-21 07:31:05 PDT
Message Hans Lellelid wrote:
> Cameron Brunner wrote:
>
>> Against just following the heard and using PEAR standards
>>
>> switch ( $blah ) {
>>
>> case 'blah':
>>
>> echo 'asdf';
>> break;
>>
>> }
>>
>> indenting the case is something i prefer over not for a start
>>
>> $long_variable example... well, we could follow that but... painful
>> for nothing?
>>
>> These are just what I like and find easy to follow and read without
>> having to think much when i jump into new code. Mostly its just about
>> not being lazy and getting over typing a few extra lines to save
>> headaches maintaining.
>>
>>
> Ok, well, it's been awhile since I've looked at PEAR coding standards.
> I definitely don't like their variable naming standards. I don't think,
> for example, that all private/protected variables & methods should be
> prefixed with underscore. I don't think it's necessary -- and in the
> case of variables, I think they should generally all be
> private/protected anyway.
>
> Hans
>
The PEAR coding standards was established with PHP 4 in mind.
Since Propel is targeted at PHP 5.x, which implements private/protected
access modifiers, we don't really need to "emulate" this functionality
by using underscores etc.

Just my five cents.

Best regards,
Even André
Attachments

Re: [propel-dev] Coding Standards

Reply

Author hlellelid
Full name Hans Lellelid
Date 2006-09-21 07:27:23 PDT
Message Cameron Brunner wrote:
> Against just following the heard and using PEAR standards
>
> switch ( $blah ) {
>
> case 'blah':
>
> echo 'asdf';
> break;
>
> }
>
> indenting the case is something i prefer over not for a start
>
> $long_variable example... well, we could follow that but... painful
> for nothing?
>
> These are just what I like and find easy to follow and read without
> having to think much when i jump into new code. Mostly its just about
> not being lazy and getting over typing a few extra lines to save
> headaches maintaining.
>
Ok, well, it's been awhile since I've looked at PEAR coding standards.
I definitely don't like their variable naming standards. I don't think,
for example, that all private/protected variables & methods should be
prefixed with underscore. I don't think it's necessary -- and in the
case of variables, I think they should generally all be
private/protected anyway.

Hans

Re: [propel-dev] Coding Standards

Reply

Author Cameron Brunner <cameron dot brunner at gmail dot com>
Full name Cameron Brunner <cameron dot brunner at gmail dot com>
Date 2006-09-21 07:25:26 PDT
Message On 9/22/06, Hans Lellelid <hans at velum dot net> wrote:
> Hi,
>
> 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
>
> We can also get rid of Torque authors at this point (1.3 onward). I
> wanted to attribute the origins of the code as appropriate, but the
> classes have been reworked a number of times now -- so they'll probably
> be bearing little resemblance to any Torque code from here on out.
>
> >> - 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!
>
> Yeah, I tend to agree. My personal preference is a hybrid approach
> where functions are like
>
> public function myfunc()
> {
>
> }
>
> but if-statements are on same line:
>
> if ($foo === true) {
>
> } elseif () {
>
> } else {
>
> }
>
> But for the same of consistency, I'm willing to give up my functions
> with { opening on their own line :)
>
> For simplicity, we may just wish to adopt the PEAR coding standards,
> since they are ubiquitous in the PHP world.

Against just following the heard and using PEAR standards

switch ( $blah ) {

    case 'blah':

        echo 'asdf';
        break;

}

indenting the case is something i prefer over not for a start

$long_variable example... well, we could follow that but... painful for nothing?

These are just what I like and find easy to follow and read without
having to think much when i jump into new code. Mostly its just about
not being lazy and getting over typing a few extra lines to save
headaches maintaining.


Cameron

Re: [propel-dev] Coding Standards

Reply

Author hlellelid
Full name Hans Lellelid
Date 2006-09-21 07:03:20 PDT
Message Hi,

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

We can also get rid of Torque authors at this point (1.3 onward). I
wanted to attribute the origins of the code as appropriate, but the
classes have been reworked a number of times now -- so they'll probably
be bearing little resemblance to any Torque code from here on out.

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

Yeah, I tend to agree. My personal preference is a hybrid approach
where functions are like

public function myfunc()
{

}

but if-statements are on same line:

if ($foo === true) {

} elseif () {

} else {

}

But for the same of consistency, I'm willing to give up my functions
with { opening on their own line :)

For simplicity, we may just wish to adopt the PEAR coding standards,
since they are ubiquitous in the PHP world.

Hans

Re: [propel-dev] Coding Standards

Reply

Author =?UTF-8?B?RXZlbiBBbmRyw6kgRmlza3Zpaw==?= <even at lynweb dot no>
Full name =?UTF-8?B?RXZlbiBBbmRyw6kgRmlza3Zpaw==?= <even at lynweb dot no>
Date 2006-09-21 07:02:34 PDT
Message Ron Rademaker wrote:
> 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 agree on not using "short-cuts" like these. It makes the code less
readable, and for the sake of god,
is there a world shortage of whitespaces and brackets that I do not know of?

Best regards,
Even André

Re: [propel-dev] Coding Standards

Reply

Author Ron Rademaker <r dot rademaker at virtualbuilding dot nl>
Full name Ron Rademaker <r dot rademaker at virtualbuilding dot 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
>
>

Re: [propel-dev] Coding Standards

Reply

Author Cameron Brunner <cameron dot brunner at gmail dot com>
Full name Cameron Brunner <cameron dot brunner at gmail dot 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

Re: [propel-dev] Coding Standards

Reply

Author Ron Rademaker <r dot rademaker at virtualbuilding dot nl>
Full name Ron Rademaker <r dot rademaker at virtualbuilding dot 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
>
>

Re: [propel-dev] Coding Standards

Reply

Author Cameron Brunner <cameron dot brunner at gmail dot com>
Full name Cameron Brunner <cameron dot brunner at gmail dot com>
Date 2006-09-21 06:40:12 PDT
Message 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

Re: [propel-dev] Coding Standards

Reply

Author hlellelid
Full name Hans Lellelid
Date 2006-09-21 06:12:47 PDT
Message 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
>

Re: [propel-dev] Coding Standards

Reply

Author Cameron Brunner <cameron dot brunner at gmail dot com>
Full name Cameron Brunner <cameron dot brunner at gmail dot com>
Date 2006-09-21 06:03:09 PDT
Message 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

Re: [propel-dev] Coding Standards

Reply

Author hlellelid
Full name Hans Lellelid
Date 2006-09-21 05:44:54 PDT
Message 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
>

Coding Standards

Reply

Author Cameron Brunner <cameron dot brunner at gmail dot com>
Full name Cameron Brunner <cameron dot brunner at gmail dot com>
Date 2006-09-20 21:21:50 PDT
Message 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
Messages per page: