Sustainability Training Workshop - What makes good code good?
•Als PPT, PDF herunterladen•
1 gefällt mir•330 views
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.
![Who are you…? ,[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Mehr von Software Sustainability Institute
Mehr von Software Sustainability Institute (16)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Sustainability Training Workshop - What makes good code good?
- 1. Sustainability Training What makes good code good?
- 8. So which of them do you do?
- 9. And what are the blockers?
- 10. One for the road XKCD, 844 http://xkcd.com/844/
Hinweis der Redaktion
- 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!