Merged with develop and updated to new changelog.

1 files changed, 652 insertions, 0 deletions

diff --git a/user_guide_src/source/general/styleguide.rst b/user_guide_src/source/general/styleguide.rst
new file mode 100644
index 000000000..b3dc08871
--- /dev/null
+++ b/user_guide_src/source/general/styleguide.rst
@@ -0,0 +1,652 @@
+###############
+PHP Style Guide
+###############
+
+
+The following page describes the use of coding rules adhered to when
+developing CodeIgniter.
+
+.. contents:: Table of Contents
+
+File Format
+===========
+
+Files should be saved with Unicode (UTF-8) encoding. The BOM should
+*not* be used. Unlike UTF-16 and UTF-32, there's no byte order to
+indicate in a UTF-8 encoded file, and the BOM can have a negative side
+effect in PHP of sending output, preventing the application from being
+able to set its own headers. Unix line endings should be used (LF).
+
+Here is how to apply these settings in some of the more common text
+editors. Instructions for your text editor may vary; check your text
+editor's documentation.
+
+TextMate
+''''''''
+
+#. Open the Application Preferences
+#. Click Advanced, and then the "Saving" tab
+#. In "File Encoding", select "UTF-8 (recommended)"
+#. In "Line Endings", select "LF (recommended)"
+#. *Optional:* Check "Use for existing files as well" if you wish to
+   modify the line endings of files you open to your new preference.
+
+BBEdit
+''''''
+
+#. Open the Application Preferences
+#. Select "Text Encodings" on the left.
+#. In "Default text encoding for new documents", select "Unicode (UTF-8,
+   no BOM)"
+#. *Optional:* In "If file's encoding can't be guessed, use", select
+   "Unicode (UTF-8, no BOM)"
+#. Select "Text Files" on the left.
+#. In "Default line breaks", select "Mac OS X and Unix (LF)"
+
+PHP Closing Tag
+===============
+
+The PHP closing tag on a PHP document **?>** is optional to the PHP
+parser. However, if used, any whitespace following the closing tag,
+whether introduced by the developer, user, or an FTP application, can
+cause unwanted output, PHP errors, or if the latter are suppressed,
+blank pages. For this reason, all PHP files should **OMIT** the closing
+PHP tag, and instead use a comment block to mark the end of file and
+it's location relative to the application root. This allows you to still
+identify a file as being complete and not truncated.
+
+**INCORRECT**::
+
+	<?php
+
+	echo "Here's my code!";
+
+	?>
+
+**CORRECT**::
+
+	<?php
+
+	echo "Here's my code!";
+
+	/* End of file myfile.php */
+	/* Location: ./system/modules/mymodule/myfile.php */
+
+Class and Method Naming
+=======================
+
+Class names should always start with an uppercase letter. Multiple words
+should be separated with an underscore, and not CamelCased. All other
+class methods should be entirely lowercased and named to clearly
+indicate their function, preferably including a verb. Try to avoid
+overly long and verbose names.
+
+**INCORRECT**::
+
+	class superclass
+	class SuperClass
+
+**CORRECT**::
+
+	class Super_class
+
+::
+
+	class Super_class {
+
+		function __construct()
+		{
+
+		}
+	}
+
+Examples of improper and proper method naming:
+
+**INCORRECT**::
+
+	function fileproperties()		// not descriptive and needs underscore separator
+	function fileProperties()		// not descriptive and uses CamelCase
+	function getfileproperties()		// Better!  But still missing underscore separator
+	function getFileProperties()		// uses CamelCase
+	function get_the_file_properties_from_the_file()	// wordy
+
+**CORRECT**::
+
+	function get_file_properties()	// descriptive, underscore separator, and all lowercase letters
+
+Variable Names
+==============
+
+The guidelines for variable naming is very similar to that used for
+class methods. Namely, variables should contain only lowercase letters,
+use underscore separators, and be reasonably named to indicate their
+purpose and contents. Very short, non-word variables should only be used
+as iterators in for() loops.
+
+**INCORRECT**::
+
+	$j = 'foo';		// single letter variables should only be used in for() loops
+	$Str			// contains uppercase letters
+	$bufferedText		// uses CamelCasing, and could be shortened without losing semantic meaning
+	$groupid		// multiple words, needs underscore separator
+	$name_of_last_city_used	// too long
+
+**CORRECT**::
+
+	for ($j = 0; $j < 10; $j++)
+	$str
+	$buffer
+	$group_id
+	$last_city
+
+Commenting
+==========
+
+In general, code should be commented prolifically. It not only helps
+describe the flow and intent of the code for less experienced
+programmers, but can prove invaluable when returning to your own code
+months down the line. There is not a required format for comments, but
+the following are recommended.
+
+`DocBlock <http://manual.phpdoc.org/HTMLSmartyConverter/HandS/phpDocumentor/tutorial_phpDocumentor.howto.pkg.html#basics.docblock>`_
+style comments preceding class and method declarations so they can be
+picked up by IDEs::
+
+	/**
+	 * Super Class
+	 *
+	 * @package	Package Name
+	 * @subpackage	Subpackage
+	 * @category	Category
+	 * @author	Author Name
+	 * @link	http://example.com
+	 */
+	class Super_class {
+
+::
+
+	/**
+	 * Encodes string for use in XML
+	 *
+	 * @access	public
+	 * @param	string
+	 * @return	string
+	 */
+	function xml_encode($str)
+
+Use single line comments within code, leaving a blank line between large
+comment blocks and code.
+
+::
+
+	// break up the string by newlines
+	$parts = explode("\n", $str);
+
+	// A longer comment that needs to give greater detail on what is
+	// occurring and why can use multiple single-line comments.  Try to
+	// keep the width reasonable, around 70 characters is the easiest to
+	// read.  Don't hesitate to link to permanent external resources
+	// that may provide greater detail:
+	//
+	// http://example.com/information_about_something/in_particular/
+
+	$parts = $this->foo($parts);
+
+Constants
+=========
+
+Constants follow the same guidelines as do variables, except constants
+should always be fully uppercase. *Always use CodeIgniter constants when
+appropriate, i.e. SLASH, LD, RD, PATH_CACHE, etc.*
+
+**INCORRECT**::
+
+	myConstant	// missing underscore separator and not fully uppercase
+	N		// no single-letter constants
+	S_C_VER		// not descriptive
+	$str = str_replace('{foo}', 'bar', $str);	// should use LD and RD constants
+
+**CORRECT**::
+
+	MY_CONSTANT
+	NEWLINE
+	SUPER_CLASS_VERSION
+	$str = str_replace(LD.'foo'.RD, 'bar', $str);
+
+TRUE, FALSE, and NULL
+=====================
+
+**TRUE**, **FALSE**, and **NULL** keywords should always be fully
+uppercase.
+
+**INCORRECT**::
+
+	if ($foo == true)
+	$bar = false;
+	function foo($bar = null)
+
+**CORRECT**::
+
+	if ($foo == TRUE)
+	$bar = FALSE;
+	function foo($bar = NULL)
+
+Logical Operators
+=================
+
+Use of **\|\|** is discouraged as its clarity on some output devices is
+low (looking like the number 11 for instance). **&&** is preferred over
+**AND** but either are acceptable, and a space should always precede and
+follow **!**.
+
+**INCORRECT**::
+
+	if ($foo || $bar)
+	if ($foo AND $bar)  // okay but not recommended for common syntax highlighting applications
+	if (!$foo)
+	if (! is_array($foo))
+
+**CORRECT**::
+
+	if ($foo OR $bar)
+	if ($foo && $bar) // recommended
+	if ( ! $foo)
+	if ( ! is_array($foo))
+	
+
+Comparing Return Values and Typecasting
+=======================================
+
+Some PHP functions return FALSE on failure, but may also have a valid
+return value of "" or 0, which would evaluate to FALSE in loose
+comparisons. Be explicit by comparing the variable type when using these
+return values in conditionals to ensure the return value is indeed what
+you expect, and not a value that has an equivalent loose-type
+evaluation.
+
+Use the same stringency in returning and checking your own variables.
+Use **===** and **!==** as necessary.
+
+**INCORRECT**::
+
+	// If 'foo' is at the beginning of the string, strpos will return a 0,
+	// resulting in this conditional evaluating as TRUE
+	if (strpos($str, 'foo') == FALSE)
+
+**CORRECT**::
+
+	if (strpos($str, 'foo') === FALSE)
+
+**INCORRECT**::
+
+	function build_string($str = "")
+	{
+		if ($str == "")	// uh-oh!  What if FALSE or the integer 0 is passed as an argument?
+		{
+
+		}
+	}
+
+**CORRECT**::
+
+	function build_string($str = "")
+	{
+		if ($str === "")
+		{
+
+		}
+	}
+
+
+See also information regarding
+`typecasting <http://us3.php.net/manual/en/language.types.type-juggling.php#language.types.typecasting>`_,
+which can be quite useful. Typecasting has a slightly different effect
+which may be desirable. When casting a variable as a string, for
+instance, NULL and boolean FALSE variables become empty strings, 0 (and
+other numbers) become strings of digits, and boolean TRUE becomes "1"::
+
+	$str = (string) $str; // cast $str as a string
+
+Debugging Code
+==============
+
+No debugging code can be left in place for submitted add-ons unless it
+is commented out, i.e. no var_dump(), print_r(), die(), and exit()
+calls that were used while creating the add-on, unless they are
+commented out.
+
+::
+
+	// print_r($foo);
+
+Whitespace in Files
+===================
+
+No whitespace can precede the opening PHP tag or follow the closing PHP
+tag. Output is buffered, so whitespace in your files can cause output to
+begin before CodeIgniter outputs its content, leading to errors and an
+inability for CodeIgniter to send proper headers. In the examples below,
+select the text with your mouse to reveal the incorrect whitespace.
+
+
+Compatibility
+=============
+
+Unless specifically mentioned in your add-on's documentation, all code
+must be compatible with PHP version 5.1+. Additionally, do not use PHP
+functions that require non-default libraries to be installed unless your
+code contains an alternative method when the function is not available,
+or you implicitly document that your add-on requires said PHP libraries.
+
+Class and File Names using Common Words
+=======================================
+
+When your class or filename is a common word, or might quite likely be
+identically named in another PHP script, provide a unique prefix to help
+prevent collision. Always realize that your end users may be running
+other add-ons or third party PHP scripts. Choose a prefix that is unique
+to your identity as a developer or company.
+
+**INCORRECT**::
+
+	class Email		pi.email.php
+	class Xml		ext.xml.php
+	class Import	mod.import.php
+
+**CORRECT**::
+
+	class Pre_email		pi.pre_email.php
+	class Pre_xml		ext.pre_xml.php
+	class Pre_import	mod.pre_import.php
+
+Database Table Names
+====================
+
+Any tables that your add-on might use must use the 'exp\_' prefix,
+followed by a prefix uniquely identifying you as the developer or
+company, and then a short descriptive table name. You do not need to be
+concerned about the database prefix being used on the user's
+installation, as CodeIgniter's database class will automatically convert
+'exp\_' to what is actually being used.
+
+**INCORRECT**::
+
+	email_addresses		// missing both prefixes
+	pre_email_addresses	// missing exp_ prefix
+	exp_email_addresses	// missing unique prefix
+
+**CORRECT**::
+
+	exp_pre_email_addresses
+
+.. note:: Be mindful that MySQL has a limit of 64 characters for table
+	names. This should not be an issue as table names that would exceed this
+	would likely have unreasonable names. For instance, the following table
+	name exceeds this limitation by one character. Silly, no?
+	**exp_pre_email_addresses_of_registered_users_in_seattle_washington**
+
+One File per Class
+==================
+
+Use separate files for each class your add-on uses, unless the classes
+are *closely related*. An example of CodeIgniter files that contains
+multiple classes is the Database class file, which contains both the DB
+class and the DB_Cache class, and the Magpie plugin, which contains
+both the Magpie and Snoopy classes.
+
+Whitespace
+==========
+
+Use tabs for whitespace in your code, not spaces. This may seem like a
+small thing, but using tabs instead of whitespace allows the developer
+looking at your code to have indentation at levels that they prefer and
+customize in whatever application they use. And as a side benefit, it
+results in (slightly) more compact files, storing one tab character
+versus, say, four space characters.
+
+Line Breaks
+===========
+
+Files must be saved with Unix line breaks. This is more of an issue for
+developers who work in Windows, but in any case ensure that your text
+editor is setup to save files with Unix line breaks.
+
+Code Indenting
+==============
+
+Use Allman style indenting. With the exception of Class declarations,
+braces are always placed on a line by themselves, and indented at the
+same level as the control statement that "owns" them.
+
+**INCORRECT**::
+
+	function foo($bar) {
+		// ...
+	}
+
+	foreach ($arr as $key => $val) {
+		// ...
+	}
+
+	if ($foo == $bar) {
+		// ...
+	} else {
+		// ...
+	}
+
+	for ($i = 0; $i < 10; $i++)
+		{
+		for ($j = 0; $j < 10; $j++)
+			{
+			// ...
+			}
+		}
+
+**CORRECT**::
+
+	function foo($bar)
+	{
+		// ...
+	}
+
+	foreach ($arr as $key => $val)
+	{
+		// ...
+	}
+
+	if ($foo == $bar)
+	{
+		// ...
+	}
+	else
+	{
+		// ...
+	}
+
+	for ($i = 0; $i < 10; $i++)
+	{
+		for ($j = 0; $j < 10; $j++)
+		{
+			// ...
+		}
+	}
+
+Bracket and Parenthetic Spacing
+===============================
+
+In general, parenthesis and brackets should not use any additional
+spaces. The exception is that a space should always follow PHP control
+structures that accept arguments with parenthesis (declare, do-while,
+elseif, for, foreach, if, switch, while), to help distinguish them from
+functions and increase readability.
+
+**INCORRECT**::
+
+	$arr[ $foo ] = 'foo';
+
+**CORRECT**::
+
+	$arr[$foo] = 'foo'; // no spaces around array keys
+
+**INCORRECT**::
+
+	function foo ( $bar )
+	{
+
+	}
+
+**CORRECT**::
+
+	function foo($bar) // no spaces around parenthesis in function declarations
+	{
+
+	}
+
+**INCORRECT**::
+
+	foreach( $query->result() as $row )
+
+**CORRECT**::
+
+	foreach ($query->result() as $row) // single space following PHP control structures, but not in interior parenthesis
+
+Localized Text
+==============
+
+Any text that is output in the control panel should use language
+variables in your lang file to allow localization.
+
+**INCORRECT**::
+
+	return "Invalid Selection";
+
+**CORRECT**::
+
+	return $this->lang->line('invalid_selection');
+
+Private Methods and Variables
+=============================
+
+Methods and variables that are only accessed internally by your class,
+such as utility and helper functions that your public methods use for
+code abstraction, should be prefixed with an underscore.
+
+::
+
+	convert_text()		// public method
+	_convert_text()		// private method
+
+PHP Errors
+==========
+
+Code must run error free and not rely on warnings and notices to be
+hidden to meet this requirement. For instance, never access a variable
+that you did not set yourself (such as $_POST array keys) without first
+checking to see that it isset().
+
+Make sure that while developing your add-on, error reporting is enabled
+for ALL users, and that display_errors is enabled in the PHP
+environment. You can check this setting with::
+
+	if (ini_get('display_errors') == 1)
+	{
+		exit "Enabled";
+	}
+
+On some servers where display_errors is disabled, and you do not have
+the ability to change this in the php.ini, you can often enable it with::
+
+	ini_set('display_errors', 1);
+
+**NOTE:** Setting the
+`display_errors <http://us.php.net/manual/en/ref.errorfunc.php#ini.display-errors>`_
+setting with ini_set() at runtime is not identical to having it enabled
+in the PHP environment. Namely, it will not have any effect if the
+script has fatal errors
+
+Short Open Tags
+===============
+
+Always use full PHP opening tags, in case a server does not have
+short_open_tag enabled.
+
+**INCORRECT**::
+
+	<? echo $foo; ?>
+
+	<?=$foo?>
+
+**CORRECT**::
+
+	<?php echo $foo; ?>
+
+One Statement Per Line
+======================
+
+Never combine statements on one line.
+
+**INCORRECT**::
+
+	$foo = 'this'; $bar = 'that'; $bat = str_replace($foo, $bar, $bag);
+
+**CORRECT**::
+
+	$foo = 'this';
+	$bar = 'that';
+	$bat = str_replace($foo, $bar, $bag);
+
+Strings
+=======
+
+Always use single quoted strings unless you need variables parsed, and
+in cases where you do need variables parsed, use braces to prevent
+greedy token parsing. You may also use double-quoted strings if the
+string contains single quotes, so you do not have to use escape
+characters.
+
+**INCORRECT**::
+
+	"My String"					// no variable parsing, so no use for double quotes
+	"My string $foo"				// needs braces
+	'SELECT foo FROM bar WHERE baz = \'bag\''	// ugly
+
+**CORRECT**::
+
+	'My String'
+	"My string {$foo}"
+	"SELECT foo FROM bar WHERE baz = 'bag'"
+
+SQL Queries
+===========
+
+MySQL keywords are always capitalized: SELECT, INSERT, UPDATE, WHERE,
+AS, JOIN, ON, IN, etc.
+
+Break up long queries into multiple lines for legibility, preferably
+breaking for each clause.
+
+**INCORRECT**::
+
+	// keywords are lowercase and query is too long for
+	// a single line (... indicates continuation of line)
+	$query = $this->db->query("select foo, bar, baz, foofoo, foobar as raboof, foobaz from exp_pre_email_addresses
+	...where foo != 'oof' and baz != 'zab' order by foobaz limit 5, 100");
+
+**CORRECT**::
+
+	$query = $this->db->query("SELECT foo, bar, baz, foofoo, foobar AS raboof, foobaz
+					FROM exp_pre_email_addresses
+					WHERE foo != 'oof'
+					AND baz != 'zab'
+					ORDER BY foobaz
+					LIMIT 5, 100");
+
+Default Function Arguments
+==========================
+
+Whenever appropriate, provide function argument defaults, which helps
+prevent PHP errors with mistaken calls and provides common fallback
+values which can save a few lines of code. Example::
+
+	function foo($bar = '', $baz = FALSE)
+