CS:naming

Files
For our purposes, consider that files are split into six categories:

* Model: The basic needs and resources of an application; majority of the logic. * Equivalence: A desktop computer, containing a hard drive with data.

* View: The presentation layer (though not an HTML template) of an application. * Equivalence: The monitor of a desktop computer.

* MVC: The interactive component. * Equivalence: You, typing on the analogous computer.

* MVC: The "look and feel." * Equivalence: Your hairstyle and clothes.

* Documentation: Small, simple, redistributable notes. * README, INSTALL, CHANGELOG, LICENSE, et cetera.

* Package Support Files: The "et cetera." * SQL Schemas, CSS, JavaScript, media, et cetera.

Then, consider the following heirarchy: * /   * index.php * includes/ * config.php * Classes/ * User.php * Communications.php * Communications/ * Communications_Mail.php * Error.php * modules/ * login.php * sendemail.php * confirmation.php * templates/ * home.tpl * form.tpl * login.tpl * thanks.tpl

Note the difference in case first. Files in the root are what are accessed via the web, and should always be lower-case. The majority of directories are also all lower-case, as are the files within them. The difference is the classes and packages.

The Classes directory should begin with a capital C, and all files and subdirectories therein should begin titles with a capital letter. In the case of a package or library, the library directory name should begin with a capital. Files within the package directory must then be preceded by the library name and an underscore, followed by the name of the individual class. In all cases, the name of the class will be the name of the file.

Referring to the hierarchy example above, the following example code can be presumed:

  <?php class Communications_Mail extends Communications { /**    * Specifically email communications code, * inheriting from the general communications layer. */

/**    * The from address to use. *     * @var string */   var $from; /**    * Email sends to here. *     * @var string */   var $to = 'daniel.brown@parasane.net'; /**    * Email subject. *     * @var string */   var $subject; /**    * Email body. *     * @var string */   var $body; /**    * Sends an email. *     * Sends an email using the defined email methods inherited * from the Communications class. *     * Notes: * Accepts no parameters. Uses class variables instantiated * in controller. *     * Caveats: * Will probably be used to send tons of SPAM, because I    * don't ever have anything good to say anyway. *     * Usage: * send *     * Returns: * Boolean true on success. * Throws exception on failure. */   public function send { // Headers $headers = "From: ".$this->from."\r\n"; $headers .= "X-Mailer: PHP/".phpversion."\r\n"; if (mail($this->to,$this->subject,$this->body,$headers,'-f'.$this->from)) { return true; } else { throw new Exception("Unable to send email!"); }   } }

 from = 'danbrown@php.net'; $Mail->subject = 'Pseudocode Example from Love Machine CS Wiki Page'; $Mail->body <<send; } catch (Exception $e) { Error::critical("Exception near line #".__LINE__.": ".$e->getMessage); }

// Continue processing....

Classes
Class definitions should use the camel case style, and use underscores for separation between package class and modules. Braces style should follow as well the Java coding style and go in the same line as the declaration with a space as separator. The name of the classes should be short and self descriptive, so that by only reading the class name you would know how to use it, the same applies to the class member functions.

Functions
Function names should start with lowercase, and camel case style afterwards. Use common sense and write names that describe what the function does in a imperative way, for both class members or standalone functions.

Variables
Variable names should be simple and descriptive for improved code readability, and word separation in variables is preferred to use the underscore style Using camel case style will not be penalized but the first style is preferred. The important rule is not to mix both in the same piece of code for that is prone to cause confusion.

e.g. **Good**

e.g. **Bad**

Constants
Constants should be defined using uppercase words separated with underscores, and again please use descriptive names.

Namespaces
Namespaces names should begin with an uppercase letter, and use camel case style. Use names that will easily express the purpose of the code encapsulated in them.