PHP Coding Standards: Difference between revisions

From Wikipedia of the Dark Brotherhood, an online Star Wars Club
m (→‎Database Abstraction: clean up, typos fixed: ie. → i.e.)
(Marking obsolete)
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
{{eras|real}}
{{Obsolete}}
<center>
<center>
<table border="1">
<table border="1">
Line 103: Line 103:
*Registry database shortcuts should be defined centrally in the tools class.
*Registry database shortcuts should be defined centrally in the tools class.


[[Category: DJB Info]]
[[Category:Coding Standards]]
[[Category:Coding Standards]]

Latest revision as of 00:45, 21 April 2024

You must unlearn what you have learned.
This article contains obsolete data. It reflects a Dark Brotherhood policy, position, or object that has been removed or replaced. It is preserved here for historical purposes only and should not be used/referenced.
Dark Brotherhood Coding Standards
Coding Standards and Practices
ASP Coding Standards CSS Coding Standards Database Standards
HTML Coding Standards JavaScript Coding Standards PHP Coding Standards


General

  • All associative arrays should use single quotes around element names.
  • All global variables should be referred to using the $GLOBALS['VAR_NAME'] syntax.
  • Super global variables should be used as opposed to relying on register_globals being on
  • A given include should not be done repeatedly in the same script.
  • A closing PHP tag (?>) at the end of the file is extraneous and should be removed to prevent unexpected whitespace output. See: Zend File Formatting Standards
  • Hard coded paths should be avoided whenever possible.
  • Function and method names should be all lowercase, with underscores separating words: my_function() rather than myFunction().
  • Any operation that is being done repeatedly in the application should be functionalized. Functions or Object-Oriented PHP should be used whenever possible.
  • Passwords that appear in PHP code must be base64 encoded, then decoded when utilized.
  • API classes should be written in preference to functions in the global scope.
  • When possible, write code in distinct, testable chunks. (See Unit Testing below.)

Global Variables

  • Global variables should be all uppercase and use $GLOBALS where appropriate. Ex. $GLOBALS['MY_GLOBAL_VAR']
  • Local variables should NEVER be in all uppercase.

The following global variables should be defined for every script:

Variable Purpose Example
$GLOBALS['BASE_DIR'] This is the base directory for the application and should not be hard coded if possible. Used by PSUSmarty and PSUTemplate to create a unique template cache directory. /var/htdocs/myapp/subdir

dirname(__FILE__)

$GLOBALS['BASE_URL'] This is the base URL for the application and should be a full relative path. /webapp/subdir/
$GLOBALS['TEMPLATES'] Full path to your application's templates directory. Required if using DJBTemplate. $GLOBALS['BASE_DIR'] . '/templates';
$GLOBALS['TITLE'] Application title, as displayed in templates by DJBTemplate. Required if using DJBTemplate. "APE"

Templating

  • All files that include XHTML and conditional PHP must be separated into a .html and a .tpl file using Smarty. Conditional PHP and HTML code should never exist in the same file.
    • Exception: high traffic content may follow other rendering guidelines due to performance.

Database Abstraction

  • Database abstraction with ADOdb should be used when connecting to databases.
  • Database connections should be opened using the registry, i.e. tools::db('djb').
  • Registry database shortcuts should be defined centrally in the tools class.