Sustainability Training Workshop - What makes good code good?


Published on

Presentation by Mike Jackson, Software Architect at the Software Sustainability Institute.

Presented at the Digital Social Research: Sustainability Training Workshop at OeRC, Oxford on 12 December 2011.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Or how would we distinguish good code from bad code? Of course, we could ask 100 people this and get 100 answers but as there ’ s a group of us here we can distil out what we believe to be the answer!
  • Thanks to Google we can ask the world what it thinks and see what sorts of replies we get. For “ What makes good code good ” on 6 th May 2011 Paul DiLascia ’ s article was the top hit and it ’ s referenced by many others. How do we compare? Readability is often neglected – just because code is consumed by computers it is read, updated and changed by us!
  • And one more. This blog post started by acknowledging this is a difficult question due to code being a mix of art and science. These are in order of priority but trade-offs are possible. Note correctness, this needs requirements, specification and design For it to be testable it needs automated tests. It should be extensible, flexible and reusable so you don ’ t need to rewrite it when extending or reusing it. But one must beware of YAGNI (You Ain ’t Gonna Need It) and not waste time writing code you’ll never need.
  • From universities across the North East attended. Attendees varied both in their experience of programming and the languages they used. MATLAB was the most popular, followed by FORTRAN, C/C++, R and Python, and there were also a handful of users each of Java, Visual Basic, SQL, Smalltalk and hardware definition languages. It must do what it is intended to do and do it correctly. Without this quality, any research deriving from the code could be fundamentally flawed. The code may be worked upon by not just the original author, but others, for example research associates recruited onto a project. Similarly, the original author may need to return to the code after a long break. Source code itself says what the code does and how it does it. However, it is also important that comments be added to include design rationale, or why the code is as it is, why certain implementation decisions were taken. This can be particularly useful when these decisions might otherwise seem unconventional or non-intuitive. The code should be elegant and concise. There should be no redundant or repeated code. However, the code should not be so concise as to be so cryptic that it is very difficult to understand. The code should optimise its usage of processor, memory and storage resources. A few seconds improved run-time in a function is not necessarily worth a day of debugging if it goes wrong. The code should be well-designed and modular as this also promotes testing and code reuse. There should be tests for correctness so that both the author, and others, can have confidence that the code is fit for purpose. In addition, these tests should be shipped with the code to enable users to test their deployments, prove to themselves it works as expected and also to be able to test any changes they make. The code should be scalable and be able to handle inputs which require processing, memory or storage beyond the bounds needed by the original authors. If these bounds are reached it should fail gracefully, not just crash with a core dump. Usability is also important, the delivery of software that is easy to use. This more relates to the question "what makes good software good" than "what makes good code good" but it is beneficial to be aware that someone who is not the original author may use the software. And finally, the software should be portable. Though there may only be a need for it to run on one platform at the time of its writing, developing multi-platform software may make the software attractive to a wider number of users, or to other applications areas. Adoption of these guidelines can help scientists ensure that their code can be more than just a throwaway prototype but an asset that can continue to contribute to the evolution of both their research and that of their peers.
  • Here ’ s another set of criteria. They ’ re different ways of expressing what we ’ ve already seen. Reflects the problems it solves, little effort to understand and makes sense a year from now relate to design. Easily understood, short, little effort to understand relate to simple and readable. Loose coupling and cohesive relate to modular and layered. Note Documents requirements for usage – not much use if we can ’ t use it!
  • Sustainability Training Workshop - What makes good code good?

    1. 1. Sustainability Training What makes good code good?
    2. 2. Who are you…? <ul><li>Researchers who do some programming? </li></ul><ul><li>Research/scientific programmers? </li></ul><ul><li>Software developers? </li></ul>
    3. 3. The Question <ul><li>On 12 th December 2011, Mike of the SSI asked 6 researchers in social sciences what makes good code good… </li></ul><ul><li>And they said… </li></ul>
    4. 5. A popular view <ul><li>Simple – concise but not cryptic </li></ul><ul><li>Readable – commented, sensible names, follows conventions </li></ul><ul><li>Modular – reusable building blocks </li></ul><ul><li>Layered – application/OS, model/view/controller, … </li></ul><ul><li>Designed – “ thoughts are cheaper than debugging ” , if you can ’ t explain it easily it ’ s designed poorly </li></ul><ul><li>Efficient – fast, compact, takes only what ’ s needed + frees it when done </li></ul><ul><li>Elegant – simple + efficient + brilliant </li></ul><ul><li>Clear – all of the above are an antidote to complexity </li></ul><ul><li>Clever hacks – because the world is not perfect </li></ul>What makes good code good, Paul DiLascia, MSDN Magazine, 07/2004, p144
    5. 6. Another view <ul><li>Correct – does what it ’ s intended to do </li></ul><ul><li>Readable – remember WORM (Write Once Read Many) </li></ul><ul><li>Testable – “ if it ’ s not tested it ’ s broken ” </li></ul><ul><li>Documented – not what/how but why/because </li></ul><ul><li>Robust and reliable </li></ul><ul><li>Maintainable – by you and others six months from now </li></ul><ul><li>Extensible, flexible + reusable but beware of YAGNI! </li></ul><ul><li>Efficient, performant + scalable </li></ul><ul><li>Secure </li></ul><ul><li>Discoverable – others can understand quickly + easily </li></ul><ul><li>Simple – modular </li></ul>Bittermanandy, What is good code? , 10/09/2010
    6. 7. And one from scientists <ul><li>Fit for purpose </li></ul><ul><li>Readable, well-commented and documented, includes design rationale. </li></ul><ul><li>Elegant, concise but not needlessly cryptic </li></ul><ul><li>Well-designed and modular </li></ul><ul><li>Tests for correctness and ships tests with code </li></ul><ul><li>Optimised but not at expense of understandibility </li></ul><ul><li>Scalable </li></ul><ul><li>Usable </li></ul><ul><li>Portable </li></ul>31 “ scientists who do some programming ” on the Effective scientific programming workshop, 20/06/2011
    7. 8. So which of them do you do?
    8. 9. And what are the blockers?
    9. 10. One for the road XKCD, 844
    10. 11. Another view <ul><li>Reflects the problem it solves </li></ul><ul><li>Can be easily understood by programmers without experience in your language </li></ul><ul><li>Generally short </li></ul><ul><li>Doesn ’t require much thinking to understand </li></ul><ul><li>Very little coupling </li></ul><ul><li>Cohesive - definitions of functions + types required are not scattered throughout the software </li></ul><ul><li>Documents any requirements for proper usage </li></ul><ul><li>Makes just as much sense to you one year from now, as it does now </li></ul>Christopher Diggins, The Properties of Good Code, 27/09/2005,