Re: cvs: php4 /ext/msession msession.c
| From: | Hartmut Holzgraefe | Date: | Sat, 22 Dec 2001 19:04:03 +0000 |
| Subject: | Re: cvs: php4 /ext/msession msession.c | ||
| References: | 1 | Groups: | php.cvs |
| Request: | Send a blank email to php-cvs+get-8773@lists.php.net to get a copy of this message | ||
Mark L. Woodward wrote:
well, if you want to have a single codebase for an extension that works with several versions of PHP then the PHP CVS is probably not the right place to maintain your code in from my understanding extensions bundled with PHP should take atvantage of internal API changes where ever possible, as it just doesn't make sense to introduce improved mechanisms, especialy in case of things like the new parameter parser that is meant to *improve* readability of source code, while mixing old and new stuff in a forrest of #ifdef directives (don't get me wrong, i'm takling about c code bc, not user level bc) if you have changes you want to apply to pre-4.1 versions then you should probably merge them in the release branches in CVS seperately for the current status of the source: if you want to stay with the old parameter passing style then please remove the ifdefs and the new style version completely the main reason for the new style function is readability and ease of use, with both old and new style encapsulated in #ifdef's whe have reached none of these goals :((- | DO NOT ever remove backward compatibility!!!! NEVER!!!! |
ok, this wasn't very clever (to much to soon), but we usualy do not use those type encoding characters in front of variable names (although there is no written rule here), and the string handling in the new parameter parsing function made me finally change this as having a 'int ihost_len;' besides 'char *szhost;' didn't look readable and intuitive to me at all- | DO NOT rename my variable names |
- | DO NOT reformat by braces, if you don't like the way I brace my code | - | too bad. I take strides to follow the format that other authors use |php4/CODING_STANDARDS, Syntax and indentation, Section 2: [2] Use K&R-style. Of course, we can't and don't want to
force anybody to use a style he or she is not used to, but,
at the very least, when you write code that goes into the core
of PHP or one of its standard modules, please maintain the K&R
style. This applies to just about everything, starting with
indentation and comment styles and up to function declaration
syntax.
(see also http://www.tuxedo.org/~esr/jargon/html/entry/indent-style.html)
- | I expect the same consideration. I use vi, not emacs. If you do not |this is not a matter of the editor used, i changed the brace style to our coding standards while i went through the file adding the prototype folding hooks and changed the parameter parsing as i was already changing more then half of the lines in the file anyway and if you wonder about the proto folding hook comments: the folding mechanism is supported by both vim and emacs, and you should add them even if your editor of choice does not support them as they are used by some tools that generate documentation and statistics from source, like the funcsummary.txt list in phpdoc or the function tables at http://zugeschaut-und-mitgebaut.de/php/ -- Hartmut Holzgraefe hartmut@six.de http://www.six.de +49-711-99091-77- | have an editor that will not muck up my braces, do not edit this | - | code. |