Thread: [Grouptime-developers] Coding Standard - is it ready?
Status: Pre-Alpha
Brought to you by:
sauanimal
Menu
▾
▴
grouptime-developers
|
From: Jan U. <ja...@ko...> - 2002-09-09 11:23:18
|
Hi! Can I get from developers the agreement, that we can say, this coding standard is acceptable and we declare this to our final release for now!? The last release can be found here: http://www.realtime.ee/~sau/coding_standards.zip If something doesn't like, let us know, and I'll fix it. If now feedback havent received by the end of today 09.09.2002, 10pm GMT 0, then I'll take that all agreed and I'll declare this doc for final. May the source be with you Jan Urva |
|
From: Jan U. <ja...@ko...> - 2002-09-09 14:00:24
|
Ok, changed some standards, some bugfixes, some additions. Is this acceptable for all: http://www.realtime.ee/~sau/coding_standards.zip If something doesn't like, let us know, and I'll fix it. If now feedback havent received by the end of today 09.09.2002, 10pm GMT 0, then I'll take that all agreed and I'll declare this doc for final. May the source be with you Jan Urva |
|
From: Andrey H. <and...@ma...> - 2002-09-09 14:16:59
|
Hi, what about my proposals 1) to have C as prefix in the class names. 2)to use PHPDoc compatible comments - for file and functions. Constants will self explain them. 3)I see that there is no proposal for variable names : $some_var or $someVar. I think the former is better because the second is the way the methods are named. So by using the former it will be easier to track errors for using an property instead of calling method. ($s->updateThing vs $s->updateThing() ). 4)Strict typing : If one var is used as int it will be int to the end of the script. In conditions IMO it is better to use === and !== to check and type. Otherwise problems can be faced. Consider this : <?php $str_val = '0'; if ($str_val) echo "one"; else echo "two"; ?> This will output "two" no matter that strlen($str_val) is not 0. This is type juggling. So use === to check. 5)Casting : I prefer this : $i_var = (int)$some_str_val; Others are (string), (float) New ones : 1)POSIX regex(ereg_* ) or PCRE regex(preg_*) ----- Original Message ----- From: "Jan Urva" <ja...@ko...> To: <gro...@li...> Sent: Monday, September 09, 2002 6:08 PM Subject: RE: [Grouptime-developers] Coding Standard - is it ready? > Ok, changed some standards, some bugfixes, some additions. > > Is this acceptable for all: > http://www.realtime.ee/~sau/coding_standards.zip > > If something doesn't like, let us know, and I'll fix it. > > If now feedback havent received by the end of today 09.09.2002, 10pm GMT > 0, then I'll take that all agreed and I'll declare this doc for final. > > May the source be with you > Jan Urva > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > Grouptime-developers mailing list > Gro...@li... > https://lists.sourceforge.net/lists/listinfo/grouptime-developers |
|
From: Jan U. <ja...@ko...> - 2002-09-09 14:22:45
|
> what about my proposals > 1) to have C as prefix in the class names. no C prefix, there's no point > 2)to use PHPDoc compatible comments - for file and functions. > Constants will self explain them. Nope, we use comments as they are described in our standard 3)I see that there is no > proposal for variable names : $some_var or $someVar. I think > the former is better because the second is the way the > methods are named. So by using the former it will be easier > to track errors for using an property instead of calling > method. ($s->updateThing vs > $s->updateThing() ). variable names are also used as $someVar, $someOtherVar > 4)Strict typing : > If one var is used as int it will be int to the end of the > script. In conditions IMO it is better to use === and !== to > check and type. Otherwise problems can be faced. Consider > this : <?php $str_val = '0'; if ($str_val) echo "one"; else > echo "two"; ?> This will output "two" no matter that > strlen($str_val) is not 0. This is type juggling. So use === > to check. 5)Casting : I prefer this : $i_var = > (int)$some_str_val; Others are (string), (float) I've told you, both can be used, it's not a matter of standard as I see it. > New ones : > 1)POSIX regex(ereg_* ) or PCRE regex(preg_*) I preffer ereg_*. Jan |
|
From: Lucas R. <lu...@uf...> - 2002-09-09 14:32:30
|
> > New ones : > > 1)POSIX regex(ereg_* ) or PCRE regex(preg_*) > I preffer ereg_*. I prefer preg_* ones! Perl is cool! :-) There are more docs about perl compatible than the other! :-) --lucasr |
|
From: Andrey H. <and...@ma...> - 2002-09-09 14:40:09
|
Comments follow. ----- Original Message ----- From: "Jan Urva" <ja...@ko...> To: <gro...@li...> Sent: Monday, September 09, 2002 6:31 PM Subject: RE: [Grouptime-developers] Coding Standard - is it ready? > > what about my proposals > > 1) to have C as prefix in the class names. > no C prefix, there's no point ok > > > 2)to use PHPDoc compatible comments - for file and functions. > > Constants will self explain them. > Nope, we use comments as they are described in our standard My reason to mention phpdoc comments is that there is phpdoc script that automatically generates help by parsing the code. I've used it and I liked it. The generated output is in XML and HTML so it is easily browseable. The HTML version has similarities of the Java docs. So the API can be generated with no hardness and regularily updated on the Home Page. I think is better to write comments in other way and to have automatic documentation generation. > 3)I see that there is no > > proposal for variable names : $some_var or $someVar. I think > > the former is better because the second is the way the > > methods are named. So by using the former it will be easier > > to track errors for using an property instead of calling > > method. ($s->updateThing vs > > $s->updateThing() ). > variable names are also used as $someVar, $someOtherVar I think that is not the best way. PHP is case sensitive for vars so lowecased vars with words separated by _ is better (imo = in my opinion). > > 4)Strict typing : > > If one var is used as int it will be int to the end of the > > script. In conditions IMO it is better to use === and !== to > > check and type. Otherwise problems can be faced. Consider > > this : <?php $str_val = '0'; if ($str_val) echo "one"; else > > echo "two"; ?> This will output "two" no matter that > > strlen($str_val) is not 0. This is type juggling. So use === > > to check. 5)Casting : I prefer this : $i_var = > > (int)$some_str_val; Others are (string), (float) > I've told you, both can be used, it's not a matter of standard as I see > it. ok > > New ones : > > 1)POSIX regex(ereg_* ) or PCRE regex(preg_*) > I preffer ereg_*. I will stick to preg_* much faster. Andrey |
|
From: Jan U. <sa...@kr...> - 2002-09-09 14:58:27
|
On Mon, 9 Sep 2002, Andrey Hristov wrote: > Comments follow. > > ----- Original Message ----- > From: "Jan Urva" <ja...@ko...> > To: <gro...@li...> > Sent: Monday, September 09, 2002 6:31 PM > Subject: RE: [Grouptime-developers] Coding Standard - is it ready? > > > > > what about my proposals > > > 1) to have C as prefix in the class names. > > no C prefix, there's no point > > ok > > > > > > 2)to use PHPDoc compatible comments - for file and functions. > > > Constants will self explain them. > > Nope, we use comments as they are described in our standard > > My reason to mention phpdoc comments is that there is phpdoc script that > automatically generates > help by parsing the code. I've used it and I liked it. The generated output > is in XML and HTML so > it is easily browseable. The HTML version has similarities of the Java docs. > So the API can be generated with no hardness and regularily updated on the > Home Page. > I think is better to write comments in other way and to have automatic > documentation generation. Let's leave it open for now, i don't know about that, i have to think it through. We're starting our comments standard. > > > 3)I see that there is no > > > proposal for variable names : $some_var or $someVar. I think > > > the former is better because the second is the way the > > > methods are named. So by using the former it will be easier > > > to track errors for using an property instead of calling > > > method. ($s->updateThing vs > > > $s->updateThing() ). > > variable names are also used as $someVar, $someOtherVar > > I think that is not the best way. PHP is case sensitive for vars so > lowecased vars with > words separated by _ is better (imo = in my opinion). i know, but i like the $someVar more (and lucas likes it), so, i think we'll keep it for now at least. > > > > 4)Strict typing : > > > If one var is used as int it will be int to the end of the > > > script. In conditions IMO it is better to use === and !== to > > > check and type. Otherwise problems can be faced. Consider > > > this : <?php $str_val = '0'; if ($str_val) echo "one"; else > > > echo "two"; ?> This will output "two" no matter that > > > strlen($str_val) is not 0. This is type juggling. So use === > > > to check. 5)Casting : I prefer this : $i_var = > > > (int)$some_str_val; Others are (string), (float) > > I've told you, both can be used, it's not a matter of standard as I see > > it. > > ok > > > > New ones : > > > 1)POSIX regex(ereg_* ) or PCRE regex(preg_*) > > I preffer ereg_*. > > I will stick to preg_* much faster. Ok, let's use preg_ then, no point of arquing, i think. For me it's no difference actually... Jan > Andrey > > > > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > Grouptime-developers mailing list > Gro...@li... > https://lists.sourceforge.net/lists/listinfo/grouptime-developers > |
Thanks for helping keep SourceForge clean.
X