Most of your guidelines match with our practices. Here are some comments.
On Sat, 28 Apr 2001, Steven Haryanto wrote:
> 0.1 We are writing PHP4 application here, not PHP3, nor Perl, Python, etc.
> So use PHP idioms.
Same here.
> 0.3 Consistency matters.
>
> 0.4 Standards is important.
>
> 0.5 Readability matters. Especially since the code will be touched by
> several developers.
Agreed.
> 1.0 Enclosing PHP code
>
> Always use <?php ?>.
We use <? ?> here. But sticking to a single method is fine.
> 1.4 Whitespaces
>
> - No whitespace after function or method name. Example:
>
> exit()
We also use this. But I have seen others using spaces. Even there are some
examples in php-manual with spaces (e.g. array_shift).
> - Whitespace in expressions are usually not necessary. But use them when
> they enhance readability.
>
> $a = $b + $c*(5*time());
We prefer
$a = $b + $c * (5 * time());
> 1.5 Function names
>
> Function names are not case sensitive in PHP. Use the all-lowercase
> notation.
Since most of us come from good old C regime, this should be the most
readable form.
> 1.6 Quotes
>
> Use whichever ones you like. But if you can use '' for simple strings,
> and "" only if you need interpolation.
This should _very_slightly_ improve performance too.
> 2.2 Debugging comments.
>
> # is used to comment out certain parts of a code during debugging.
We always use /* */ because we filter php files through a stripper which
also removes newlines before sent to the real server.
> 2.3 Documentation comments.
We use the style used in the linux kernel.
> 3. Naming
We use all lowercase for variables like "variable", "my_name". Also, in
html forms, analogous variables take the form "variable", "myName".
> 4. File organization
We use WML (website meta language - www.engelschall.com/sw/wml/) with make
to produce single php files and do _not_ use the include feature of php.
Also, we have written scripts that creates diff files between releases.
> 5. Testing
We have few files that are included (WML include and not PHP include) from
every file. The production version and testing versions have different
sets of them, and make rebuilds the site selectively.
> 6. Creating documentation
We use tex, and we are planning to go for texinfo.
> 7. Database programming
We use _only_ postgresql, because of its feature richness and performance.
So no problem of abstraction.
> 8. Error handling
>
> ...
>
> 8.2 Reporting error
We use the guidelines given in "GNU Coding Standards" by Richard Stallman.
> 9. Portability
We are expecting portability over POSIX like systems.
Anuradha
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
