Web Development - Revision history

Admin: /* Code Complexity */

Admin — Thu, 28 Jul 2011 19:10:15 GMT

Code Complexity

← Older revision		Revision as of 19:10, 28 July 2011
Line 3:		Line 3:

	==Code Complexity==		==Code Complexity==
-	* Prefer to write simple code which is easy to understand. The simplest code is not necessarily the smallest, and some changes which make code larger (such as decomposing complex expressions and choosing more descriptive names) may also make it simpler. * Be willing to make size tradeoffs in favor of simplicity.	+	* Prefer to write simple code which is easy to understand. The simplest code is not necessarily the smallest, and some changes which make code larger (such as decomposing complex expressions and choosing more descriptive names) may also make it simpler.
		+	* Be willing to make size tradeoffs in favor of simplicity.
	* Prefer simple methods and functions which take a small number of parameters. Avoid methods and functions which are long and complex, or take an innumerable host of parameters. When possible, decompose monolithic, complex methods into several focused, simpler ones.		* Prefer simple methods and functions which take a small number of parameters. Avoid methods and functions which are long and complex, or take an innumerable host of parameters. When possible, decompose monolithic, complex methods into several focused, simpler ones.

Admin at 19:09, 28 July 2011

Admin — Thu, 28 Jul 2011 19:09:41 GMT

← Older revision		Revision as of 19:09, 28 July 2011
Line 1:		Line 1:
	{{Header\|1 = <h2>'''[[Development Team\|DareNET Development Wiki]]''' - {{FULLPAGENAME}}</h2>}}		{{Header\|1 = <h2>'''[[Development Team\|DareNET Development Wiki]]''' - {{FULLPAGENAME}}</h2>}}
-	This document contains practices and guidelines which apply across languages. Contributors should follow these guidelines. These guidelines are not hard-and-fast but should be followed unless there is a compelling reason to ~~deviated~~ from them.	+	This document contains practices and guidelines which apply across languages. Contributors should follow these guidelines. These guidelines are not hard-and-fast but should be followed unless there is a compelling reason to deviate from them.

	==Code Complexity==		==Code Complexity==

Admin at 08:22, 16 June 2011

Admin — Thu, 16 Jun 2011 08:22:45 GMT

← Older revision		Revision as of 08:22, 16 June 2011
Line 1:		Line 1:
	{{Header\|1 = <h2>'''[[Development Team\|DareNET Development Wiki]]''' - {{FULLPAGENAME}}</h2>}}		{{Header\|1 = <h2>'''[[Development Team\|DareNET Development Wiki]]''' - {{FULLPAGENAME}}</h2>}}
		+	This document contains practices and guidelines which apply across languages. Contributors should follow these guidelines. These guidelines are not hard-and-fast but should be followed unless there is a compelling reason to deviated from them.
		+
		+	==Code Complexity==
		+	* Prefer to write simple code which is easy to understand. The simplest code is not necessarily the smallest, and some changes which make code larger (such as decomposing complex expressions and choosing more descriptive names) may also make it simpler. * Be willing to make size tradeoffs in favor of simplicity.
		+	* Prefer simple methods and functions which take a small number of parameters. Avoid methods and functions which are long and complex, or take an innumerable host of parameters. When possible, decompose monolithic, complex methods into several focused, simpler ones.
		+
		+	Avoid putting many ideas on a single line of code.
		+
		+	For example, avoid this kind of code:
		+
		+	<pre>$category_map = array_combine(
		+	$dates,
		+	array_map(create_function('$z', 'return date("F Y", $z);'), $dates));</pre>
		+
		+	Expressing this complex transformation more simply produces more readable code:
		+
		+	<php>$category_map = array();
		+	foreach ($dates as $date) {
		+	$category_map[$date] = date('F Y', $date);
		+	}</php>
		+
		+	And, obviously, don't do this sort of thing:
		+
		+	<pre>if ($val = $some->complicatedConstruct() && !!~blarg_blarg_blarg() & $flags
		+	? HOPE_YOU_MEMORIZED == $all_the_lexical_binding_powers : <<<'Q'
		+	${hahaha}
		+	Q
		+	);</pre>
		+
		+	==Performance==
		+	* Prefer to write efficient code.
		+	* Strongly prefer to drive optimization decisions with hard data. Avoid optimizing based on intuition or rumor if you can not support it with concrete measurements.
		+	* Prefer to optimize code which is slow and runs often. Optimizing code which is fast and runs rarely is usually a waste of time, and can even be harmful if it makes that code more difficult to understand or maintain. You can determine if code is fast or slow by measuring it.
		+	* Reject performance discussions that aren't rooted in concrete data.
		+
		+	==Naming Things==
		+	* Follow language-specific conventions.
		+	* Name things unambiguously.
		+	* Choose descriptive names.
		+	* Avoid nonstandard abbreviations (common abbreviations like ID, URI and HTTP are fine).
		+	* Spell words correctly.
		+	* Use correct grammar.
		+
		+	For example, avoid these sorts of naming choices:
		+
		+	<pre>$PIE->GET_FLAVOR(); // Unconventional.
		+	$thing->doStuff(); // Ambiguous.
		+	$list->empty(); // Ambiguous -- is it isEmpty() or makeEmpty()?
		+	$e = 3; // Not descriptive.
		+	$this->updtHndlr(); // Nonstandard abbreviation.
		+	$this->chackSpulls(); // Misspelling, ungrammatical.</pre>
		+
		+	Prefer these:
		+
		+	<php>$pie->getFlavor(); // Conventional.
		+	$pie->bake(); // Unambiguous.
		+	$list->isEmpty(); // Unambiguous.
		+	$list->makeEmpty(); // Unambiguous.
		+	$edge_count = 3; // Descriptive.
		+	$this->updateHandler(); // No nonstandard abbreviations.
		+	$this->getID(); // Standard abbreviation.
		+	$this->checkSpelling(); // Correct spelling and grammar.</php>
		+
		+	==Error Handling==
		+	* Strongly prefer to detect errors.
		+	* Strongly prefer to fail fast and loudly. The maximum cost of script termination is known, bounded, and fairly small. The maximum cost of continuing script execution when errors have occurred is unknown and unbounded. This also makes APIs much easier to use and problems far easier to debug.
		+
		+	When you ignore errors, defer error handling, or degrade the severity of errors by treating them as warnings and then dismissing them, you risk dangerous behavior which may be difficult to troubleshoot:
		+
		+	<pre>exec('echo '.$data.' > file.bak'); // Bad!
		+	do_something_dangerous();
		+
		+	exec('echo '.$data.' > file.bak', $out, $err); // Also bad!
		+	if ($err) {
		+	debug_rlog("Unable to copy file!");
		+	}
		+	do_something_dangerous();</pre>
		+
		+	Instead, fail loudly:
		+
		+	<php>exec('echo '.$data.' > file.bak', $out, $err); // Better
		+	if ($err) {
		+	throw new Exception("Unable to copy file!");
		+	}
		+	do_something_dangerous();</php>
		+
		+	But the best approach is to use or write an API which simplifies condition handling and makes it easier to get right than wrong:
		+
		+	<php>execx('echo %s > file.bak', $data); // Good
		+	do_something_dangerous();
		+
		+	Filesystem::writeFile('file.bak', $data); // Best
		+	do_something_dangerous();</php>
		+
		+	==Documentation, Comments and Formatting==
		+	* Prefer to remove code by deleting it over removing it by commenting it out. It shall live forever in source control, and can be retrieved therefrom if it is ever again called upon.
		+	* In source code, use only ASCII printable characters plus space and linefeed. Do not use UTF-8 or other multibyte encodings.

	== See Also ==		== See Also ==

Admin: Replaced content with '{{Header|1 =

'''DareNET Development Wiki''' - {{FULLPAGENAME}}

}} == See Also == * [[Web Development/PHP Coding Standards|PHP Coding Standards]…'

Admin — Thu, 16 Jun 2011 08:11:59 GMT

Replaced content with '{{Header|1 = <h2>'''DareNET Development Wiki''' - {{FULLPAGENAME}}</h2>}} == See Also == * [[Web Development/PHP Coding Standards|PHP Coding Standards]…'

← Older revision		Revision as of 08:11, 16 June 2011
Line 1:		Line 1:
	{{Header\|1 = <h2>'''[[Development Team\|DareNET Development Wiki]]''' - {{FULLPAGENAME}}</h2>}}		{{Header\|1 = <h2>'''[[Development Team\|DareNET Development Wiki]]''' - {{FULLPAGENAME}}</h2>}}
-	~~This document outlines technical and style guidelines which are followed in website-darenet. Contributors should also follow these guidelines.~~
-
-	~~==Spaces, Linebreaks and Identation==~~
-	* Use one tab for each level of indentation.
-	* Use Unix linebreaks ("\n"), not MSDOS ("\r\n") or OS9 ("\r").
-	* Use K&R style braces and spacing.
-	* Put a space after control keywords like if and for.
-	* Put a space after commas in argument lists.
-	* Put a space around operators like =, <, etc.
-	* Don't put spaces after function names.
-	* Parentheses should hug their contents.
-	* Generally, prefer to wrap code at 80 columns.
-
-	~~==Case and Capitalization==~~
-	* Name variables and functions using lowercase_with_underscores.
-	* Name classes using UpperCamelCase.
-	* Name methods and properties using lowerCamelCase.
-	* Use uppercase for common acronyms like ID and HTML.
-	* Name constants using UPPERCASE.
-	* Write true, false and null in lowercase.
-
-	~~==Comments==~~
-	* Do not use "#" (shell-style) comments.
-	* Prefer "//" comments inside function and method bodies.
-
-	~~==PHP Language Style==~~
-	* Use "<?php", not the "<?" short form. Omit the closing "?>" tag.
-	* Prefer casts like (string) to casting functions like strval().
-	* Prefer type checks like $v === null to type functions like is_null().
-	* Avoid all crazy alternate forms of language constructs like "endwhile" and "<>" (acceptable in templates).
-	* Always put braces around conditional and loop blocks.
-
-	~~==PHP Language Features==~~
-	* Use PHP as a programming language, not a templating language.
-	* Avoid globals.
-	* Avoid extract().
-	* Avoid eval().
-	* Avoid variable variables.
-	* Prefer classes over functions.
-	* Prefer class constants over defines.
-	* Avoid naked class properties; instead, define accessors.
-	* Use exceptions for error conditions.
-
-	~~==Examples==~~
-	~~===if/else:===~~
-
-	~~<php>if ($some_variable > 3) {~~
-	~~// ...~~
-	~~} else if ($some_variable === null) {~~
-	~~// ...~~
-	~~} else {~~
-	~~// ...~~
-	~~}</php>~~
-	You should always put braces around the body of an if clause, even if it is only one line long. Note spaces around operators and after control statements. Do not use the "endif" construct, and write "else if" as two words.
-
-	~~===for:===~~
-
-	~~<php>for ($ii = 0; $ii < 10; $ii++) {~~
-	~~// ...~~
-	~~}</php>~~
-	~~Prefer $ii, $jj, $kk, etc., as iterators, since they're easier to pick out visually and react better to "Find Next..." in editors.~~
-
-	~~===foreach:===~~
-
-	~~<php>foreach ($map as $key => $value) {~~
-	~~// ...~~
-	~~}</php>~~
-
-	~~===switch:===~~
-
-	~~<php>switch ($value) {~~
-	~~case 1:~~
-	~~// ...~~
-	~~break;~~
-	~~case 2:~~
-	~~if ($flag) {~~
-	~~// ...~~
-	~~break;~~
-	}
-	~~break;~~
-	~~default:~~
-	~~// ...~~
-	~~break;~~
-	~~}</php>~~
-	~~break statements should be indented to block level.~~
-
-	~~===array literals:===~~
-
-	~~<php>$junk = array(~~
-	~~'nuts',~~
-	~~'bolts',~~
-	~~'refuse',~~
-	~~);</php>~~
-	~~Use a trailing comma and put the closing parenthesis on a separate line so that diffs which add elements to the array affect only one line.~~
-
-	~~===operators:===~~
-
-	~~<php>$a + $b; // Put spaces around operators.~~
-	~~$omg.$lol; // Exception: no spaces around string concatenation.~~
-	~~$arr[] = $element; // Couple [] with the array when appending.~~
-	~~$obj = new Thing(); // Always use parens.</php>~~
-
-	~~===function/method calls:===~~
-
-	~~<php>// One line~~
-	~~eject($cargo);~~
-
-	~~// Multiline~~
-	~~AbstractFireFactoryFactoryEngine::promulgateConflagrationInstance(~~
-	~~$fuel,~~
-	~~$ignition_source);</php>~~
-
-	~~===function/method definitions:===~~
-
-	~~<php>function example_function($base_value, $additional_value) {~~
-	~~return $base_value + $additional_value;~~
-	}
-
-	~~class C {~~
-	~~public static function promulgateConflagrationInstance(~~
-	~~IFuel $fuel,~~
-	~~IgnitionSource $source) {~~
-	~~// ...~~
-	}
-	~~}</php>~~
-
-	~~===class:===~~
-
-	~~<php>class Dog extends Animal {~~
-
-	~~const CIRCLES_REQUIRED_TO_LIE_DOWN = 3;~~
-
-	~~private $favoriteFood = 'dirt';~~
-
-	~~public function getFavoriteFood() {~~
-	~~return $this->favoriteFood;~~
-	}
-	~~}</php>~~

	== See Also ==		== See Also ==

		+	* [[Web Development/PHP Coding Standards\|PHP Coding Standards]]
	* [[Web Development/Javascript Coding Standards\|Javascript Coding Standards]]		* [[Web Development/Javascript Coding Standards\|Javascript Coding Standards]]

Admin at 08:04, 16 June 2011

Admin — Thu, 16 Jun 2011 08:04:02 GMT

← Older revision		Revision as of 08:04, 16 June 2011
Line 138:		Line 138:
	}		}
	}</php>		}</php>
		+
		+	== See Also ==
		+
		+	* [[Web Development/Javascript Coding Standards\|Javascript Coding Standards]]

Admin at 07:59, 16 June 2011

Admin — Thu, 16 Jun 2011 07:59:23 GMT

← Older revision		Revision as of 07:59, 16 June 2011
Line 42:		Line 42:
	* Avoid naked class properties; instead, define accessors.		* Avoid naked class properties; instead, define accessors.
	* Use exceptions for error conditions.		* Use exceptions for error conditions.
		+
		+	==Examples==
		+	===if/else:===
		+
		+	<php>if ($some_variable > 3) {
		+	// ...
		+	} else if ($some_variable === null) {
		+	// ...
		+	} else {
		+	// ...
		+	}</php>
		+	You should always put braces around the body of an if clause, even if it is only one line long. Note spaces around operators and after control statements. Do not use the "endif" construct, and write "else if" as two words.
		+
		+	===for:===
		+
		+	<php>for ($ii = 0; $ii < 10; $ii++) {
		+	// ...
		+	}</php>
		+	Prefer $ii, $jj, $kk, etc., as iterators, since they're easier to pick out visually and react better to "Find Next..." in editors.
		+
		+	===foreach:===
		+
		+	<php>foreach ($map as $key => $value) {
		+	// ...
		+	}</php>
		+
		+	===switch:===
		+
		+	<php>switch ($value) {
		+	case 1:
		+	// ...
		+	break;
		+	case 2:
		+	if ($flag) {
		+	// ...
		+	break;
		+	}
		+	break;
		+	default:
		+	// ...
		+	break;
		+	}</php>
		+	break statements should be indented to block level.
		+
		+	===array literals:===
		+
		+	<php>$junk = array(
		+	'nuts',
		+	'bolts',
		+	'refuse',
		+	);</php>
		+	Use a trailing comma and put the closing parenthesis on a separate line so that diffs which add elements to the array affect only one line.
		+
		+	===operators:===
		+
		+	<php>$a + $b; // Put spaces around operators.
		+	$omg.$lol; // Exception: no spaces around string concatenation.
		+	$arr[] = $element; // Couple [] with the array when appending.
		+	$obj = new Thing(); // Always use parens.</php>
		+
		+	===function/method calls:===
		+
		+	<php>// One line
		+	eject($cargo);
		+
		+	// Multiline
		+	AbstractFireFactoryFactoryEngine::promulgateConflagrationInstance(
		+	$fuel,
		+	$ignition_source);</php>
		+
		+	===function/method definitions:===
		+
		+	<php>function example_function($base_value, $additional_value) {
		+	return $base_value + $additional_value;
		+	}
		+
		+	class C {
		+	public static function promulgateConflagrationInstance(
		+	IFuel $fuel,
		+	IgnitionSource $source) {
		+	// ...
		+	}
		+	}</php>
		+
		+	===class:===
		+
		+	<php>class Dog extends Animal {
		+
		+	const CIRCLES_REQUIRED_TO_LIE_DOWN = 3;
		+
		+	private $favoriteFood = 'dirt';
		+
		+	public function getFavoriteFood() {
		+	return $this->favoriteFood;
		+	}
		+	}</php>

Admin at 07:54, 16 June 2011

Admin — Thu, 16 Jun 2011 07:54:14 GMT

Show changes

Admin: /* MVC */

Admin — Mon, 13 Jul 2009 05:26:32 GMT

MVC

← Older revision		Revision as of 05:26, 13 July 2009
Line 19:		Line 19:
	* The dispatcher checks the request URL (/register/channel), and hands the request to the correct controller.		* The dispatcher checks the request URL (/register/channel), and hands the request to the correct controller.
	* The controller performs application specific logic. For example, it may check to see if Joe has logged in.		* The controller performs application specific logic. For example, it may check to see if Joe has logged in.
-	* The controller also uses models to gain access to the application's data. Models usually represent database tables, but they could also represent LDAP entries, RSS feeds or files on the system. In this example, the controller uses a model to fetch a list of channels already registered to Joe from ~~a services query~~.	+	* The controller also uses models to gain access to the application's data. Models usually represent database tables, but they could also represent LDAP entries, RSS feeds or files on the system. In this example, the controller uses a model to fetch a list of channels already registered to Joe from the database, and if Joe is currently op'd in the channel he wants to register.
	* Once the controller has worked its magic on the data, it hands it to view. The view takes this data and gets it ready for presentation to the client. Views in website-darenet will mostly likely be in HTML format, but a view could just as easily be a PDF, XML document or JSON object depending on needs.		* Once the controller has worked its magic on the data, it hands it to view. The view takes this data and gets it ready for presentation to the client. Views in website-darenet will mostly likely be in HTML format, but a view could just as easily be a PDF, XML document or JSON object depending on needs.
	* Once the view has used the data from the controller to build a fully rendered view, the content of that view is returned to Joe's browser.		* Once the view has used the data from the controller to build a fully rendered view, the content of that view is returned to Joe's browser.

Admin: /* Why MVC? */

Admin — Fri, 10 Jul 2009 11:45:55 GMT

Why MVC?

← Older revision		Revision as of 11:45, 10 July 2009
Line 27:		Line 27:
	=== Why MVC? ===		=== Why MVC? ===

-	Because it is a tried and true software design pattern that turns an application into a maintainable, modular, rapidly developed package. Crafting application tasks into separate models, views and controllers will make website-darenet light on its feet. New features can then be easily added, and new faces on old features ~~are~~ a snap. The modular and separate design will also allow for developers and designers to work simultaneously, including the ability to rapidly prototype. Separation will also allow developers to make changes in one part of website-darenet without affecting others.	+	Because it is a tried and true software design pattern that turns an application into a maintainable, modular, rapidly developed package. Crafting application tasks into separate models, views and controllers will make website-darenet light on its feet. New features can then be easily added, and new faces on old features will be a snap. The modular and separate design will also allow for developers and designers to work simultaneously, including the ability to rapidly prototype. Separation will also allow developers to make changes in one part of website-darenet without affecting others.

	== Coding Standards ==		== Coding Standards ==

Admin: /* = Why MVC? */

Admin — Fri, 10 Jul 2009 11:45:24 GMT

= Why MVC?

← Older revision		Revision as of 11:45, 10 July 2009
Line 25:		Line 25:
	Almost every request to a website-darenet application will follow this basic pattern. We'll add some details later on which are specific to website-darenet, so keep this in mind as we proceed.		Almost every request to a website-darenet application will follow this basic pattern. We'll add some details later on which are specific to website-darenet, so keep this in mind as we proceed.

-	=== Why MVC? ==	+	=== Why MVC? ===

	Because it is a tried and true software design pattern that turns an application into a maintainable, modular, rapidly developed package. Crafting application tasks into separate models, views and controllers will make website-darenet light on its feet. New features can then be easily added, and new faces on old features are a snap. The modular and separate design will also allow for developers and designers to work simultaneously, including the ability to rapidly prototype. Separation will also allow developers to make changes in one part of website-darenet without affecting others.		Because it is a tried and true software design pattern that turns an application into a maintainable, modular, rapidly developed package. Crafting application tasks into separate models, views and controllers will make website-darenet light on its feet. New features can then be easily added, and new faces on old features are a snap. The modular and separate design will also allow for developers and designers to work simultaneously, including the ability to rapidly prototype. Separation will also allow developers to make changes in one part of website-darenet without affecting others.