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

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

Andrey want me to post this one, he has some kind of trouble

>>>>>>
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.
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. 3)Class names. Let's get it like C++ and add 'C' as
a prefix. So class names like CMyClass, CFoo, CBar. 4)$class = new
MyClassName;
  Why not CMyClassName() - no matter there are no params this is call to
method. 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. 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. 7)Casting : I prefer this :
$i_var = (int)$some_str_val;  Other are (string), (float) 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.
 */

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

This is for now. Please comment. :))

Andrey
<<<<<