Although [coding style](w:Coding style "wikilink") might seem a minor thing for novice programmers, it really is of utter importance when writing code for a medium-sized or big project. If you code alone, it still is vital to follow prespecified coding standards in order to achieve a better level of code readability for yourself. If you code as a member of a team, not following strict style conventions is completely out of the question. Considering that a project which you're the only programmer for might grow into a team project in the future makes it a crucial matter to follow certain coding standards, as it is a hard and time-consuming procedure to port code to new coding style. And, although many coding style rules can be automated and applied using a beautifier script, many rules cannot (as they fall into the programmer's judgment), and a lot of rules are broken by these scripts. In addition, many programmers, including myself, do not like using these scripts and believe that using a beautiful coding style yourself is part of the elegance of your own code.
Following a specific coding style is good for several reasons. It makes code more readable and more manageable. It can be easily read and quickly understood and modified by yourself, or by another member of your team in the future. It makes your peers appreciate your code more, as it is more elegant, and simplifies distributing under an Open Source license and documenting it.
Although it is not important whether you follow this or another coding style guide, it is very important that all the code in your project, no matter from whom it was written, follows one and only one coding style guide. Therefore, being specific and strict about which style you choose to use is crucial.
This document aims to specify my personally preferred coding style. It is certainly not the only coding style available out there, and you can use your own according to your preferences. This is in place to guide the coding style in the projects which I am the only developer for, and (mainly) for the projects that I have started but are now developed by teams. This document has grown through the experience in BlogCube, Excalibur, and deviantART, and through the valuable advice of my teams. It is used in Excalibur, Rabbit, ALiVE, BlogCube, and many other minor projects. Keep in mind that this specific coding style is not used on deviantART or other projects that I did not start myself. You are very welcome to follow this or part of this style in your own projects if you wish. If you find it inspiring and readability-promoting, I would very much appreciate it if you let me know that you follow it!
This document aims to describe a coding style for procedure-describing programming languages often used by the Kamibu team. Although it is not language-specific, it was written to describe a coding style for C, C++, PHP, Java, Python, and Javascript. Please do not apply these rules in non-procedure-describing languages such as XML, XHTML, or CSS, or to query describing languages such as SQL/MySQL. Although a set of coding style conventions is also important for these languages, this document is inappropriate for those.
As a general rule of thumb, use this document as a guide to improve the readability of your code. If any particular rule causes readability to be reduced in a particular occasion, you might violate it, but please adhere to the set of these rules in general if you decide to follow them. Keep in mind that simply following a coding standards document does help, but is not the only thing necessary to improve code readability. Care should be taken to avoid too complicated statements and to increase the maintainability of your code.
Sometimes it is more important to optimize code rather than write easily maintainable code. In this case, readability is neglected in favor of optimization. This is acceptable; however, this is rarely the case in modern programming, as optimizations achievable through code formatting are tiny compared to the productivity gained through well-formatted code.
Most programming languages ignore whitespace. Python ignores whitespace in certain locations. This is convenient because whitespace can be used to improve code readability.
Each statement should occupy its own line, even if your language allows writing many statements in one line. Two statements should never occupy the same line.
Do not use this in C++:
printf( "Enter a number: " ); scanf( "%i\n", &i );Use this instead:
printf( "Enter a number: " );
scanf( "%i\n", &i );Some languages optionally allow the use of ; at the end of lines. In the languages in which whitespace does not play any technical role, always use ; at the end of each line when it is optional. This, apart from avoiding logical mistakes, helps, for instance with Javascript, in making it possible to truncate whitespace in order to reduce download times or if you want to obfuscate the code sent to your client. When you use a ; at the end of a line, do not include any additional spacing before or after it, and generally make sure no additional whitespace is present at the end of your code lines if it is not necessary.
Optional line breaks can be used for increased readability throughout your code. For example, you can use an additional line break between two logically different blocks of code to separate them contextually.
Long statements can be broken into several lines.
Do not use this in PHP:
<?php
if ( MyLongFunction() && MyOtherLongFunction() && MyFastFunction() && MySlowFunction() && !( $res->Impact() || $res2->Impact() ) ) {
DoSomething();
}
?>Use this instead:
<?php
if ( MyLongFunction()
&& MyOtherLongFunction()
&& MyFastFunction()
&& MySlowFunction()
&& !( $res->Impact() || $res2->Impact() ) ) {
DoSomething();
}
?>Code lines should generally be limited to 100 characters. If your line grows longer than that, consider splitting it into several lines by inserting line breaks.
Line breaks inserted within one statement should be inserted after commas or semicolons, but before other operators.
Do not use this in Javascript:
for ( i = SomeVeryLongFunctionNameThatRequiresALineBreak()
; i < 5
; ++i ) {
DoSomething();
}Use this instead:
for ( i = SomeVeryLongFunctionNameThatRequiresALineBreak();
i < 5;
++i ) {
DoSomething();
}Indentation assists in identifying flow and blocks of code. Indentation should be done using four spaces, and not the tab character. Because of this, please configure your editor to display a tab character as four spaces:
- In vim set expandtab tabstop=4 shiftwidth=4 softtabstop=4
- In Notepad++ Settings > Preferences > Edit Components > Tab Setting > Replace by space / Tab size = 4
Certain blocks of code are indented. All repetition blocks (for, foreach, while, do and so forth), all blocks that are executed conditionally (if, switch), as well as structural blocks (functions, procedures, classes, interfaces, try/catch) should be indented. The defining or opening code line of the block and the ending line of the block, if any, should not be indented. Nested blocks should cause additive indentation to occur.
For example, in C++:
if ( condition ) {
statements();
for ( i = 0; i < N; ++i ) {
otherstatement();
}
}As you can see the lines inside the if block are indented. The lines inside the for block are indented as well. Since the for block exists within the if block, the lines inside the for block are doubly indented.
In multiple-options conditionals, the block containing all the conditions should be indented once, and each conditional block should be indented additionally.
For example, in PHP:
switch ( $condition ) {
case 1:
point1();
break;
case 2:
point2();
break;
case 3:
point3();
break;
default:
defaultpoint();
}In Python, indentation is not optional. The same rules as specified in this document should be followed.
Unnecessary blocks and indentation should be avoided, always favoring code simplicity. The use of exceptions, and flow-control statements such as "return", "break", and "continue" should be favoured to having an increased level of indentation. For example, "else" statements directly after a "return" statement within a conditional should be avoided.
Do not use this in C++:
int signature( int a ) {
if ( a > 0 ) {
return 1;
}
else if ( a < 0 ) {
return -1;
}
else {
return 0;
}
}Use this instead:
int signature( int a ) {
if ( a > 0 ) {
return 1;
}
if ( a < 0 ) {
return -1;
}
return 0;
}As you can see, the "else" blocks have been removed to improve code readability and simplicity. If this starts getting confusing, else statements within comments can optionally be used:
int signature( int a ) {
if ( a > 0 ) {
return 1;
}
/* else */ if ( a < 0 ) {
return -1;
}
/* else */
return 0;
}Indentation should generally be limited to 10 levels. If you require additional levels of indentation, you probably have to split your classes and functions into sub-classes and sub-functions.
Spacing improves readability a lot, and makes it easier to tell apart different entities. As a coding style document is mostly about spacing, several rules are defined below, in each different section. If no specific rules are set, no spaces should be used around entities, unless your language requires it.
Aligning content of similar lines using spaces, especially when they form one statement, can improve readability:
<?php
$test = 'Hello, world!';
$foo = 'Hello, mom!';
$bar = 'Hello, dad!';
?>Although we usually use only one space around the assignment operator, using two spaces in front of it in the above example aligns both the assignment operator and the opening quote, and should be preferred.
One space should be used around each side of all operators which take two parameters. This includes, for instance, the following operators in PHP:
- The arithmetic operators +, -, *, /, and %
- The string operator .
- The logical operators &&, || and xor
- The bitwise operators ^, &, |, << and >>
- The comparison operators ==, !=, <, >, <=, and >=
Spaces should also be left around assignment operators. For instance, the following operators in Java:
- The simple assingment operator =
- The arithmetic operation assignment operators +=, -=, *=, /=, %=
- The bitwise operation assignment operators <<=, >>=, >>>=, &=, |=, and ^=
No additional spaces should be left around any operator which takes only one parameter. This includes, for example, the following operators in C++:
- The arithmetic negation operator -
- The logical negation operator !
- The bitwise negation operator ~
- The address-of operator &
- The pointer-value operator *
- The pre- and post-increment and decrement operators ++, --
In addition, no space should be left after the error control operator @ in PHP.
No spaces should ever be left within an operator. For example, the PHP operator "=&" should always be written as such, and not as "= &".
Do not use this in PHP:
<?php
$i= $i+ 5;
?>Use this instead:
<?php
$i = $i + 5;
?>Certain operators should not be used. These are language specific.
In PHP, the use of the following operators is strongly discouraged:
- The and and or logical operators. Use && and || instead. There are certain use cases of and and or as they have different precedences. Prefer to parenthesize your expressions.
- The =& operator, when used for objects. In PHP5, objects are assigned by reference by default.
- The <> comparison operator. Use "!=" instead.
- The `` backticks execution operator. Use shell_exec instead.
Avoid using the inline conditional operator, i.e. the ? ... : operator excessively, unless it makes the code clearer. Using it often leads to code unmaintainable and difficult to read.
Do not use this in PHP:
<?php
$days = 31-((($month-(($month<8)?1:0))%2)+(($month==2)?((!($year%((!($year%100))?400:4)))?1:2):0));
?>Use this instead:
<?php
function LeapYear( $year ) {
if ( $year % 100 ) {
if ( $year % 400 ) {
return true;
}
}
else if ( $year % 4 ) {
return true;
}
/* else */
return false;
}
function DaysInMonth( $month, $year ) {
switch ( $month ) {
case 1:
case 3:
case 5:
case 7:
case 8:
case 10:
case 12:
return 31;
case 2:
if ( LeapYear( $year ) ) {
return 29;
}
/* else */
return 28;
}
return 30;
}
$days = DaysInMonth( $month, $year );
?>In C, C++, Java, Javascript, and PHP, prefer to use the preincrement and predecrement operators ++i and --i instead of their postincrement and postdecrement equivalents i++ and i--, as the first are faster. (Understanding why is left as an exercise for the reader)
A space should be left after an opening parenthesis ( or curly bracket { or bracket [ and before a closing parenthesis ) or curly bracket } or bracket ], providing they contain some content. If no content is contained, no spaces should be left before or after them. No additional spaces should be left before an opening parenthesis, curly bracket, or bracket, and no additional spaces should be left after a closing parenthesis, curly bracket, or bracket. This applies to all grouping, casting, function definition, and function calling parentheses, character-index curly brackets in PHP, array access in Java, PHP, and C++, but does not apply to block-grouping curly brackets. For specific rules about block-grouping curly brackets, see below.
Do not use this in Python:
x = (5+3) * i;Use this instead:
x = ( 5 + 3 ) * i;Variable casting should follow the parentheses rule.
Do not use this in C++:
x = (int) y;Use this instead:
x = ( int )y;Optional parentheses can be used if you think they improve readability.
A lot of programmers find the following Java code hard to read:
x = ob.j++ == 6 && ++ob.i == 6You can use this instead:
x = ( ob.j++ == 6 ) && ( ++ob.i == 6 )Some languages allow optional parenthesization, but under certain circumstances, this becomes redundant and decreases code readability. Redundant parenthesization should be avoided. For example, in PHP, no parentheses should be used around the parameters passed to the "echo", "require", and "include" constructs.
Many programming languages such as C, C++, Javascript, Java, and PHP, use a curly bracket-based syntax to define blocks.
All block statements that are surrounded by curly brackets should follow this structure: The opening curly bracket, preceded by a single space character, should stay at the same line as the opening statement while the closing bracket appears in its own line. The closing bracket should be at the same level of indentation as the opening statement. No additional spacing should appear after the closing bracket. All statements between the two should be in a higher level of indentation than the opening statement.
For example, in C++:
if ( condition ) {
statements();
for ( i = 0; i < N; ++i ) {
otherstatement();
}
}If a block group consists of several blocks using curly brackets, such as an if/else structure, the ending bracket for each block should be on its own line, and the same for the opening statement.
Do not use this in C++:
if ( condition ) {
Operation();
} else {
Operation2();
}Use this instead:
if ( condition ) {
Operation();
} else {
Operation2();
}If additional code tied to the ending curly bracket is needed, but it does not introduce a new code block, such as in do...while statements, it should appear at the same line as the ending curly bracket.
For example, in C++:
do {
Operation();
} while ( condition );While curly brackets are technically optional, they should be always included, even when your block contains only one line of code. This makes your code more readable and eliminates possible future logical mistakes.
Do not use this in Java:
for ( i = 0; i < N; ++i )
system.out.println( i );Use this instead:
for ( i = 0; i < N; ++i ) {
system.out.println( i );
}No additional spaces should be used around strings.
When your language allows use of both "double" and 'single' quotes to define strings, use the latter. Switching to the first kind is acceptable providing there is a reason to do it, such as using "\n" or $variables within strings in PHP, or to avoid excessive escaping.
No spaces additional to what defined above should be left around function names when defining them or calling them.
Do not use this in PHP:
<?php
function Foo ( $bar ) {
return $bar + 5;
}
?>Use this instead:
<?php
function Foo( $bar ) {
return $bar + 5;
}
?>Parenthesization rules should apply to the function definition and calling parentheses as normal. Parameters passed to functions should be comma-separated with one space following each comma, but none preceding.
Do not use this in PHP:
<?php
echo Foo( $scooby,$doo );
?>Use this instead:
<?php
echo Foo( $scooby, $doo );
?>Other control structures accepting multiple arguments should use the same idea. Arguments should be separated using commas (or semicolons) followed, but not preceded by a space. For example, this includes the PHP echo keyword, and for statements in C, C++, PHP, Java, and Javascript.
Do not use this in Javascript:
for ( i = 0;i < N;++i ) {
alert( i );
}Use this instead:
for ( i = 0; i < N; ++i ) {
alert( i );
}Functions should start with an upper-case letter. Each word inside the function name should be capitalized, but no underscores should occur between the words: DoSomething(), MarkAsRead(). When writing for a big project and your functions are split into different files conceptually, prefix each function name with the library name in singular capitalized the same as function names followed by an underscore: User_CheckCorruption(), PrivateMessage_Delete(). Preceding a function name can be omitted if the function is used extremely often, to make other code parts shorter, but it is important to make certain it is obvious from which library it feeds: _(), Element().
Function names should make the function operation obvious. For this reason, prefer not to shorten names unless absolutely necessary. Keep function names short by choosing appropriate names rather than shortening words.
Functions should usually occupy less than a screen of code. That's 50 lines of code the most. If a given function takes up more than this, it probably means that it performs an operation that can be split into multiple sub-functions.
Some functions are deprecated. These are language-specific.
In PHP, do not use the print construct. Use echo instead. The use of extract is forbidden, as it yields to [magic](w:Magic (programming) "wikilink").
Objects and classes are a crucial part in modern programming when [OOP](w:Object-oriented programming "wikilink") is used.
No space should be left around object resolving operators such as ::, . and -> in C++, the :: and -> operator in PHP, the :: and . operator in Java, and the . operator in Javascript and in Python. No additional spaces should be left around object variables. The same applies to class names both when defining them and using them.
Do not use this in Javascript:
loc = window . locationUse this instead:
loc = window.locationClass names, like function names, should be as short as possible, without, however, shortening words. If possible, use one word for your class names. The same capitalization as in functions should be used: User, Article, Message, Deviation, Screenshot, ImageProcessor. Preceding a class name with a library/context name should be avoided; if you feel the urge to do that, you probably should split your libraries into sub-libraries.
If your language makes it is possible to group functions into a namespace and your function names end up inconveniently long when prefixed with a library name, use namespaces to group similar functions together. Namespaces should be named after the library name they are contained in in plural and capitalized according to function names: Users::CheckCorruption(), PrivateMessages::Delete(). This is to avoid naming conflicts with instanciable class names.
If you decide to use namespaces, however, do not use prefixes at all. Either the one, or the other.
Certain languages, such as PHP, do not allow namespaces. When static calling is allowed, as in PHP, use it to define a namespace. In this case, make sure your class cannot be instantiated, or, if your language does not allow this, create an exception-throwing constructor to assert that your class will not be instantiated. Do not mix namespace classes and normal classes into one class!
When static calling is not allowed, as in Javascript, use singletons to define a namespace, and make them global variables:
var Examples = {
Test: function() {
alert( 'Hello, world!' );
}
}Use the classic OOP [design patterns](w:Design pattern (computer science) "wikilink") with objects representing physical application entities in domain-level-object degree. You can use namespacing as defined above. Singletons can be used as namespaces, or for other operations, but should be limited to a certain extend. Avoid [god](w:God object "wikilink") and [big hairy](w:Big Hairy Object "wikilink") objects. Do not use exotic OOP patterns such as [visitor](w:Visitor pattern "wikilink"), as the code grows unmaintainable if some developers use them and some do not. Follow the [Law of Demeter](w:Law of Demeter "wikilink").
If your language supports it, always make all your class variables either private or protected, and allow the use of [setters and getters](w:Mutator method "wikilink") to access them. Even if your language does not support visibility specification, make sure you do not publicly use class variables directly. For functions, use the most limited possible visibility according to your needs. Hence, for example, if a function does not need to be cross-class or publicly accessible, make it private, and not protected or public.
If your language supports it, always define your classes as being non-extensible if they will work incorrectly when extended. For example, in PHP, use the final keyword. If your classes are extensible, take care to make them properly extensible, by using appropriate visibility.
In most OOP languages, it is possible to access the working object instance of the current class using a special keyword, such as this. Some of them, such as Java, expose all class attributes and methods directly into the scope of class methods, allowing using them directly, unless a scope resolution is required. For clarity, if a this-like keyword is available, always use it when it is optional.
Care should be taken for code that is executed conditionally to observe basic optimization rules. Code that is more likely to be executed should be faster than code that is less likely to be executed.
For example, when using the or and and operators, place your faster statements first, and your slower statements afterwards.
Do not use this in C++:
if ( SlowFunction() || FastFunction() ) {
if ( SlowFunction2() && FastFunction2() ) {
Result();
}
}Use this instead:
if ( FastFunction() || SlowFunction() ) {
if ( FastFunction2() && SlowFunction2() ) {
Result();
}
}No additional spaces should be used around variables or constants.
Constant names should always be in uppercase letters, even when your language allows any capitalization. If you want to use multiple words, separate them by underscores. Do not shorten words unless it is something generally acceptable (e.g. "URL", "DIR", "DB", "MAX", and "MIN"); instead, try to find a descriptive word to eliminate the number of words used: IMAGES_URL, ROOT_DIR, DB_PASSWORD. Do not shorter words by removing letters. For example, do not shorten "count" to "cnt".
You can prefix your constants with the library name they are contained in in singular for increased clarity: USER_PASSWORD_SALT, ALBUM_MAX_SIZE.
Variable names should be in lower case, short and descriptive. Underscores should be used to separate words, but in most cases you should avoid using multiple words in the first place. Shortened words and letters are allowed, providing they increase simplicity and do not affect clarity: options, revisions, to_user, change, id.
The variables "i" and "j" should always be defined as integers and used as counters, as most programmers are used to this logic.
Global variables should be avoided to a certain extend. It is okay to use global variables to represent project-wide settings, and singletons that perform certain operations. If you do use globals, make sure they are certain, prespecified, and that there is no doubt about whether a specific variable is a global or not. If necessary, create a documentation entry that lists all globals used in your project clearly.
Class member names should start with the lower-case letter "m" (denoting member) if they are of private or protected visibility. If your language does not support visibilities, precede your private variables with the underscore character instead of the m character to disallow direct access to your variables. Their names should then follow function naming capitalization.
In any case, if your language is not case-sensitive about variable names and you are using a specific capitalization, do not switch between capitalizations, as this makes the code harder to read.
In general, also prefer to avoid using variables with similar names in the same context, such as, for example "advice_count" and "advise_count", as they can be easily confused.
Variables should be defined or made global at the top of each function. No variable declarations should occur in the middle of a function. If putting your variables at the top of the function makes it look unclear, your function is probably too complex and should be split into several sub-functions. Leave an empty line after the variables declarations or globalizations part of your function.
Do not use this in PHP:
<?php
function MyFunction() {
$a = true;
$i = 0;
global $b; // this line should be at the top of the function
while ( $a ) {
Operation();
++$i;
if ( $i == $b ) {
break;
}
}
}
?>Use this instead:
<?php
function MyFunction() {
global $b;
$a = true;
$i = 0;
while ( $a ) {
Operation();
++$i;
if ( $i == $b ) {
break;
}
}
}
?>If your language supports defining variables whose scope is limited to a smaller block of code than a function, such as a for statement, this is acceptable:
for ( int i = 0; i < N; ++i ) {
DoSomething( i );
}When defining class members, variable definitions should be at the top of the class definition and followed by an empty line.
Do not use this in PHP:
<?php
final class Foo {
public function Foo( $construct ) {
$this->mBar = ( int )$construct;
}
private $mBar; // this should be at the top of the class
public function Bar() {
return $this->mBar;
}
}
?>Use this instead:
<?php
final class Foo {
private $mBar;
public function Foo( $construct ) {
$this->mBar = ( int )$construct;
}
public function Bar() {
return $this->mBar;
}
}
?>When multiline comments are allowed, use them when writing multiline comments. You can use either the multiline comment format or the single line comment format for single line comments.
PHP allows the use of old-style comments using the # symbol. Use of such comments is forbidden.
When you write incomplete code that you want to improve later, add a comment starting with the word "[TODO](w:Comment (computer programming)#Tags "wikilink")" in this capitalization and without a space between the "TO" and the "DO" (so that it is greppable), followed by a colon, a space, and a description of what needs to be done. If you come across code that is buggy, or can be optimized, but do not have the time to fix it at that moment, add a TODO comment with a similar structure. Do not use [NOTE](w:Comment (computer programming)#Tags "wikilink") or [FIXME](w:Comment (computer programming)#Tags "wikilink").
[Descriptive comments](w:Comment (computer programming)#Code_description "wikilink") are encouraged. While you write your code, try to clarify the intend of parts that are complex to understand using comments. While reading code, if you found some part difficult to understand, you are encouraged to write an explanatory comment clarifying why that code was written. Descriptive comments should be in imperative form, as if you're the programmer talking to the computer: "Declare variable $a", "loop through the array", "find the user who wrote the comment" and so forth.
The else comment can be used if it is unclear whether the particular code will execute conditionally, especially after a return statement that is executed conditionally.
For example, in C++:
int foo( int bar ) {
if ( bar < 0 ) {
return 0;
}
/* else */
return bar;
}fallthru, an intentional misspelling of "fall through", can be used in switch statements in which it is hard to tell whether execution continues between cases. As it is more often to stop execution after a case is found, most programmers are more familiar with this, and, hence, a "fallthru" comment makes the code behavior clear.
For example, in C++:
switch ( boat ) {
case 5:
++i;
/* fallthru */
case 10:
++j;
break;
default:
i = 0;
j = 0;
}The comment RECURSE! can be used to make it clear that a function is being called recursively. This is often useful to make the intention of the function clearer to the reader.
When reading code written by your team and you find a part impossible to understand, feel free to add comments questioning the behavior of the code. Comments such as "What does this do?" or "What does variable $goldage store?" are appropriate.
If you find a certain piece of code would be better if written in another way, but do not feel comfortable enough to edit it yourself, feel free to add a comment stating how you would like the code to be. This is generally good because it often leads to code refactoring, or at least good faith discussion about what the code should look like.
Comments that are not descriptive should be signed using your developer username. Replies to these comments should be signed as well. When comments arrive to a point (for example a TODO is resolved, or a refactoring decision is made after a guidance comment), the relevant comment should be removed. This only applies to non-descriptive comments, however -- descriptive comments should stay in their place as long as they are valid.
Asserting is important. It is one of the easiest and fastest ways to debug. Find out why. Most modern programming languages support assertions themselves. If not, it is easy to implement them ad hoc. Please use assertions extensively, they are a Good Thing!
All programming languages have their differences and are unique. Certain rules should be followed when programming in a language that do not apply in other languages.
Some programming languages support the use of goto-like statements, leading to [unstructured programming](w:Unstructured programming "wikilink"). These should be avoided.
Some programming languages allow embedding different languages within them. For example, PHP allows embedding the direct output within the code, whether it is HTML, CSS, Javascript, or something else. In this case, your main language should be used to guide indentation and other rules. Hence, if you are writing a PHP script that contains some HTML, your indentation should follow the PHP code flow, and not the HTML nesting.
Care should be taken to follow strict nesting when combining languages. In this sense, for example when writing PHP and HTML, a "div" opening tag should be in the same PHP function as the respective closing "div" tag, and under the same parent block (i.e. cross-nesting should not be used).
In PHP, there exist shortened forms of the "<?php" introductory tag. These forms are "<?" and "<?=". For increased compatibility, shortened tags should not be used.
There are two basic ways to output content in PHP. The first is to use the echo "text" construct, while the second is to use ?>text<?php. The latter should be preferred, as it allows code highlighters to switch between PHP and your output format (be it HTML, CSS, Javascript, TeX, or anything else) and is slightly faster.
For increased readability, a new line before "?>" and a new line after "<?php" (as they do not affect the output) should be enforced.
The keywords false, true, and null should be in lower-case, while the keyword New should be spelled with the "N" in upper-case and the rest in lower-case.
All source code files must use the [[w:UTF-8|UTF-8]] encoding (in favor of [[w:ISO-8859-1#ISO-8859-1|ISO-8859-1]], ISO-8859-7, or Windows-1252). No [[w:Byte Order Mark|BOM]] should ever be used. In Notepad++, you can configure this using Settings > Preferences > New Document > Encoding > UTF-8 without BOM.
The line breaks should be in UNIX format, i.e. each line should end with a line feed (LF). Line feeds are represented as ordinal 10, octal 012 and hex 0A. Do not use carriage returns (CR) like Macintosh computers do or the carriage return/line feed combination (CRLF) like Windows computers do. In Notepad++, you can configure this using Settings > Preferences > New Document > Format > UNIX.
All source code files should end with one (and not multiple) new line and nothing after it. This means that when the cursor is at the very end of the file, it should be one line below the last source code line (it is worth noting that vim's behavior deviates from the one described here; in vim the last new line is hidden by default).
Filenames (and folder names) should always be in lower case. They must only contain lower case latin letters, numbers, the dot and the underscore character. Do not use spaces or UTF-8 characters or other symbols. Do not use different capitalization. This is important as different special characters are disallowed on different platforms. In addition, case sensitivity is different on different platforms.
I'd like to thank these people for making suggestions for this document, or inspiring me to mention certain points:
Other Coding Style guides:
- [GNU](w:GNU Coding Standards "wikilink")
- PEAR
- Mozilla
- Google C++ Guide
See also the relevant Wikipedia articles:
- [Coding style](w:Coding style "wikilink")
- [Indent style](w:Indent style "wikilink")
- [Comments](w:Comment (computer programming) "wikilink")