Re: Coding standard proposal

Dmitri, Glad to hear you're using PEAR! A few days ago, I asked on IRC about variable naming standards. The manual has/had a section on method and member variable names at http://pear.php.net/manual/en/standards.naming.php. The standard is to use $camelCase. Descriptive variable names are good programming practise and I agree they should be used. As for putting the variable type in the variable name, I think this is a bad idea. - What if you need to change the type of a variable to fix a bug? If the typed variable name is part of the public or protected API you'd then introduce either inconsistency or API breakage. - PHP is loosely typed so the parameter value $intValue could be the string '13'. Variable names should be descriptive enough that the type would be obvious. - Making humans update all variable names if they make an internal change to a variable type will lead to mistakes. Computers already manage types for us. - you can already use type hinting for arrays and objects. Your idea of updating phpDocumentor to use typed variable names for generating documentation is interesting but think it is outweighed by my points above. Mike On Sat, 2008-19-04 at 10:17 -0400, Dmitri wrote: > Hello! > I am not a pear developer, just a heavy user of PEAR classes > > I think it will be a good idea to add some simple coding standard for > variable naming. > > hint a variable type in the first 2-4 letters of the variable > prefixes: > string: str > array: arr > object: obj > integer: int > boolean: bool > handle: hdl > function: fn > > Follow the prefix with the CamelCase name of the variable, which should > be descriptive > For example $arrFormData or $strFileName or $boolNotify > > > This will make it a lot easier to understand the code. Also > phpDocumentor code can be modified to make use of this naming convention > to automatically guess the type of variable, > for example if it sees a function like this fnParseEmail($strRawMessage, > $boolExtractAttachment = false) > it can automatically add this to doc block > @param string $strRawMessage > @param boolean $boolExtractAttachment > > I think adapting this standard will further improve the quality of pear > classes and make it easier for users of these classes to understand the > intentions of the developer of the class. > > > > > -- > > Open Source ALL content management > with streaming video > http://wiki.sharedlog.com > > >