ArticlePDF Available

Ten recommendations for software engineering in research

Authors:

Abstract and Figures

Hastings et al. GigaScience 2014, 3:31
http://www.gigasciencejournal.com/content/3/31
COMMENTARY Open Access
Ten recommendations for software
engineering in research
Janna Hastings*, Kenneth Haug and Christoph Steinbeck
Abstract
Research in the context of data-driven science requires a backbone of well-written software, but scientific researchers
are typically not trained at length in software engineering, the principles for creating better software products. To
address this gap, in particular for young researchers new to programming, we give ten recommendations to ensure
the usability, sustainability and practicality of research software.
Keywords: Software engineering, Best practices
Background
Scientific research increasingly harnesses computing as a
platform [1], and the size, complexity, diversity and rel-
atively high availability of research datasets in a variety
of formats is a strong driver to deliver well-designed,
efficient and maintainable software and tools. As the
frontier of science evolves, new tools constantly need to
be written; however scientists, in particular early-career
researchers, might not have received training in software
engineering [2], thus their code is in jeopardy of being
difficult and costly to maintain and re-use.
To address this gap, we have compiled ten brief software
engineering recommendations.
Recommendations
1. Keep it simple
Every software project starts somewhere. A rule of thumb
is to start as simply as you possibly can.Significantlymore
problems are created by over-engineering than under-
engineering. Simplicity starts with design: a clean and ele-
gant data model is a kind of simplicity that leads naturally
to efficient algorithms.
Do the simplest thing that could possibly work, and then
double-check it really does work.
*Correspondence: hastings@ebi.ac.uk
Cheminformatics and Metabolism, European Molecular Biology Laboratory –
European Bioinformatics Institute, Wellcome Trust Genome Campus, CB10
1SD Hinxton, UK
2. Test, test, test
For objectivity, large software development efforts assign
different people to test software than those who develop
it. This is a luxury not available in most research labs,
but there are robust testing strategies available to even the
smallest project.
Unit tests are software tests which are executed auto-
matically on a regular basis. In test driven development,
the tests are written first, serving as a specification and
checking every aspect of the intended functionality as it is
developed [3]. One must make sure that unit tests exhaus-
tively simulate all possible – not only that which seems
reasonable – inputs to each method.
3.Donotrepeatyourself
Donotbetemptedtousethecopy-paste-modifycoding
technique when you encounter similar requirements.
Even though this seems to be the simplest approach, it
will not remain simple, because important lines of code
will end up duplicated. When making changes, you will
have to do them twice, taking twice as long, and you may
forget an obscure place to which you copied that code,
leaving a bug.
Automated tools, such as Simian [4], can help to detect
and fix duplication in existing codebases. To fix duplica-
tions or bugs, consider writing a library with methods that
can be called when needed.
4. Use a modular design
Modules act as building blocks that can be glued together
to achieve overall system functionality. They hide the
© 2014 Hastings et al.; licensee BioMed Central. This is an Open Access article distributed under the terms of the Creative
Commons Attribution License (http://creativecommons.org/licenses/by/4 .0), which permits unrestricted use, distribution, and
reproduction in any medium, provided the original work is properly credited. The Creative Commons Public Domain Dedication
waiver (http://creativecommons.org/publicdomain/zero /1.0/) applies to the data made available in this article, unless otherwise
stated.
Hastings et al. GigaScience 2014, 3:31 Page 2 of 4
http://www.gigasciencejournal.com/content/3/31
Figure 1 An example of incomprehensible code: What does this
code actually do? It contains a bug; is it easy to spot?
details of their implementation behind a public interface,
which provides all the methods that should be used.
Users should code – and test – to the interface rather
than the implementation [5]. Thus, concrete implemen-
tation details can change without impacting downstream
users of the module. Application programming interfaces
(APIs) can be shared between different implementation
providers.
Scrutinise modules and libraries that already exist for
the functionality you need. Do not rewrite what you can
profitably re-use – and do not be put off if the best candi-
date third-party library contains more functionality than
you need (now).
5. Involve your users
Users know what they need software to do. Let them try
the software as early as possible, and make it easy for them
to give feedback, via a mailing list or an issue tracker. In an
open source software development paradigm, your users
can become co-developers. In closed-source and commer-
cial paradigms, you can offer early-access beta releases to
atrustedgroup.
Many sophisticated methods have been developed for
user experience analysis. For example, you could hold an
interactive workshop [6].
6. Resist gold plating
Sometimes, users ask for too much, leading to fea-
ture creep or “gold plating”. Learn to tell the difference
between essential features and the long list of wishes users
may have. Prioritise aggressively with as broad a collec-
tion of stakeholders as possible, perhaps using “game-
storming” techniques [7].
Gold plating is a challenge in all phases of development,
not only in the early stages of requirements analysis. In its
most mischievous disguise, just a little something is added
in every iterative project meeting. Those little somethings
add up.
7. Document everything
Comprehensive documentation helps other developers
who may take over your code, and will also help you in
thefuture.Usecodecommentsforin-linedocumenta-
tion, especially for any technically challenging blocks, and
public interface methods. However, there is no need for
comments that mirror the exact detail of code line-by-line.
It is better to have two or three lines of code that are easy
to understand than to have one incomprehensible line, for
example see Figure 1.
Write clean code [ 8] th at you would want to maintain
long-term (Figure 2). Meaningful, readable variable and
method names are a form of documentation.
Write an easily accessible module guide for each mod-
ule, explaining the higher level view: what is the purpose
of this module? How does it fit together with other mod-
ules? How does one get started using it?
8. Avoid spaghetti
Since GOTO-like commands fell justifiably out of
favour several decades ago [9], you might believe that
spaghetti code is a thing of the past. However, a similar
phenomenon may be observed in inter-method and inter-
module relationships (see Figures 3 and 4). Debugging –
stepping through your code as it executes line by line – can
help you diagnose modern-day spaghetti code. Beware of
module designs where for every unit of functionality you
have to step through several different modules to discover
where the error is, and along the way you have long lost
the record of what the original method was actually doing
or what the erroneous input was. The use of effective
and granular logging is another way to trace and diagnose
problems with the flow through code modules.
9. Optimise last
Beware of optimising too early. Although research appli-
cations are often performance-critical, until you truly
encounter the wide range of inputs that your software
Figure 2 This code peform s the same function, but is written more clearly.
Hastings et al. GigaScience 2014, 3:31 Page 3 of 4
http://www.gigasciencejournal.com/content/3/31
Figure 3 An unhealthy module design for ‘biotool‘ with multiple interdependencies between different packages. An addition of
functionality to the system (such as supporting a new field) requires updating the software in many different places. Refactoring into a simpler
architecture would improve maintainability.
will eventually run against in the production environment,
it may not be possible to anticipate where the real bot-
tlenecks will lie. Develop the correct functionality first,
deploy it and then continuously improve it using repeated
evaluation of the system running time as a guide (while
your unit tests keep checking that the system is doing what
it should).
10. Evolution, not revolution
Maintenance becomes harder as a system gets older. Take
time on a regular basis to revisit the codebase, and con-
sider whether it can be renovated and improved [10].
However, the urge to rewrite an entire system from the
beginning should be avoided, unless it is really the only
option or the system is very small. Be pragmatic [11] – you
may never finish the rewrite [12]. This is e specially true for
systems that were written without following the preceding
recommendations.
Figure 4 The functional units from the biotool architecture can
be grouped together in a refactoring process, putting similar
functions together. The result may resemble a Model-View-Controller
architecture.
Use a good version control system (e.g., Git [13]) and a
central repository (e.g., GitHub [14]). In general, commit
early and commit often, and not only when refactoring.
Conclusion
Effective software engineering is a challenge in any enter-
prise, but may be even more so in the research context.
Among other reasons, the research context can encourage
a rapid turnover of staff, with the result that knowledge
about legacy systems is lost. There can be a shortage of
software engineering-specific training, and the “publish or
perish” culture may incentivise taking shortcuts.
Table 1 Further reading
Description URL
Software Carpentry: scientific
computing skills; learn online
or in face-to-face workshops http://software- carpentry.org/
The Software Sustainability Institute http://software.ac.uk/
Learn more about what makes
code easy to maintain http://www.thc.org/root/phun/
unmaintain.html
How to write good unit tests http://developer.salesforce.com/
page/How_to_Write_Good_
Unit_Tests
What is clean code? http://java.dzone.com/articles/
what-clean-code-%E2%80%93-
quotes
Introduction to refactoring http://sourcemaking.com/
refactoring/
The danger of premature
optimization
http://c2.com/cgi/wiki?
PrematureOptimization
This table lists additional online resources where the interested reader can learn
more about software engineering best practices in the research context.
Hastings et al. GigaScience 2014, 3:31 Page 4 of 4
http://www.gigasciencejournal.com/content/3/31
The recommendations above give a brief introduction
to established best practices in software engineering that
may serve as a useful reference. Some of these recom-
mendations may be debated in some contexts, but never-
theless are important to understand and master. To learn
more, Table 1 lists some additional online and educational
resources.
Competing interests
The authors declare that they have no competing interests.
Authors’ contributions
JH prepared the initial draft. All authors contributed to, and have read and
approved, the final version.
Acknowledgements
This commentary is based on a presentation given by JH at a workshop on
Software Engineering held at the 2014 annual Metabolomics conference in
Tsuruoka, Japan. The authors would like to thank Saravanan Dayalan for
organising the workshop and giving JH the opportunity to present. We would
furthermore like to thank Robert P. Davey and Chris Mungall for their careful
and helpful reviews of an earlier version of this manuscript.
Received: 25 September 2014 Accepted: 19 November 2014
Published: 4 December 2014
References
1. Goble C: Better software, better research. IEEE Internet Comput 2014,
18:4–8.
2. Wilson G, Aruliah DA, Brown C T, Chue Hong NP, Davis M, Guy RT, Haddock
SHD, Huff KD, Mitchell IM, Plumbley MD, Waugh B, White EP, Wilson P:
Best practices for scientific computing. PLoS Biol 2014, 12:e1001745.
3. Beck K: Test Driven Development. New York: Addison-Wesley; 2002.
4. Simian: Similarity Analyzer. [http://www.harukizaemon.com/simian/]
5. Bloch J: Effective Java. New York: Addison-Wesley; 2008.
6. Pavelin K, Pundir S, Cham JA: Ten simple rules for running interactive
workshops. PLoS Comput Biol 2014, 10:e1003485.
7. Gray D, Brown S, Macanufo J: Game-storming: A playbook for innovators
rulebreakers and changemak ers. Sebastopol, CA: O’Reilly; 2010.
8. Martin RC: Cl ean Code: A Handbook of Agile Software Craftsmanship.
New York: Prentice Hall; 2008.
9. Dijkstra EW: Letters to the editor: go to statement considered
harmful. Commun ACM 1968, 11(3):147–148.
10. Fowler M: Refactoring: Improving the Design of Existi ng Code. Reading,
Massachusetts: Addison Wesley; 1999.
11. Hunt A, Thomas D: The Pragmatic P rogrammer. Reading, Massachusetts:
Addison Wesley Longman; 2000.
12. Brooks FP: T he Mythical Man Month. New York: Addison-Wesley; 1975.
13. The Git distributed version control management system.
[http://git-scm.com/]
14. GitHub: An online collaboration p latform for Git version-controlled
projects. [http://github.com/]
doi:10.1186/2047-217X-3-31
Cite this arti cle as: Hastings et al.:Ten recommendations for software
engineering in research. GigaScience 2014 3:31.
Submit your next manuscript to BioMed Central
and take full advantage of:
Convenient online submission
Thorough peer review
No space constraints or color figure charges
Immediate publication on acceptance
Inclusion in PubMed, CAS, Scopus and Google Scholar
Research which is freely available for redistribution
Submit your manuscript at
www.biomedcentral.com/submit
... Problem Feature Implementation Stodden V, Miguez S. 22 x Fehr J, and Heiland J. 23 x Wilson G, Aruliah DA, et al. 24 x x x Wilson G, Bryan J, et al. 25 x Hastings J, Haug K, Steinbeck C. 26 x x Lee BD. 6 x x Taschuk M, Wilson G. 2 x x Sandve GK, Nekrutenko A, et al. 5 x x x Karimzadeh M, Hoffman MM. 27 x Gil Y, David CH, et al. 7 x x The recommendations focus on the open domain (see Table 5). Especially, the documentation for the shared domain is rarely mentioned. ...
... Private Shared Open Stodden V, Miguez S. 22 x x Fehr J, and Heiland J. 23 x Wilson G, Aruliah DA, et al. 24 x x Wilson G, Bryan J, et al. 25 x Hastings J, Haug K, Steinbeck C. 26 x Lee BD. 6 x Taschuk M, Wilson G. 2 x x Sandve GK, Nekrutenko A, et al. 5 x x Karimzadeh M, Hoffman MM. 27 x Gil Y, David CH, et al. 7 x In engineering science, PhD candidates usually stay round about six years, become experts in a very specific field and then leave. Successors-interested in the same topic-often do not have the chance to talk to them. ...
... Author Audience Author Audience Audience Stodden V, Miguez S. 22 x x x Fehr J, and Heiland J. 23 x x x Wilson G, Aruliah DA, et al. 24 x x Wilson G, Bryan J, et al. 25 x x Hastings J, Haug K, Steinbeck C. 26 x x x x Lee BD. 6 x x x Taschuk M, Wilson G. 2 x x x Sandve GK, Nekrutenko A, et al. 5 x x x Karimzadeh M, Hoffman MM. 27 x x x Gil Y, David CH, et al. 7 x x x ...
Preprint
Full-text available
The reuse of research software needs good documentation, however, the documentation in particular is often criticized. Especially in non-IT specific disciplines, the lack of documentation is attributed to the lack of training, the lack of time or missing rewards. This article addresses the hypothesis that scientists do document but do not know exactly what they need to document, why, and for whom. In order to evaluate the actual documentation practice of research software, we examined existing recommendations, and we evaluated their implementation in everyday practice using a concrete example from the engineering sciences and compared the findings with best practice examples. In order to get a broad overview of what documentation of research software entailed, we defined categories and used them to conduct the research. Our results show that the big picture of what documentation of research software means is missing. Recommendations do not consider the important role of developers whose documentation takes mainly place in their research articles. Moreover, we show that research software always has a history that influences the documentation.
... Tools and practices already exist that can improve the quality and efficiency of software cyber-infrastructure, and improve productivity through coordination and reuse. Practices, tools, and techniques that the software community uses routinely have begun to see uptake in the sciences, with good success (Bangerth and Heister, 2013;Turk, 2013;Hastings et al., 2014;Wilson et al., 2014;Poisot, 2015;Hwang et al., 2017;Nanthaamornphong and Carver, 2017;Scott, 2017;Taschuk and Wilson, 2017;Wilson et al., 2017;Benureau and Rougier, 2018;Bryan, 2018;Adorf et al., 2018;Lathrop et al., 2019); in Sect. 3, we describe how the CSDMS community has implemented some of these. ...
Article
Full-text available
Computational modeling occupies a unique niche in Earth and environmental sciences. Models serve not just as scientific technology and infrastructure but also as digital containers of the scientific community's understanding of the natural world. As this understanding improves, so too must the associated software. This dual nature – models as both infrastructure and hypotheses – means that modeling software must be designed to evolve continually as geoscientific knowledge itself evolves. Here we describe design principles, protocols, and tools developed by the Community Surface Dynamics Modeling System (CSDMS) to promote a flexible, interoperable, and ever-improving research software ecosystem. These include a community repository for model sharing and metadata, interface and ontology standards for model interoperability, language-bridging tools, a modular programming library for model construction, modular software components for data access, and a Python-based execution and model-coupling framework. Methods of community support and engagement that help create a community-centered software ecosystem are also discussed.
... A more complex way for RS identification than a citation form is the use of metadatasets. The Software Citation Implementation Working Group is working over several possibilities for software metadatasets 71 . The PRESOFT (Preservation for REsearch SOFTware) metadataset proposed for RS in 40 is built over the skeleton of the RS reference cards that where published between 2008 and 2013 by the PLUME project 15. ...
Preprint
Full-text available
Background: Evaluation of the quality of research software is a challenging and relevant issue, still not sufficiently addressed by the scientific community. Methods: Our contribution begins by defining, precisely but widely enough, the notions of research software and of its authors followed by a study of the evaluation issues, as the basis for the proposition of a sound assessment protocol: the CDUR procedure. Results: CDUR comprises four steps introduced as follows: Citation, to deal with correct RS identification, Dissemination, to measure good dissemination practices, Use, devoted to the evaluation of usability aspects, and Research, to assess the impact of the scientific work. Conclusions: Some conclusions and recommendations are finally included. The evaluation of research is the keystone to boost the evolution of the Open Science policies and practices. It is as well our belief that research software evaluation is a fundamental step to induce better research software practices and, thus, a step towards more efficient science.
... It is therefore essential that research software sticks to good software practices: use of version control, good documentation and compliance with coding standards. 17 If you have ever stopped to think about reproducibility and replicability, you have probably wondered how we can measure these concepts. Is a result reproducible only if exactly the same number is obtained? ...
Article
Full-text available
Statisticians play a key role in almost all scientific research. As such, they may be key to solving the reproducibility crisis. Heidi Seibold, Alethea Charlton, Anne‐Laure Boulesteix and Sabine Hoffmann urge statisticians to take an active role in promoting more credible science
... Efforts to consolidate the diversity of the ecosystem in terms of software quality will have to be implemented as community processes. Code development should adopt best practices of software engineering [10], [59]. These practices must be adapted to the needs of CMS, for instance, in regard to testing (cf. ...
Conference Paper
Many fields of science rely on software systems to answer different research questions. For valid results researchers need to trust the results scientific software produces, and consequently quality assurance is of utmost importance. In this paper we are investigating the impact of quality assurance in the domain of computational materials science (CMS). Based on our experience in this domain we formulate challenges for validation and verification of scientific software and their results. Furthermore, we describe directions for future research that can potentially help dealing with these challenges
... A more complex way for RS identification than a citation form is the use of metadatasets. The Software Citation Implementation Working Group is working over several possibilities for software metadatasets 71 . The PRESOFT (Preservation for REsearch SOFTware) metadataset proposed for RS in 40 is built over the skeleton of the RS reference cards that where published between 2008 and 2013 by the PLUME project 15. ...
Article
Full-text available
Background: Evaluation of the quality of research software is a challenging and relevant issue, still not sufficiently addressed by the scientific community. Methods: Our contribution begins by defining, precisely but widely enough, the notions of research software and of its authors followed by a study of the evaluation issues, as the basis for the proposition of a sound assessment protocol: the CDUR procedure. Results: CDUR comprises four steps introduced as follows: C itation, to deal with correct RS identification, D issemination, to measure good dissemination practices, U se, devoted to the evaluation of usability aspects, and R esearch, to assess the impact of the scientific work. Conclusions: Some conclusions and recommendations are finally included. The evaluation of research is the keystone to boost the evolution of the Open Science policies and practices. It is as well our belief that research software evaluation is a fundamental step to induce better research software practices and, thus, a step towards more efficient science.
... See for example the Directive 2009/24/EC of the European Parliament and of the Council from 23 April 2009 on the legal protection of computer programs, https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX%3A32009L002466 Please note that no license means All rights reserved. ...
Article
Full-text available
Background: Evaluation of the quality of research software is a challenging and relevant issue, still not sufficiently addressed by the scientific community. Methods: Our contribution begins by defining, precisely but widely enough, the notions of research software and of its authors followed by a study of the evaluation issues, as the basis for the proposition of a sound assessment protocol: the CDUR procedure. Results: CDUR comprises four steps introduced as follows: C itation, to deal with correct RS identification, D issemination, to measure good dissemination practices, U se, devoted to the evaluation of usability aspects, and R esearch, to assess the impact of the scientific work. Conclusions: Some conclusions and recommendations are finally included. The evaluation of research is the keystone to boost the evolution of the Open Science policies and practices. It is as well our belief that research software evaluation is a fundamental step to induce better research software practices and, thus, a step towards more efficient science.
... Efforts to consolidate the diversity of the ecosystem in terms of software quality will have to be implemented as community processes. Code development should adopt best practices of software engineering [10], [59]. These practices must be adapted to the needs of CMS, for instance, in regard to testing (cf. ...
Preprint
Many fields of science rely on software systems to answer different research questions. For valid results researchers need to trust the results scientific software produces, and consequently quality assurance is of utmost importance. In this paper we are investigating the impact of quality assurance in the domain of computational materials science (CMS). Based on our experience in this domain we formulate challenges for validation and verification of scientific software and their results. Furthermore, we describe directions for future research that can potentially help dealing with these challenges.
Article
Full-text available
The reuse of research software needs good documentation, however, the documentation in particular is often criticized. Especially in non-IT specific disciplines, the lack of documentation is attributed to the lack of training, the lack of time or missing rewards. This article addresses the hypothesis that scientists do document but do not know exactly what they need to document, why, and for whom. In order to evaluate the actual documentation practice of research software, we examined existing recommendations, and we evaluated their implementation in everyday practice using a concrete example from the engineering sciences and compared the findings with best practice examples. To get a broad overview of what documentation of research software entailed, we defined categories and used them to conduct the research. Our results show that the big picture of what documentation of research software means is missing. Recommendations do not consider the important role of researchers, who write research software, whose documentation takes mainly place in their research articles. Moreover, we show that research software always has a history that influences the documentation.
Article
Full-text available
Most bioinformatics tools available today were not written by professional software developers, but by people that wanted to solve their own problems, using computational solutions and spending the minimum time and effort possible, since these were just the means to an end. Consequently, a vast number of software applications are currently available, hindering the task of identifying the utility and quality of each. At the same time, this situation has hindered regular adoption of these tools in clinical practice. Typically, they are not sufficiently developed to be used by most clinical researchers and practitioners. To address these issues, it is necessary to re-think how biomedical applications are built and adopt new strategies that ensure quality, efficiency, robustness, correctness and reusability of software components. We also need to engage end-users during the development process to ensure that applications fit their needs. In this review, we present a set of guidelines to support biomedical software development, with an explanation of how they can be implemented and what kind of open-source tools can be used for each specific topic.
Article
Full-text available
Do you have a difficult problem to solve? Are you writing a grant proposal involving several stakeholders? Do you want to gather user feedback on a resource, tool, or service? Or perhaps you need to improve a process or way of working in a team? To address problems such as these, we recommend holding an interactive workshop. We find that the dynamic nature of such workshops encourages creative thought and can quickly yield ideas and solutions [1]. Our ten simple rules aim to empower you to design and lead your own successful interactive workshops. We define an “interactive workshop” as a structured set of facilitated activities for groups of participants who work together to explore a problem and its solutions, over a specific period of time, in one location. Participants can be users, potential users, team members, customers, or stakeholders. Figure 1 shows a typical layout; note if you have five or fewer participants, consider having just one group. Figure 1 Example room layout for an interactive workshop. An interactive workshop is distinct from a standard meeting because it aims to stimulate creativity through collaborative working. A meeting, in contrast, usually involves planning and reporting work with attendees sharing their individual points; it does not involve group activities “live” in the meeting. Also, meetings may be an hour or less, whereas the minimum time needed for an interactive workshop is 2–3 hours. We also do not include training workshops, talks, or seminars in our definition, because from our experience they tend to comprise lectures and tutorials, not brainstorming activities. However, it could be possible to have an interactive workshop session as part of a longer training course.
Article
Full-text available
Scientists spend an increasing amount of time building and using software. However, most scientists are never taught how to do this efficiently. As a result, many are unaware of tools and practices that would allow them to write more reliable and maintainable code with less effort. We describe a set of best practices for scientific software development that have solid foundations in research and experience, and that improve scientists’ productivity and the reliability of their software.
Article
Modern scientific research isn't possible without software. However, its vital role is often overlooked by funders, universities, assessment committees, and even the research community itself. This is a serious issue that needs urgent attention. This article raises a number of points concerning quality, code review, and openness; development practices and training in scientific computing; career recognition of research software engineers; and sustainability models for funding scientific software. We must get software recognized to be the first-class experimental scientific instrument that it is and get "better software for better research."
Article
Even bad code can function. But if code isnt clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesnt have to be that way.Noted software expert Robert C. Martin, presents a revolutionary paradigm with Clean Code: A Handbook of Agile Software Craftsmanship. Martin, who has helped bring agile principles from a practitioners point of view to tens of thousands of programmers, has teamed up with his colleagues from Object Mentor to distill their best agile practice of cleaning code on the fly into a book that will instill within you the values of software craftsman, and make you a better programmerbut only if you work at it.What kind of work will you be doing? Youll be reading codelots of code. And you will be challenged to think about whats right about that code, and whats wrong with it. More importantly you will be challenged to reassess your professional values and your commitment to your craft. Clean Code is divided into three parts. The first describes the principles, patterns, and practices of writing clean code. The second part consists of several case studies of increasing complexity. Each case study is an exercise in cleaning up codeof transforming a code base that has some problems into one that is sound and efficient. The third part is the payoff: a single chapter containing a list of heuristics and smells gathered while creating the case studies. The result is a knowledge base that describes the way we think when we write, read, and clean code.Readers will come away from this book understandingHow to tell the difference between good and bad codeHow to write good code and how to transform bad code into good codeHow to create good names, good functions, good objects, and good classesHow to format code for maximum readability How to implement complete error handling without obscuring code logicHow to unit test and practice test-driven developmentWhat smells and heuristics can help you identify bad codeThis book is a must for any developer, software engineer, project manager, team lead, or systems analyst with an interest in producing better code.
Chapter
Wer dieses Buch liest, lernt: die Anwender zu begeistern, die echten Anforderungen zu finden, den Verfall von Software zu bekämpfen, gegen Redundanz anzugehen, dynamischen und anpassbaren Quelltext zu schreiben, effektiv zu testen, Teams von Pragmatischen Programmierern zu bilden und durch Automatisierung sorgfältiger zu entwickeln. Zunehmende Spezialisierung und Technisierung verstellen den Softwareentwicklern oft den Blick auf das Wesentliche: Anforderungen in ein funktionierendes und wartbares Programm zu überführen, das die Anwender begeistert. Der Pragmatische Programmierer rückt dies wieder in den Mittelpunkt. Egal ob Einsteiger, erfahrener Programmierer oder Projektmanager: Wer die Tipps täglich anwendet, wird seine Produktivität, Genauigkeit und Zufriedenheit bei der Arbeit rasch steigern und legt damit die Basis für den langfristigen Erfolg als Pragmatischer Programmierer.
Conference Paper
Almost every expert in Object-Oriented Development stresses the importance of iterative development. As you proceed with the iterative development, you need to add function to the existing code base. If you are really lucky that code base is structured just right to support the new function while still preserving its design integrity. Of course most of the time we are not lucky, the code does not quite fit what we want to do. You could just add the function on top of the code base. But soon this leads to applying patch upon patch making your system more complex than it needs to be. This complexity leads to bugs, and cripples your productivity.
Article
For a number of years I have been familiar with the observation that the quality of programmers is a decreasing function of the density of go to statements in the programs they produce. More recently I discovered why the use of the go to statement has such disastrous effects, and I became convinced that the go to statement should be abolished from all “higher level” programming languages (i.e. everything except, perhaps, plain machine code). At that time I did not attach too much importance to this discovery; I now submit my considerations for publication because in very recent discussions in which the subject turned up, I have been urged to do so.