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 metoo. This is my preferred style.

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.

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

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

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

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

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.

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 beprefixed with underscore. I don't think it's necessary -- and in thecase of variables, I think they should generally all beprivate/protected anyway.

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 withouthaving to think much when i jump into new code. Mostly its just aboutnot being lazy and getting over typing a few extra lines to saveheadaches maintaining.

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). Iwanted to attribute the origins of the code as appropriate, but theclasses have been reworked a number of times now -- so they'll probablybe 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 approachwhere 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 functionswith { 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.

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?

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

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 authorisnt the same for the function then it should be on the function aswell, 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 codebelow the if too often, we should blow this out of existance!

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

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

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 turningaway code, but that we will ensure that releases adhere to standards.

You're suggestions are fine. For phpdoc, I personally like the PEAR style:

I think there is a coding style page on the wiki. Feel free to updatethat 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>

I'm for accepting patches with wrong coding rules only for us to comealong later and fix them up however i would state that we shouldenforce a RELEASE version of propel to be fully compliant with thecoding standards. I'm also for getting strict with the rules. I amactually looking into using php code sniffer (check pear) to do thisfor us (including notifying us of the generated code problems).

Tabs - agreed, set it to 2 4 or 8 depending on your own preferenceclass and function {}'s - opening on the same line as the definitionextra whitespace often - if ( $blah == $blahblah ) not if($blah==$blahblah)extra linebreak after { and }extra linebreak in anything in the same function that is for anythingtoo different ($query stuff then $criteria stuff should be brokenapart)

Thats just a few things id like to see personally off the top of myhead. Anyone got any comments about these? What rules for phpdoccomments?

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

Ok, I agree. (And I -- or at least my editors -- are probably partly toblame for inconsistencies.)

- Definitely unix line endings should be standard (there I know thatI'm at fault for having misset defaults at some point in PHPEdit.) - I personally prefer tabs for whitespace, though I'm open todiscussion on that. - I do most of my editing in GUI editors (like PHPEdit or Eclipse), soI also don't like editor-specific markup in the files (I guess I'mthinking of vim).

I'm very fine with having coding guidelines, but I don't want tooverstep that line where the coding standards are just arbitrary rulesto 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>

After delving thru the codebase i have been seeing functions usespaces for indentation (4space) and tabs used half way thru (tabs setto 8 on my vim), can we start to enforce some sort of codingstandards? I'm even happy enough to go thru every file myself andsetup the standards we agree on.