RE: [Grouptime-developers] Coding Standard - is it ready?

[Jan U. <ja...@ko...>]

> Hi all,
> I got some comments on the coding standard:
> 1)I don't see any reason to use short tags instead of long in 
> all places. Exception is<?=$some_var;?> which is faster to 
> write than <?php echo $some_var;?> . But I see that 
> <?=$some_var;?> is not preferred. 
This <? ehco ... ?> it's more clearer. Therefore it stays.

2)Indentaion. IMO 
> indentation must be in tabs. Every good editor can be 
> configured how much spaces(visual) tab to be - I use 4 spaces 
> for tab but someone can use 8 spaces. So I think that there 
> should not be any indentation spaces. 

qutoe:indentation should be used four (4) whitespaces or TAB's that act
like four (4) whitesspaces.
therefore, we allow both variants but, the TAB must be 4 whtiespace :)

3)Class names. Let's 
> get it like C++ and add 'C' as a prefix. So class names like 
> CMyClass, CFoo, CBar. 
I don't see no point, so we don't change that.

4)$class = new MyClassName;
>   Why not CMyClassName() - no matter there are no params this 
> is call to method. 
same as previous

5)if operator:
>     Which is better :
>     if ($some_var == 1) {
> 
>     } else {
> 
>     }
> OR
>     if ($some_var == 1){
> 
>     }else{
>     }
> 
> I prefer the second one but the former is K&R style that is 
> used in php sources I when i wrote patches I use it. I think 
> we must decide which one we will use. 
We'll use the first one, space betweem ) {

6)Strict types: 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.
I think this is not a matter of coding standard, it's more like the
feature of programming language... meaning we can use it.

7)Casting : I prefer this : $i_var = 
> (int)$some_str_val;  Other are (string), (float) 
Acceptable

8)File comments : I think we have to phpdoc compatible comments. 
> LIke this: <?php
> /**
> Class that has all the features of input validatin
> 
> @author  Andrey Hristov
> @version  $Id: cinputvalidate.class.php,v 1.25 2002/09/02 
> 16:20:21 andrey Exp $ @package Group_Time @module  
> Input_validation */ 

9)Function comments :
>  /**
>  * Checks for validity.
>  *
>  * @access public
>  * @param array $check_vars Array with properties of the 
> category to be created.
>  * @return array $ret_ar  1. VALIDATE_FAIL - if data 
> validation failed at some point (about 2 validations).
>  *        2. GENERAL_OPERATION_SUCCESSFUL if there is no 
> error from 1 to
> 1.
>  */
Don't like them,therefore we don't use them

 
> 10)Statuses returned from methods. To extend TRUE/FALSE .
>   Look above and see - if validation failed array is returned 
> - array(VALIDATE_FAIL, 2); The second parameter is used to 
> track where in the code the validation failed. If everything 
> went ok - then
> array(GENERAL_OPERATION_SUCCESSFUL) is returned. There can be 
> any other var after the first - it can be used to return vars 
> from the function. In this case VALIDATE_ is namespace for 
> validation constants. GENERAL_ is namespace for general 
> constants and so on.
Agreed.

 11)Namespaces for constants - if some 
> module introduces constants they must be written and used in 
> uppercase. No matter that php is case insensitive by default 
> for constants. Every module has a prefix and all constants 
> has to have prefix. Uppercased constants applies also to TRUE/FALSE.
Agreed

Jan