Re: [Apc-aa-coders] Coding Standards

[Mitra <mi...@mi...>]

OK so while we are making coding standards ...

Outside of a class definition it is best not to access its member 
variables directly, so for example don't do
auth->auth[$uid]
The reason is that it makes it hard to change the internal data 
representation, which is a part of the reason behind using classes.

Instead create a function in the class that returns what you are 
looking for, and think ahead - i.e. the worst thing you can do is 
just to create access functiosn like "function get_auth()". This just 
adds overhead with no useful encapsulation, instead create useful 
functions like "function is_authorised($uid)"

I suggest these coding standards should be in the doc directory and 
pointed to in the FAQ.
- Mitra


At 10:53 PM +0100 18/1/03, Honza Malik wrote:
>Hello,
>
>    I think now is the time to define some coding standards for
>ActionApps. It help us to have the code as readable as possible for
>everyone. Most of the following rules comes from php PEAR standard:
>http://pear.php.net/manual/en/standards.php
>Most important rules on tne top:
>
>
>- use UNIX end of lines (use \n and never windows \r\n)
>      If we mix both modes, the CVS diffs are unusefull
>
>- Indent 4 spaces, with no tabs
>      Do not use Tabs or use 'insert Tabs as spaces' option of your text
>      editor. Most of the editors (like Jedit or HomeSite) allows it.
>      Then the code will look good in any editor.
>
>- use <?php open tag
>      Do not use any other shorted version like <?, .. There are some
>      problems on some Apache configurations with <?...
>
>- comments should follow phpDoc standard
>      See http://phpdocu.sourceforge.net/
>      Use /*  */ and // for comments, not #
>
>- control structures should look like
>      if ((condition1) || (condition2)) {
>          commands;
>      } else {
>          commands;
>      }
>      Open brace at the end of line
>      if, while, ... separated by space (it is not function call)
>
>- function($var1, $var2=true)
>      No space between function name and open brace allow us easier find
>      the function in the code
>
>- 80 characters wide
>      Try to write the code 80 characters wide, if possible
>
>- quote strings in indexes
>      Allways qoute strings like 'name' in $arr['name'] or $db->f('name')
>      although current PHP do not need it
>
>- use $_GET, $POST, and $_SERVER
>      Use mentioned superglobal arrays to access variables from forms ...
>
>- use return true; instead of return(true);
>      Return is the statement, not a function
>
>- When you commiting changes into CVS, allways update CHANGES file and
>   send a note to apc...@so...
>
>- Document new feature in the FAQ (http://apc-aa.sourceforge.net/faq/)
>   and in the code
>
>- If it is possible, create an example of new feature on Sourceforge
>   installation of AA
>
>- If you changing database structure (adding table, ...), you should
>   update doc/aadb.sql as well as sqlupdate.php3 script
>
>- Before you are going to code some new feature, let us know about,
>   please (apc...@so...)
>
>
>-------------
>I know the current code do not strictly follows mentioned rules, but
>from this time it will ....... hopefully
>
>     Honza
>
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
>allow you to extend the highest allowed 128 bit encryption to all your
>clients even if they use browsers that are limited to 40 bit encryption.
>Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
>_______________________________________________
>Apc-aa-coders mailing list
>Apc...@li...
>https://lists.sourceforge.net/lists/listinfo/apc-aa-coders


-- 
Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
02-6684-8096  or 0414-648-0722 

Life is a Mystery to be Lived, not a Problem to be Solved