In the programming world, there is a principle referred to as ‘DRY’, which stands for “Don’t Repeat Yourself”. In a nutshell, it states that if you find yourself writing identical code in two or more different areas of a system, then you should rationalise this into a single module that is utilised within these areas.

DRY is part of a broader principle of Code Reuse – a fundamental tenet of software engineering. The reuse of code carries with it the advantage of a smaller code base and reduced maintenance costs.

As the spotlight falls ever more frequently on the world of Object Oriented Programming (OOP), it’s worth highlighting some of the key challenges that this discipline attempts to address. Code reuse is certainly one of them, but others such as segregation of functional responsibility, and ‘coupling’ are also relevant.

‘Coupling’ is a term that describes interdependence of a system. Systems are said to be highly coupled when each module depends on many other modules in a system. We can visualise the modules as a series of balls each connected by a string to other balls (modules) on which it depends. This analogy is quite good, as we can see that a system that is highly-coupled (lots of string) has a tendency to become a tangled mess. And, if we want to replace a ball, or change the nature of it in some way (size, colour, for example), then this may have a knock-on effect on all the balls (modules), so we have to examine (test) these to ensure they are still ok. In short, a highly-coupled system is BAD!

As it turns out, DRY, and the principle of reuse can actually lead to more tightly coupled systems. Consider and contrast two distinct are areas of a financial system. One is concerned with keying new client informations and the other with the provision of management information. These are two areas that are largely unrelated. If we consolidate all their common functionality, then we tie them closely together. If we then modify this common functionality in future, then we have to test two different areas.

So, like almost any other principle in programming, it turns out that DRY is a trade-off and a compromise. They key is context. Sometimes duplication is a mere coincidence, and by retaining it we allow independent areas of the system to mature and evolve independently while limited the bonds that couple it. Sometimes, WET (Write-Every-Time) really is better than DRY!

Some time ago, I penned an article “Heroes of Computing” where I discussed what, in my opinion, was a lamentable lack of awareness for pioneers of the computing profession, even within the profession itself.

And what of those most notable pioneers?

Charles Babbage, who many people credit with building the first computer was ridiculed and died a lonely man.

Ada Lovelace, who wrote logic that would run on Babbage’s machines and is often cited as the worlds first programmer died of bloodletting from her physicians as a treatment of uterine cancer.

And, finally, Alan Turing, one of the most brilliant minds this country has ever produced, whose contributions to the war effort in WWII at Bletchley Park is widely regarded to have shortened it by two years sparing potentially millions of lives, was forced to undergo chemical castration after being convicted of homosexuality.

Image by Christopher_Hawkins via Flickr

Lets look at this in a different light.

Alan Turing invented the computer and was castrated and persecuted. Alan Sugar sold computers and was knighted.

So, I was delighted when I was directed towards a new e-Petition on the UK government website, calling for his pardon.

In 2009 then British Prime-Minister, Gordon Brown, issued a formal apology on behalf of the British government. Stating “I’m proud to say sorry to a real war hero.”

People may cite the context of that era and state that, at the time, homosexuality was illegal. But even if you account for that, Alan Turing’s treatment was still utterly appalling.

He was prosecuted for gross indecency under Section 11 of the Criminal Law Amendment Act 1885, the same piece of legislation used nearly seven decades earlier to prosecute Oscar Wilde. The punishment was quite different, however. Wilde was sentenced to two years imprisonment and hard labour, whilst Turing was offered chemical castration as an alternative to imprisonment. The sentence is widely regarded to be a knee-jerk reaction at the time to acute public anxiety about spies and homosexual entrapment by Soviet agents. Turing was, of course,  never accused nor suspected of espionage in any shape or form.

In this instance, I think it’s also worth referencing the case in 2006 where the British Government formally pardoned 306 soldiers who were executed for desertion during the World War One. This was considered by many to be most brutal of wars, as many ordinary individuals, conscripted and wrenched away from their family and loved-ones were subject to a gruesome and almost unimaginable horror.

It was recognised that in many cases these people were probably sufferers of post-traumatic stress disorder (PTSD). The pardon allowed their families to remember them in honour and to celebrate their life and sacrifice.

In the centenary of his birth I see that it is only fitting that the same gesture be bestowed upon Turing. By all accounts he was an inspirational and brilliant man who encompassed the very best of British ingenuity and inventiveness, and is someone whose life should be more publicised and celebrated.

So, please, if you are a British citizen I would implore you to sign the government E-Petition. The link is below

https://submissions.epetitions.direct.gov.uk/petitions/23526

I stumbled across this message recently during the course of developing a bespoke jQuery plugin for one of our systems.

The offending code in question was

/*****************************************************************************/
/*Private functions.
/*****************************************************************************/

Given its structure, I found myself blinded to the offending code until I spotted that I had indeed omitted the closing ‘*/’ from the second line.

The message it yielded in full was:

Stopping, unable to continue. (4% scanned).

This message is easy enough to understand, but it’s one of those that causes JSLint to halt in its tracks

The omission of a closing statement to any block of code can result in inadvertently nesting any proceeding code. Block comments are more forgiving of the omission, because the second opening ‘/* will be treated as a comment itself.

However, consider the following:

/*Private functions.    /*Nested Comment*/   */

In the above code, the first close-comment will close everything, and the second will be left dangling. This is even shown up by the syntax-highlighter (if you can see it).

One user did ask this question of Douglas Crockford, who responded

JSLint stops because it sees comments that are nested. That is usually
an indication of a serious coding error. In the face of such errors,
JSLint stops.

So there we have it. Don’t nest your comments.

This article is one of a series on the error and warning messages produced by JSLint.

When referring to function arguments in JavaScript, we almost always refer to them by the name by which they were passed:

function foo(a) {
    var b = a;   //refer to the function parameter 'a',
    //....
}

However, there is an object representing these arguments to which we can refer. This is the arguments object.

This object provides us with some useful properties, which include .length and .callee. It also allows us to refer to the argument by position like so:

function foo(a) {
    var b = arguments[0];
}

It is this use of the arguments object that JSLint complains about. Variables are given names to identify what they are and what they mean. There are a valuable tool for writing self-documenting code, and referring to them in any other way makes little sense. You’re also relying on the argument being in a particular position. If you ever change the order of the arguments in the function definition, you’ll have to change the index by which you reference each argument.

Moreover, unless your variable name is longer than 12 characters, you will require  more keystrokes to refer to the arguments themselves. In addition to this, opimisers like GZip which can give variables and arguments shorter names for compression and obfuscation purposes are likely to skip over these instances, reducing the compression capability of your code.

Refer to this post on JavaScript arguments at seifi.org for more information on the arguments object.

Special thanks to this article at Programming Goodies for highlighting this as missing from my list of JSLint Errors.

A Guide To JSLint Messages

This article is one of a series on the error and warning messages produced by JSLint.

When you explain something to someone and then ask “Does that make sense?” or “Did you understand that?”, if they answer “Sort-of” then they don’t understand it. At all.

Principles

Most developers are have instilled within themselves certain fundamental core programming practices. Possibly the most famous of these is the DRY (Don’t Repeat Yourself) Principle, which states that duplication can lead to maintenance nightmares, poor factoring, and logical contradictions.

But as with many principles in programming, there are always trade-offs, and times where the rigorous application of a principle can be unhelpful and even counter-productive.

The counterpart to DRY is WET (Write Every Time), and there are scenarios where it makes sense to duplicate code, as described in the articles: Write Every Time Dilutes performance Bottlenecks and Beware The Share.

The JSLint Error

Another principle that is preached almost religiously is the efficient management of resources, and one strategy for doing this is to allocate any resources as late as possible, and  release them as early as possible. The use of block scoping is a particularly common key for achieving this.

This gives rise to code similar to the following:

var a = 1;
if (x === a){
    var b = 2; //'try' giving variable 'b' block scope
    //do other stuff
}

In languages such as C++, C# and Java the above convention would limit the scope and lifetime of the variable ‘b’ to the ‘if’ block.

JavaScript, however, has no block scoping, and any variables declared within a block will be ‘hoisted’ to the top of the nearest scope when the code is picked up by the compiler. This is either the nearest containing function, or global scope. In short, this will make them visible outside the originally intended scope.

JSLint is all about reducing bugs, and had the author of this StackOverflow question run their code through JSLint, then they may never have had to ask a question at all.

Adding (Pseudo) Block Scoping

If you really wanted to enforce scoping down at this level then the following convention might help:

var a = 1;
if (x === a){
    (function(){
        var b = 2; //give variable 'b' (pseudo) block scope
        //do other stuff
    }());
}

Here we’ve wrapped the code in an anonymous function, and invoked it immediately (thanks to the set of parens at the end).

But JSLint Stops Scanning

Yeah, sometimes it does.

I have tried to remain neutral in all my posts on JSLint messages to date. Here, however I am going to jump off the fence and offer a sentiment of bafflement.

JSLint deems some errors so serious that it immediately ceases scanning. For me this is understandable in the event that it encounters utterly unparsable code and literally cannot continue, however, I just don’t understand why it must stop dead with the following:

for (var x=0; x<10 x++){
    //do something
}

And it appears I am not alone. A very similar query posted on the JSLint GitHub repository failed to yield any explanation before the thread was closed.

Any ideas anyone?

A Guide To JSLint Messages

This article is one of a series on the error and warning messages produced by JSLint.

DO NOT REPLY EITHER WAY – THIS IS A SCAM

URGENT! If you took out a bank loan prior to 2007 the you are almost certainly entitled to £2300 in compensation. To claim text ‘YES’. (free to reply).

Received from:

• +447522075609/07522075609

Another span tesxt message variant to look out for.

This message has surfaced in relation to the current Missold Payment Protection Insurance Ruling. The adjacent BBC article reports that several million people may be worthy of such compensation – ripe pickings for our scammers.

If you’re looking to claim back any money in relation to this, the BBC outlines a series of steps you can take personally. You can also check out the PPI reclaiming guide at moneysavingexpert.com. Ultimately, this is your money, rightfully due to you, so why waste money on an opportunistic company just looking to profit from your misfortune.

Image via Wikipedia

This is a spam text message WHICH IS ILLEGAL. The companies that use this form of marketing are equivalent to the people who buy stolen goods. These are not the sort of companies you want to do business with!

This is one of many messages that are circulating as originally highlighted in my article Debt Settlement Order Spam Text Message. If you ever receive anything that remotely fits this template then delete it.

Again, DO NOT REPLY. This is a random act of spamming – a computer program is systematically trying to send this out to thousands of numbers at random. It has, by sheer chance, found your number!

And, if you can, post the number in the comments below. This will help people searching by that number alone find this article and avoid any potential trouble arising from replying.

Also, please. please post any variants in full. I have had so many comments from people in desperate circumstances who are being targeted by the parasites that operate these scams.

Are You a Victim?

Screenchannel Television is making a new series about debt and loans and are looking for people to share their experiences. If have been a victim of this scam, or have even considered responding and are interested in taking part, then you can read more in this article.

How Does It Work?

The whole setup is quite elaborate. But in essence there is a computer program that pretends to be the number you see that sends out all the spam messages. Meanwhile, another computer program monitors the text-message mailbox of all of the numbers you see. If you reply, then you are added to a database of numbers to be called (and for future spamming).

I’ve written this up in full at: Telephony Leads and Debt Management Companies – How It Works.

Reporting

You may be report these messages to your provider. The following links may help:

Vodafone – How do I report spam text messages? Forward the spam message to VSPAM (87726).

Orange – Stop spam text messages. If you are on Orange and get spam messages, please forward them to 7726 free from your Orange phone. By doing this you are helping Orange to collate information to help reduce spam messages being sent to you and others.

02 also allow you to report on 7726. See: SPAM and unwanted subscription texts

I would also try forwarding the message onto 7726 if you are with T-Mobile or Three.

You can also try NumberCop and DoNotCall.gov

Back in May 2009, the Guardian newspaper wrote an article Spam to go – the new mobile menace. It recommends a number of organisations you can contact.

To complain about an inappropriate text, call the Advertising Standards Authority 020 7492 2222 or go to www.asa.org.uk/asa/contact/

To resolve continual mobile spam despite texting “stop”, contact the ICO on 01625 54 57 45 or go to www.ico.gov.uk/complaints.aspx

For help with premium rate text spam, call PhonepayPlus on 0800 500 212 or log on to www.phonepayplus.org.uk/output/Make-a-complaint.aspx

Periodically, I check the JSLint update history on GitHub to see what’s going on, and what significant updates have been included.

So, imagine my surprise when I saw a simple one-line comment on a June 12, 2011 edit:

eqeq

I did a quick diff on the source code to see this following line added:

 //     eqeq       true, if == should be allowed

This means that you can now configure JSLint to ignore uses of ‘==’, where previously it would have insisted you should use ‘===’

At the time of writing it hadn’t been updated on the JSLint front page, however testing locally with the following yielded no ‘==’ related warnings:

    /*jslint eqeq: true*/
    var x = 0;
    if (x == 1) {
        alert("test");
    }

I always recommend that use the ‘===’ in this instance anyway, but I am aware of the differing opinions surrounding it. Ultimately, you can make your own decision (and it is ‘on’ by default so you have to opt-out).