<!DOCTYPE html>
<html>
<head>
<title>Page Title</title>
</head>
<body>
<img src="images/company-logo.png" alt="Company">
<h1 class="hello-world">Hello, world!</h1>
</body>
</html>
Enforce standards mode and more consistent rendering in every browser possible with this simple doctype at the beginning of every HTML page.
<!DOCTYPE html>
<html>
</html>
From the HTML5 spec:
Authors are encouraged to specify a lang attribute on the root html element, giving the document's language. This aids speech synthesis tools to determine what pronunciations to use, translation tools to determine what rules to use, and so forth.
<!DOCTYPE html>
<html lang="en">
</html>
Internet Explorer supports the use of a document compatibility tag to specify what version of IE the page should be rendered as. Unless circumstances require otherwise, it's most useful to instruct IE to use the latest supported mode with edge mode.
<meta http-equiv="X-UA-Compatible" content="IE=Edge">
Quickly and easily ensure proper rendering of your content by declaring an explicit character encoding. When doing so, you may avoid using character entities in your HTML, provided their encoding matches that of the document (generally UTF-8).
<head>
<meta charset="utf-8">
</head>
HTML attributes should come in this particular order for easier reading of code.
Classes make for great reusable components, so they come first. Ids are more specific and should be used sparingly (e.g., for in-page bookmarks), so they come second.
<a class="..." id="..." data-modal="..." href="...">
Example link
</a>
<input class="..." type="...">
<img src="..." alt="...">
Whenever possible, avoid unnecessary parent elements when writing HTML. Many times this requires iteration and refactoring, but produces less HTML.
<!-- Not so great -->
<span class="avatar">
<img src="...">
</span>
<!-- Better -->
<img class="avatar" src="...">
Writing markup in a JavaScript file makes the content harder to find, harder to edit, and less performant. Avoid it whenever possible.
.spaces-after {
width: 100%;
}
.line-break,
.grouped {
width: 100%;
height: 100%;
}
body {
background-color: #eee;
}
// Comment
// Blocks
// Avoid
margin: 0px;
// Use
margin: 0;
body {
background-image: url('company-logo.png');
background-size: cover;
background-position: center center;
}
Compared to s, @import is slower, adds extra page requests, and can cause other unforeseen problems. Avoid them and instead opt for an alternate approach:
<!-- Avoid @imports -->
<style>
@import url("more.css");
</style>
<!-- Use link elements -->
<link rel="stylesheet" href="core.css">
// Avoid
.t {
...
}
.red {
...
}
.header {
...
}
// Use
.tweet {
...
}
.important {
...
}
.tweet-header {
...
}
JavaScript programs should be stored in and delivered as .js files.
JavaScript code should not be embedded in HTML files unless the code is specific to a single session. Code in HTML adds significantly to page weight with no opportunity for mitigation by caching and compression.
<script src=filename.js></script> tags should be placed as late in the body as possible. This reduces the effects of delays imposed by script loading on other page components. There is no need to use the language or type attributes. It is the server, not the script tag, that determines the MIME type.
Avoid lines longer than 120 characters. When a statement will not fit on a single line, it may be necessary to break it. Place the break after an operator, ideally after a comma. A break after an operator decreases the likelihood that a copy-paste error will be masked by semicolon insertion. The next line should be indented 8 spaces.
Be generous with comments. It is useful to leave information that will be read at a later time by people(possibly yourself) who will need to understand what you have done. The comments should be well-written and clear, just like the code they are annotating. An occasional nugget of humor might be appreciated. Frustrations and resentments will not.
It is important that comments be kept up-to-date. Erroneous comments can make programs even harder to read and understand. Make comments meaningful. Focus on what is not immediately visible.
// Avoid
i = 0; // Set i to zero.
All variables should be declared before use. JavaScript does not require this, but doing so makes the program easier to read and makes it easier to detect undeclared variables that may become implied globals. Implied global variables should never be used. Use of global variables should be minimized.
The var statement should be the first statement in the function body.
It is preferred that each variable be given its own line and comment. They should be listed in alphabetical order if possible.
JavaScript does not have block scope, so defining variables in blocks can confuse programmers who are experienced with other C family languages. Define all variables at the top of the function.
var currentEntry, // currently selected table entry
level, // indentation level
size; // size of table
All functions should be declared before they are used. Inner functions should follow the var statement. This helps make it clear what variables are included in its scope.
There should be no space between the name of a function and the( (left parenthesis) of its parameter list. There should be one space between the ) (right parenthesis) and the { (left curly brace) that begins the statement body. The body itself is indented four spaces. The } (right curly brace) is aligned with the line containing the beginning of the declaration of the function.
function outer(c, d) {
var e = c * d;
function inner(a, b) {
return (e * a) + b;
}
return inner(0, 1);
}
The if class of statements should have the following form:
if(condition) {
...
}
if(condition) {
...
} else {
...
}
if(condition) {
...
} else if(condition) {
...
} else {
...
}
A for class of statements should have the following form:
for(initialization; condition; update) {
...
}
for(variable in object) {
if(filter) {
...
}
}
A while statement should have the following form:
while(condition) {
...
}
Personally, I prefer to use 'single quote marks' but I don't mind if "double quote marks" are used. I would just request that you stick to using the way you prefer.
// Use this
echo 'Hello world!';
// Or use this
echo "Hello world!";
Although functions, classes and user-defined functions are not case-sensitive, please use lowercase characters throughout.
// Use this
echo 'Hello world!';
// Don't use
Echo 'Hello world!';
// Don't use
ECHO 'Hello world!';
Use lowercase characters when declaring variables as they are case-sensitive. Use an underscore(_) to separate real words.
// Use this
$my_variable = 'Hello world!';
// Don't use
$myVariable = 'Hello world!';
Use lowercase characters when declaring functions as they are case-sensitive. Use an underscore(_) to separate real words.
function this_is_my_function() {
...
}
this_is_my_function();
Use // for comment blocks (instead of /* */) and don't use the # for commenting.
Always use echo over print as echo is marginally faster than print.
Use it without the(brackets) as they are not needed.
echo 'Echo, echo...';
When concatenating variables, use a space before and after the period mark to help make it easier to read.
$var1 = 'first';
$var2 = 'third';
$var3 = $var1 . 'second' . $var2 . 'fourth';