diff options
| author | Igor Wiedler <igor@wiedler.ch> | 2012-06-27 14:47:13 +0200 |
|---|---|---|
| committer | Igor Wiedler <igor@wiedler.ch> | 2012-06-27 14:47:13 +0200 |
| commit | 1b3cb68c2fdc5224367ddc3a9414c323c7d5bb7f (patch) | |
| tree | 62898f931c8b82a198a4c0dc7bf4237c7b4e9077 /phpBB/docs/coding-guidelines.html | |
| parent | f273ab16ae68d15832832e2b2c98a3b99c966c97 (diff) | |
| parent | 85ea062a0536edc46ea1a8893201777f8137e41e (diff) | |
| download | forums-1b3cb68c2fdc5224367ddc3a9414c323c7d5bb7f.tar forums-1b3cb68c2fdc5224367ddc3a9414c323c7d5bb7f.tar.gz forums-1b3cb68c2fdc5224367ddc3a9414c323c7d5bb7f.tar.bz2 forums-1b3cb68c2fdc5224367ddc3a9414c323c7d5bb7f.tar.xz forums-1b3cb68c2fdc5224367ddc3a9414c323c7d5bb7f.zip | |
Merge remote-tracking branch 'upstream/develop' into feature/avatars
* upstream/develop: (255 commits)
[ticket/10935] Limit number of PM rules per user to 5000
[ticket/10801] Fixed quickmod tools.
[ticket/9551] uncomment line and change length to 255
[ticket/10925] Clarify installation requirements for SQLite
[ticket/10938] Serve subforum listing on forumlist from template loop
[ticket/10640] Change subject length in mcp in subsilver
[ticket/10640] Change subject length in MCP
[ticket/10640] Do not change default value of truncate_string()
[ticket/10640] Change maximum subject length
[ticket/10936] remove PCRE and mbstring support check
[ticket/10936] fix language key
[ticket/10829] Delete T_STYLESHEET_NAME - no longer used.
[ticket/10829] $style_name -> $style_path in style class.
[ticket/10743] Renaming user->theme
[ticket/10743] Changing obtain_cfg_items
[ticket/10882] Fix test name - oops.
[ticket/10931] Apply strtolower() correctly, i.e. not on false.
[ticket/10931] Also test get_bytes() and get_string() with false.
[ticket/10931] Make to_numeric function globally available.
[ticket/10932] Use included composer.phar in build process
...
Conflicts:
phpBB/includes/mcp/mcp_warn.php
phpBB/install/database_update.php
phpBB/styles/prosilver/template/ucp_avatar_options.html
Diffstat (limited to 'phpBB/docs/coding-guidelines.html')
| -rw-r--r-- | phpBB/docs/coding-guidelines.html | 40 |
1 files changed, 35 insertions, 5 deletions
diff --git a/phpBB/docs/coding-guidelines.html b/phpBB/docs/coding-guidelines.html index 6d428916c7..ae4655e094 100644 --- a/phpBB/docs/coding-guidelines.html +++ b/phpBB/docs/coding-guidelines.html @@ -295,11 +295,17 @@ PHPBB_QA (Set board to QA-Mode, which means the updater also c <p>We will not be using any form of hungarian notation in our naming conventions. Many of us believe that hungarian naming is one of the primary code obfuscation techniques currently in use.</p> <h4>Variable Names:</h4> - <p>Variable names should be in all lowercase, with words separated by an underscore, example:</p> + <p>In PHP, variable names should be in all lowercase, with words separated by an underscore, example:</p> <div class="indent"> <p><code>$current_user</code> is right, but <code>$currentuser</code> and <code> $currentUser</code> are not.</p> </div> + + <p>In JavaScript, variable names should use camel case:</p> + + <div class="indent"> + <p><code>currentUser</code> is right, but <code>currentuser</code> and <code>current_user</code> are not.</p> + </div> <p>Names should be descriptive, but concise. We don't want huge sentences as our variable names, but typing an extra couple of characters is always better than wondering what exactly a certain variable is for. </p> @@ -317,7 +323,7 @@ for ($i = 0; $i < $outer_size; $i++) </pre></div> <h4>Function Names:</h4> - <p>Functions should also be named descriptively. We're not programming in C here, we don't want to write functions called things like "stristr()". Again, all lower-case names with words separated by a single underscore character. Function names should preferably have a verb in them somewhere. Good function names are <code>print_login_status()</code>, <code>get_user_data()</code>, etc. </p> + <p>Functions should also be named descriptively. We're not programming in C here, we don't want to write functions called things like "stristr()". Again, all lower-case names with words separated by a single underscore character in PHP, and camel caps in JavaScript. Function names should preferably have a verb in them somewhere. Good function names are <code>print_login_status()</code>, <code>get_user_data()</code>, etc. Constructor functions in JavaScript should begin with a capital letter.</p> <h4>Function Arguments:</h4> <p>Arguments are subject to the same guidelines as variable names. We don't want a bunch of functions like: <code>do_stuff($a, $b, $c)</code>. In most cases, we'd like to be able to tell how to use a function by just looking at its declaration. </p> @@ -356,7 +362,7 @@ phpbb_dir_subdir_class_name - includes/dir/subdir/class_name.php <p>The basic philosophy here is to not hurt code clarity for the sake of laziness. This has to be balanced by a little bit of common sense, though; <code>print_login_status_for_a_given_user()</code> goes too far, for example -- that function would be better named <code>print_user_login_status()</code>, or just <code>print_login_status()</code>.</p> <h4>Special Namings: </h4> - <p>For all emoticons use the term <code>smiley</code> in singular and <code>smilies</code> in plural.</p> + <p>For all emoticons use the term <code>smiley</code> in singular and <code>smilies</code> in plural. For emails we use the term <code>email</code> (without dash between “e” and “m”).</p> <a name="codelayout"></a><h3>2.ii. Code Layout</h3> @@ -397,7 +403,7 @@ for ($i = 0; $i < size; $i++) </pre></div> <h4>Where to put the braces:</h4> - <p>This one is a bit of a holy war, but we're going to use a style that can be summed up in one sentence: Braces always go on their own line. The closing brace should also always be at the same column as the corresponding opening brace, examples:</p> + <p>In PHP code, braces always go on their own line. The closing brace should also always be at the same column as the corresponding opening brace, examples:</p> <div class="codebox"><pre> if (condition) @@ -427,6 +433,30 @@ function do_stuff() ... } </pre></div> + + <p>In JavaScript code, braces always go on the same line:</p> + + <div class="codebox"><pre> +if (condition) { + while (condition2) { + ... + } +} else { + ... +} + +for (var i = 0; i < size; i++) { + ... +} + +while (condition) { + ... +} + +function do_stuff() { + ... +} + </pre></div> <h4>Use spaces between tokens:</h4> <p>This is another simple, easy step that helps keep code readable without much effort. Whenever you write an assignment, expression, etc.. Always leave <em>one</em> space between the tokens. Basically, write code as if it was English. Put spaces between variable names and operators. Don't put spaces just after an opening bracket or before a closing bracket. Don't put spaces just before a comma or a semicolon. This is best shown with a few examples, examples:</p> @@ -502,7 +532,7 @@ $post_url = "{$phpbb_root_path}posting.$phpEx?mode=$mode&amp;start=$start"; <p>In SQL statements mixing single and double quotes is partly allowed (following the guidelines listed here about SQL formatting), else one should try to only use one method - mostly single quotes.</p> <h4>Commas after every array element:</h4> - <p>If an array is defined with each element on its own line, you still have to modify the previous line to add a comma when appending a new element. PHP allows for trailing (useless) commas in array definitions. These should always be used so each element including the comma can be appended with a single line</p> + <p>If an array is defined with each element on its own line, you still have to modify the previous line to add a comma when appending a new element. PHP allows for trailing (useless) commas in array definitions. These should always be used so each element including the comma can be appended with a single line. In JavaScript, do not use the trailing comma, as it causes browsers to throw errors.</p> <p class="bad">// wrong</p> <div class="codebox"><pre> |