I first heard about “code smells” during a session I was chairing at Dev8D 2012 on “what makes good code good?”: Ian Bayley, from Oxford Unviersity, suggested “no ‘code smells’”. I’d never heard of this term so I turned to my trusty friend Google to see what was what. Although I hadn’t heard the term before, it turns out that I knew what code smells are… source code that just looks “odd” or doesn’t feel quite right, which are signs that suggests to a developer that refactoring might be in order.

Not only were many of the smells familiar but the “deodorants” were too. For example, replacing arrays that are used as records with objects,

String[] row = new String[3];

row [0] = "Liverpool";

row [1] = "15";

can be replaced by,

Performance row = new Performance();

row.setName("Liverpool");

row.setWins("15");

Or, replacing nested conditionals with guard clauses e.g.:

double getPayAmount() {

    double result;

    if (_isDead) result = deadAmount();

    else {

        if (_isSeparated) result = separatedAmount();

        else {

            if (_isRetired) result = retiredAmount();

            else result = normalPayAmount();

        };

    }

    return result;

};

can be replaced by

double getPayAmount() {

    if (_isDead) return deadAmount();

    if (_isSeparated) return separatedAmount();

    if (_isRetired) return retiredAmount();

    return normalPayAmount();

};

The term “code smell” is attributed to Kent Beck in Martin Fowler’s book Refactoring, Improving the Design of Existing Code (Addison-Wesley, 1999, ISBN 0-201-48567-2). There are lots of online resources that will teach you how to spot smelly code and help with the deodorising so that your code ends up as pure as an Alpine breeze. As a starting point you could try Martin Fowler’s own “catalog of code smells and refactorings“, which lists both symptoms and cures, judiciously highlighted with examples. A complementary resource is Mäntylä and Lassenius’s “bad code smells taxonomy”. This groups together bad smells into a useful, recognisable and amusingly named taxonomy. As a couple of examples they have,

• The Bloaters, including long methods, large classes, long parameter lists and data clumps (sets of data like 3 integers for RGB colours which could be encapsulated).
• The Dispensables, anything which can, and should, be removed including lazy classes that don’t do enough, duplicated code, dead code and speculative generality (code which “might possibly be useful someday, maybe” but which incurs maintenance overheads).
• Other classifications are the change preventers, the couplers and the object-orientation abusers.

Another useful resource is SourceMaking’s pages on refactoring which motivates refactoring before describing many code smells and their refactorings.

Static code analysis tools such as CheckStyle or Pylint can also automatically detect (but not fix, that’s your job) code smells, and these might become a useful part of an nightly test system for your software, or part of a continuous integration server.

I hope this answers your question and the resources above will help you to write more fragrant code in future!

At the Software Sustainability Institute I’m often asked - unsurprisingly – to evaluate the sustainability of software. This typically leads to a report for the developers with observations and recommendations for improvement. Wouldn’t it be better if there was some way of evaluating your own software?

There is! Having a third-party assess the state of your software in some way, be it a colleague testing the install process and documentation to provide feedback, or having the Institute perform a full evaluation is always useful. However, developing the skill to impartially self-assess your own software is invaluable. Adopting an objective ‘green’ user or developer perspective – removing your inner assumptions and knowledge of the software from the equation – can only help your software to become better.

Not only are the Institute’s processes for evaluation available for you to use yourselves, but there is now a very helpful, lightweight and quick sustainability evaluation you can do on your own. You just fill in a simple web form with details about your software, and it returns a list of recommendations (with helpful links) on how you can improve your software. Simple! It investigates a number of key areas related to the sustainability of your software, including the processes for building and installation, documentation, availability, support, licences and source code structure, amongst many others.

You can check out this nifty evaluation resource.

Security in complex systems is always a tricky business. Consider production Grid infrastructures as an example. The intricacies of establishing working trust relationships between the users and the infrastructure, and between the systems themselves, is a mammoth task. Solving problems with such systems is also very tricky, as I’ve previously found when developing EU-wide Grid interoperability demonstrators of open standards. They appear like dragons: huge, daunting, and difficult to defeat.

The UK National Grid Service asked Steve (well, the Institute really) to help them out with their SARoNGS system. Our arrangement was very effective. The Software Sustainability Institute provided development effort for the investigation, whilst the NGS fixed issues and offered the in-depth systems knowledge that only they could provide.

So what is SARoNGS all about? The Shibboleth Access to Resources on the NGS service greatly simplifies authentication to NGS resources by accepting institutional Shibboleth credentials. It’s great for users, because they don’t need to apply for, own and use an X509 certificate. However, it appeared that the automatically generated SARoNGS certificates were being rejected by the NGS’s Workload Management Service (WMS). In short, you could no longer use SARoNGS certificates to submit jobs through the WMS without seeing a rather ominous error light up the screen:

Connection failed: CA certificate verification failed

We were warned here be dragons, but we ploughed on heedless of the danger.

You may have heard of software decay. This can occur when the environment around a piece of software changes, which leads to failures in the system as a whole. For example, an update to a dependent library or to the operating system could cause a problem. Updating one of the ubiquitous jar files in Java, only to find some of the API functions have become deprecated, can also cause grief. The good news is that there are things you can do to avoid this problem, some of which I’ve looked at already.

Security problems are often esoteric and difficult to solve. The problem could be a software dependency issue, say a newly updated security library with a bug that incorrectly interprets certificate attributes. It could also be a problem with the way in which trust relationships are defined. Sophisticated production Grid systems often trust a veritable legion of Certificate Authorities (CAs). Each CA has its own CA trust certificates, Certificate Revocation Lists (CRLs – a list of certificates not to trust) and signing policies. (I won’t get into how VOMS fits into the picture in this post, but if you’re interested, let me know.) Sorting out certificate problems can be like looking for a needle in a haystack… in a tornado. However, once identified, these issues are often easy to fix.

Systems can also fail when you haven’t changed anything at all, and this was the case with the first problem we found with SARoNGS.

Time is an important concept in security. For example, the NGS proxy certificates have a limited lifetime to reduce their vulnerability if the proxy is compromised. CRLs must also be kept up to date. The problem with expired CRLs is that they can cause the entire authentication step to fail, and this is what had happened with SARoNGS: a CRL in a critical location had expired. We updated the CRL and the first dragon lay dead on our screens!

When establishing trust in Grid systems, you need to decide which certificates to trust and where in the system to trust them. The second problem with SARoNGS was caused by two different signing policies being simultaneously. Some sites were intentionally configured to trust SARoNGS, and others were not. However, the installation of an update using the International Grid Trust Federation (IGTF) bundle meant that the UK e-Science signing policy reverted to the IGTF default: do not trust SARoNGS certificates. Again, an easy problem to fix, but a difficult one to identify. Once SARoNGS trust was reinstated in the signing policy (we used a modified NGS IGTF+ bundle) the problem was resolved and the last dragon soundly defeated.

And so the legend goes, the dragons of SARoNGS were slain. If you ever find yourself developing Grid software and run into a security brick wall, why not take a look at those conspicuous looking CRL and signing policy files? They could be dragons. And dragons need slaying!

One of the big problems with research, particularly in these austere times, is finding the money to travel to all those great conferences. You miss opportunities to present your work, and you can miss out on discovering first hand what is afoot in your research field.

The great news is that if you use software in your research and you have a good understanding of what’s happening in your field, funding is available from the Software Sustainability Institute. Regardless of discipline, the Institute will pay a number of researchers £3000 a year – in return for keeping the institute up to date on the latest developments in the researcher’s field. This helps you with disseminating your greatness and keeping up to date, while allowing the institute to build a network of Agents to understand which fields most need help.

There are some compelling benefits to consider:

• Up to £3000 a year to attend the conferences and events that you want to attend
• Your advocacy will ensure that your field benefits from the best support for software development
• Add world-leading researchers to your professional network
• Free attendance at training events for new tools and technologies
• If you develop code, improve your knowledge of effective techniques for developing sustainable software
• A great addition to your CV

Not bad eh? And you don’t have to be a professor or Principle Investigator to qualify – you just need to be in the know. The institute are looking for applicants from all disciplines, especially from those fields flagged as strategically important to UK research: the ageing population, environment and climate change, the digital economy, energy and food security.

The closing date for applications is 8th August 2011. If you’re interested, or would like to nominate someone else, why not find out more and apply at http://software.ac.uk/join-our-agents-network?

Plus, saying ‘I’m an Agent for the SSI’ sounds cool.