Sundarrajk's Weblog

Archive for the ‘Code Quality’ Category

Your Code As a Crime Scene: Use Forensic Techniques to Arrest Defects, Bottlenecks, and Bad Design in Your ProgramsYour Code As a Crime Scene: Use Forensic Techniques to Arrest Defects, Bottlenecks, and Bad Design in Your Programs by Adam Tornhill
My rating: 4 of 5 stars

A very different way of looking at problems in the code. The author suggests various non-traditional means of identifying problems in software development.

Number of times a code has changed, code churn (number of lines added, removed), number of developers working on a single piece of code, code changing together.

The primary requirement for all of this that the version control should be adhered to correctly. Every developer should have a personal login Id and should use it to checkin at regular intervals.

Many of the techniques provided in the book are available in the form the tool from…. These are only starting tools. These need to be coupled with other tools like d3.js to get a good representation of the status of the code.

A must read for all software developers.

View all my reviews

A very good analogy between refactoring bad code with cleaning up split juice. One would clean up juice split in our homes as we know that if left somebody can step on it and walk all over the place or it can dry up and attract ants and other insects to it, in short the consequences are not good.
Similarly consequences of leaving bad code as is are not good, but then why do software programmers not clean up bad code? Why do they leave it as is?

1. Thou shalt not copy-paste code
2. Thou shalt name appropriately even if it means typing long names.
3. Thou shalt write and automate Unit Test Cases
4. Thou shalt write small methods and small classes. (#)
5. Thou shalt document, not how it works, not what it does($), but how it can be used and why it exists
6. Thou shalt have only two levels of indentation in any method.
7. Thou shalt not write god classes (*).
8. Thou shalt update your, logically complete, code changes at least one a day to the version control system.
9. Thou shalt update your development environment at least once from the version control system.
10. Thou shalt be humble enough to accept errors or inefficiencies in your code as pointed out by your reviewers, peers or juniors and be open to correct them.
(#) Because all good things come in small packages.
($) What it does or contains should be known from the name.
(*) God classes are classes that do too many things. Whole application depends on a few classes.

1. Thou shalt configure static code checking, run it, and fix violations that are raised by the tool.
2. Thou shalt version your code in the Version Control System.
3. Thou shalt adopt Continuous Integration. (*)
4. Thou shalt let the end user to use the system regularly during development to get her feedback.
5. Thou shalt make an effort and understand the business process of the domain.
6. Thou shalt discuss with client the requirements in detail and if required ask, what may be perceived to be stupid/obvious questions, rather than assuming.
7. Thou shalt document all assumptions and share and discuss with the client the assumptions.
8. Thou shalt not drive the development team to work more than 10 hours or make it work on Saturdays and holidays.
9. Thou shalt not add more developers to try and finish the project earlier. (#)
10. Thous shalt not skip testing and performance testing of the system before any release.
(*) Check out code from the Version Control, Compile the code, Run static Code checking, run the Automated Unit Tests and generate reports.
(#) Read mythical man month by Fred Brooks


This is the third post in the series of posts based on the book JavaScript – The Good Parts by Douglas Crockford. The previous post covered details of how one can create and use functions in JavaScript. This post details out the features of functions in JavaScript. JavaScript functions have features which are not present in other languages and one needs to understand these details to write better JavaScripts and to understand the JavaScript written in the JavaScript libraries.

Arguments to a Function In addition to the explicit parameters passed to a function two more parameters are passed to a function.

  1. this: The value of this variable is discussed in detail below
  2. arguments: This is an Array like variable which has the list of arguments passed to the function

The value of “this” argument The value of the “this” argument passed to a function depends on how the function was invoked.
Invoking a function through “call” function of JavaScript
A method can be executed using the “call” of JavaScript.
When a global function is invoked
When a function defined in a global scope is invoked the value of “this” is the global object.
When Function is invoked as a method
When the function is defined inside another function it is called a method. When such a function is invoked the parent function is the value of “this”. All the attributes and function defined in the parent scope are accessible to this function through the “this” object.
If one has an inner function in a method then the “this” for this inner function will be the method. For the inner function to have access to the outer parent function of the method the method must expose it as its local variable. Typically this variable is called “that”

myObject.double = function () {
var that = this; //this is myObject
var helper = function () {
.value = add(that.value, that.value);

“this” value in function “double” will be myObject.
“this” value in function “helper” will be “double”.
The function “helper” does not have direct access to myObject. It will have access to only the local variables of the function double. Unless double exposes the myObject through “that” helper method will not have access to myObject.
When function is invoked as a new
Although JavaScript provides prototype based inheritance it provides the classical way of instantiating an object using the “new” keyword. When a function is invoked using the “new” keyword the value of “this” will be the object that is created out of this invocation.
When function is invoked using the “apply” or “call” method
All functions can be invoked via apply or call method. The difference between apply and call is that apply takes an array for the list of arguments to the function being invoked and call takes individual arguments instead of an array.
Invoking using “call”[, arg1[, arg2[, ...]]]);

The thisArg1 is the object that will be passed as the value of “this” to the function someFunction
Invoking using “apply”

someFunction.apply(thisArg, [arguments]);

The thisArg1 is the object that will be passed as the value of “this” to the function someFunction
Example of using “call”

var Quo = function (string) {
this.status = string;
Quo.prototype.getStatus = function () {
return this.status;
var statusObject = {status: "A-OK"};
//statusObject does not inherit from Quo.prototype, but we can invoke getStatus and get the value
//of status as follows:
var status =;
//the value of status will be "A-OK".

An example for apply will look the same, except that the arguments will be passed as an array.

The argument “arguments” In addition to “this” “arguments” is another variable that is available in each method. This is a list of arguments passed to the method. “arguments” is not an array in a true sense although it does behave array like. So functions that are normally available in array are not available with this variable.

Return from a function Every JavaScript function returns a value irrespective of whether there is a return statement or not. For functions that do not return anything this value is “undefined”.
The only exception is when a function is invoked with a “new” does not return anything. The “this”, the object created, is returned.
Pass by Reference All objects are always passed by reference. All primitive variables are passed by value.

Passing variables Passing variables is Pass by Value.

function myfunction(x){
// x is equal to 4
= 5;
// x is now equal to 5
var x = 4;
(x); // x is equal to 4
(x); // x is still equal to 4

Passing Object Passing objects is pass by reference.

function myobject() {
this.value = 5;
var o = new myobject();
(o.value); // o.value = 5
function objectchanger(fnc) {
.value = 6;
(o.value); // o.value is now equal to 6

Passing functions Passing functions is a little more complicated. See the example below to understand how it functions, why it functions and how to actually achieve pass by reference.

function myobject() {
this.value = 5;
.prototype.add = function() {
var o = new myobject();
(o.value); // o.value = 5
(o.value); // o.value = 6
function objectchanger(fnc) {
(); // runs the function being passed in
(o.value); // sorry, still just 6

Why does this happen? The problem here is the use of the “this” keyword. It”s a handy short-hand for referring to the current object context. When passing a function as a parameter, though, the context is lost. More accurately, “this” now refers to the context of the object making the call instead of the object’s function we just passed in. For standalone functions, this would be the window object and for functions called from an event, this would be the event object.
So how do we achieve this?
Option 1: When you know the method If you know the method of the object that will be called then it”s fairly easy. Just pass in the object instead of the function and call that instead. Using the objectchanger from the last example you”d get the following:

function objectchanger(obj) {
.add(); // runs the method of the object being passed in
(o.value); // the value is now 7

Option 2: When you don”t know the method If you don”t know the method of the object being passed in then you need to pass both the method and the object as parameters and use the call method. call is part of the JavaScript specification and allows a function to run in the context of another object. As a result, the this keyword will reference the right object: the object we passed in.
Here”s our objectchanger function one more time:

function objectchanger(fnc, obj) {
.call(obj); // runs the method of the object being passed in
(o.add, o);
(o.value); // the value is now 7

Note the use of the method call.

The Pragmatic Programmer: From Journeyman to MasterThe Pragmatic Programmer: From Journeyman to Master by Andrew Hunt
My rating: 5 of 5 stars

A one line review would read “A Pragmatic Book”. True to its title the book is all about Pragmatic Programming.

The authors provide Practical advice on different aspects of programming not limited to coding, design or architecture. They also cover team setup, tools to be used.

The book should be made a compulsory training material for all developers before they start programming professionally. We will start seeing a drastic improvement in the quality of applications that are being developed.

View all my reviews

This is the ninth and the last in the series of posts based on the book Effective Java by Joshua Bloch. In the previous post we saw best practices in using Threads in Java.

This post talks about the best practices in Serialization. This topic may not seem to appeal and/or be relevant to the many developers who are today writing Web Applications directly. What the developers need to keep in mind is that everytime they are using EJB, they are dealing with Serialization, everytime they are faced with session replication, they are dealing with serialization, everytime they are planning to cache something using an application like memcached or many of the other NoSQL databases they are dealing with Serialization. Serialization creeps in without the knowledge of the developer and so it is important to understand the best practices.

Implement Serialization Judiciously

Making a class Serializable, theoretically only requires only implementing the interface Serializable.
1.       Once a class is made serializable then it becomes very difficult to change the class without supporting all the earlier releases and this will be a tedious exercise. To circumvent this problem one will need to design and implement one’s own custom serialize method.
2.       The second problem is that everytime one deserializes the class one needs to be wary about bad data coming into the class. If not checked correctly one can end up with security issues.
3.       The testing of the class with new version of the class becomes more and more difficult.
If an alternate form of serialization like conversion to XML is available that should be considered as opposed to serialization of bytes.
Consider using a custom serialized form

If we use the default serializable format then one can never change the class.
1.       Do not accept the default serialized form without first considering whether it is appropriate
2.       Even if you decide that the default serialized form is appropriate, you often must provide a readObject to ensure invariants and security
3.       Declare an explicit serial version UID in every serializable class you write.
Write readObject methods defensively

A readObject method will be required to be implemented to validate that the class is in the right state. A malicious client can provide data which would normally not have been accepted via the constructor. Even if one validate the data after the stream a malicious program can provide the input stream for creation of the object and later modify the attributes of the class to invalid data or different data. To avoid this make a copy of the objects in the readObject method so that the original read objects can no longer be altered by the client that provided the stream.
Provide a readResolve method when necessary

A singleton class no longer remains a singleton if it implements serializable as now one will be able to create another instance by deserializing the earlier serialized class. To prevent this one needs to implement the readResolve method
1.       A readResolve method is required not only for Singletons but all classes that control instance creation on its own.
2.       Instead of creating the instances as suggested in the readObject method in the earlier topic one could return a new instance from readResolve to prevent the same problem as mentioned earlier.
With this we come to the end of the series of posts based on the book Effective Java by Joshua Bloch. It is wonderful book and should be read by all the Java programmers. The author comes with tons of experience in Java and the advice that they proffer in the book are extremely important to all developers.