Server side pagination.
Archive for August, 2009
Things I hate…
Saturday, August 15th, 2009Code Style is not Subjective p.2
Monday, August 10th, 2009Now for a bit about JavaScript and C-style code. First and foremost, if you are unfamiliar or think you are familiar, but really aren’t, (because of say, the welcoming C-style syntax) with JavaScript consider reading JavaScript: The Good Parts. It is a quick, light read that provides invaluable insight into the language. JS is an immensely expressive language but some of the baggage surrounding it can make it seem like little more than a toy language that is intolerable to code in and should generally be avoided at all costs. This simply isn’t true, so go on, have a read.
Update: Indentation and brace style should follow the 1TBS/OTBS style.
When programming in JS always keep in mind that JS doesn’t come with a linker, so everything is put in the global namespace unless you explicitly state not to. All program variables should be kept either within a lambda scope e.g.
(function () {
var a = ‘foo’,
b = function () {…},
c = ‘bar’, …
)());
var a = ‘foo’,
b = function () {…},
c = ‘bar’, …
)());
or within a namespace e.g.
MYPROGRAM = window.MYPROGRAM || {};
MYPROGRAM.a = ‘foo’;
MYPROGRAM.b = function b (…) {…};
MYPROGRAM.c = ‘bar’;
MYPROGRAM.a = ‘foo’;
MYPROGRAM.b = function b (…) {…};
MYPROGRAM.c = ‘bar’;
-or-
MYPROGRAM = window.MYPROGRAM || {
a: ‘foo’,
b: function b (…) {…},
c: ‘bar’
};
a: ‘foo’,
b: function b (…) {…},
c: ‘bar’
};
Also, all variables should be declared with the var keyword, otherwise the JS interpreter will automatically link it to the global object. Further, unlike many other C-style languages JS does not have block scope (neither does PHP for that matter). In languages with block scope it is suggested to not declare variables until they are used. Since both PHP and JS only have functional scope, variables should be declared at the top of the function in which they are used rather than right before they are used.
Since JS provides no linkeranything can overwrite anything else, and no runtime warning or errors are provided when such an event occurs. A lot of code in JS seems to be copied and pasted from elsewhere and this code could very well have strange interactions with your programs if the original author forgot to properly declare a variable or named one of his functions the same as yours. Always encapsulate your program variables and keep them out of the global namespace. When using a namespace, keep the namespace as all caps, this is to differentiate it from other methods or functions.
Generally, when naming function or methods, the name should start with a lower case letter, unless it is a constructor function. If it is a constructor function it should start with an upper case letter. e.g.
function Foo (bar) {
this.hello = function () {
alert(bar);
}
}
this.hello = function () {
alert(bar);
}
}
var myFoo = new Foo("bar");
myFoo.hello(); //"bar"
Since we are primarily dealing with web languages it is best not to mix up code style between different C-style languages such as JS and PHP, as during the course of a day you will most likely be working in many languages. In either language either of the following are acceptable:
if (foo) {
bar;
}
bar;
}
if (foo)
{
bar;
}
if (foo)
bar;
However, the first is the preferred way of writing it. This is due to a limitation in JS. JS implicitly inserts end of statement characters on new lines. So something like:
return
{
foo: ‘bar’
};
{
foo: ‘bar’
};
may look like it is returning a new object with the property foo with the value ‘bar.’ However, it is actually returning undefined and the object literal statement is never reached. What is really meant is:
return {
foo: ‘bar’
};
foo: ‘bar’
};
Moreover, it is very easy to make a mistake such as:
if (foo)
bar();
baz();
bar();
baz();
which was meant to mean:
if (foo) {
bar();
baz();
}
bar();
baz();
}
but really means:
if (foo) {
bar();
}
baz();
bar();
}
baz();
It is preferred that when declaring arrays or objects that their literal forms are used. So instead of:
a = new Object();
b = new Array();
b = new Array();
write:
a = {};
b = [];
b = [];
The use of whitespace is paramount when writing code. It increases legibility significantly. The suggested use of whitespace is as follows:
- Use a space before and after any operator e.g. /, +, *, -, &&, etc.
- Use a space after a function declaration and the beginning and end of the argument definition e.g. function foo (a, b, c) { }. This helps differentiate between a function definition and a function invocation.
- Use a space after semi-colons
When testing for values in JS always use === or !== operators. Their == and != counterparts do not do what you might think they do and should generally be avoided.
If a function requires many arguments consider putting the arguments in an options object and passing the object into the function instead of having a long list of arguments which may or may not be optional. This alleviates the need to have to remember the order of all the arguments and allows for more verbose code, too. For example:
function foo (bar, baz, qoz, …) { … };
foo(1, 2, 3);
foo(1, 2, 3);
can be rewritten as
function foo (args) { … };
foo({
bar: 1,
qoz: 2,
baz: 3
});
foo({
bar: 1,
qoz: 2,
baz: 3
});
More to come later…
Code Style is not Subjective p.1
Monday, August 10th, 2009Over the course of my, so-far brief, career in software development I have seen a plethora of different coding styles fully blanketing the spectrum from awful to outstanding. Software is not a write-only medium and is read (both by humans and machines alike) many more times than it is inked (or typed, punched, plugged, etc). As such, unless participating in some sort of obfuscated code competition, all code should be written with readability in mind. Over the course of the next few days I will attempt to define basic coding styles for C-style languages (like PHP, Java, C#, and JavaScript), SGML style languages (like XHTML, HTML, ColdFusion, and XML), and SQL as well as some best practices.
To begin, I will start with some basic principles that are applicable to the programming field in general.
First and foremost, in order to attain a higher degree of readability the DRY principle should always be kept in mind. Further, code should generally be as verbose as possible. Verbosity allows writing of self documenting code and keeps comments (which aren’t necessarily updated as often as the code is, which is a bad thing indeed) to a minimum. It is very easy to write terse code using quasi-cryptic operators such as ++ or — and short variable names such as r instead of row. However, while this practice could be considered elegant it can often be difficult to read and can be subject to bug introduction during maintenance (or even development).
Update: After some input from co-workers I thought it best to amend the statement discouraging the use of terse operators like ++ and –. While I personally feel it best to not use them, I can also understand that to some, it is much more readable to see i++/i– over i = i + 1 and i = i -1. If you are unfamiliar with all aspects of these operators than you should avoid using them and instead use the more verbose notation. However, if you choose to use these operators, it may be in your best interest to leave a comment or two about what these operators do if your code is to be maintained by persons without in-depth knowledge of them.
For example, consider the following piece of JS that determines if the two given arrays are equivalent:
(function (a1,a2){
for (var i = 0, var j = 0; i < a1.length && j < a2.length; i++, j++)
if (a1[i] !== a2[j]) return false;
return a1[i] === a2[j];
}([1,2,3],[1,2])); //false
for (var i = 0, var j = 0; i < a1.length && j < a2.length; i++, j++)
if (a1[i] !== a2[j]) return false;
return a1[i] === a2[j];
}([1,2,3],[1,2])); //false
This code is a bit cryptic to read and is generally poorly written for a number of reasons, some of which won’t be discussed until the JS portion of this series. It would be much easier to read and maintain if it were written as:
function arrayCompare (array1, array2) {
var length1 = array1.length,
length2 = array2.length,
i = 0, j = 0;
while (i < length1 && j < length2) {
if (array1[i] !== array2[j]) {
return false;
}
i = i + 1;
j = j + 1;
}
return array1[i] === array2[j];
}
arrayCompare([1, 2, 3], [1, 2]); //false
var length1 = array1.length,
length2 = array2.length,
i = 0, j = 0;
while (i < length1 && j < length2) {
if (array1[i] !== array2[j]) {
return false;
}
i = i + 1;
j = j + 1;
}
return array1[i] === array2[j];
}
arrayCompare([1, 2, 3], [1, 2]); //false
The code is much more verbose and it is clear what each variable represents. Since there using a for loop here would make the code much more terse using a while loop makes it much more readable. It is also easy to see that both i and j are incremented once through each iteration of the loop and it is clear what the body of the while and if statements are.
All code should adhere to strict indentation and other white-space schemas. Lines of code should also fit in your IDE (or text) editor’s window without the need for scrolling or window resizing. Unfortunately, this is a little bit subjective as not all monitors are created equally and the size of your window may differ from the size of your fellow developers window, or perhaps the size of your window on another machine. Therefore, I recommend adhering to 79 characters max per line. This will almost guarantee the code will display inside of the editor window without wrapping or the need for scrolling or resizing. 79 characters is the default max of dumb terminal windows.
Such a small character limit may seem like a large restriction, but for comparison, my Eclipse IDE with the navigator and outline windows in view leaves only 101 characters for the text editor at a 1600×1200 resolution. It is possible to be very expressive within 79 characters and anything beyond that should go to a new line and be indented appropriately.
I think that’s a good start. More to come later.