- •Table of Contents
- •About the Author
- •About the Technical Reviewer
- •Acknowledgments
- •Software Entropy
- •Clean Code
- •C++11: The Beginning of a New Era
- •Who This Book Is For
- •Conventions Used in This Book
- •Sidebars
- •Notes, Tips, and Warnings
- •Code Samples
- •Coding Style
- •C++ Core Guidelines
- •Companion Website and Source Code Repository
- •UML Diagrams
- •The Need for Testing
- •Unit Tests
- •What About QA?
- •Rules for Good Unit Tests
- •Test Code Quality
- •Unit Test Naming
- •Unit Test Independence
- •One Assertion per Test
- •Independent Initialization of Unit Test Environments
- •Exclude Getters and Setters
- •Exclude Third-Party Code
- •Exclude External Systems
- •What Do We Do with the Database?
- •Don’t Mix Test Code with Production Code
- •Tests Must Run Fast
- •How Do You Find a Test’s Input Data?
- •Equivalence Partitioning
- •Boundary Value Analysis
- •Test Doubles (Fake Objects)
- •What Is a Principle?
- •KISS
- •YAGNI
- •It’s About Knowledge!
- •Building Abstractions Is Sometimes Hard
- •Information Hiding
- •Strong Cohesion
- •Loose Coupling
- •Be Careful with Optimizations
- •Principle of Least Astonishment (PLA)
- •The Boy Scout Rule
- •Collective Code Ownership
- •Good Names
- •Names Should Be Self-Explanatory
- •Use Names from the Domain
- •Choose Names at an Appropriate Level of Abstraction
- •Avoid Redundancy When Choosing a Name
- •Avoid Cryptic Abbreviations
- •Avoid Hungarian Notation and Prefixes
- •Avoid Using the Same Name for Different Purposes
- •Comments
- •Let the Code Tell the Story
- •Do Not Comment Obvious Things
- •Don’t Disable Code with Comments
- •Don’t Write Block Comments
- •Don’t Use Comments to Substitute Version Control
- •The Rare Cases Where Comments Are Useful
- •Documentation Generation from Source Code
- •Functions
- •One Thing, No More!
- •Let Them Be Small
- •“But the Call Time Overhead!”
- •Function Naming
- •Use Intention-Revealing Names
- •Parameters and Return Values
- •Avoid Flag Parameters
- •Avoid Output Parameters
- •Don’t Pass or Return 0 (NULL, nullptr)
- •Strategies for Avoiding Regular Pointers
- •Choose simple object construction on the stack instead of on the heap
- •In a function’s argument list, use (const) references instead of pointers
- •If it is inevitable to deal with a pointer to a resource, use a smart one
- •If an API returns a raw pointer...
- •The Power of const Correctness
- •About Old C-Style in C++ Projects
- •Choose C++ Strings and Streams over Old C-Style char*
- •Use C++ Casts Instead of Old C-Style Casts
- •Avoid Macros
- •Managing Resources
- •Resource Acquisition Is Initialization (RAII)
- •Smart Pointers
- •Unique Ownership with std::unique_ptr<T>
- •Shared Ownership with std::shared_ptr<T>
- •No Ownership, but Secure Access with std::weak_ptr<T>
- •Atomic Smart Pointers
- •Avoid Explicit New and Delete
- •Managing Proprietary Resources
- •We Like to Move It
- •What Are Move Semantics?
- •The Matter with Those lvalues and rvalues
- •rvalue References
- •Don’t Enforce Move Everywhere
- •The Rule of Zero
- •The Compiler Is Your Colleague
- •Automatic Type Deduction
- •Computations During Compile Time
- •Variable Templates
- •Don’t Allow Undefined Behavior
- •Type-Rich Programming
- •Know Your Libraries
- •Take Advantage of <algorithm>
- •Easier Parallelization of Algorithms Since C++17
- •Sorting and Output of a Container
- •More Convenience with Ranges
- •Non-Owning Ranges with Views
- •Comparing Two Sequences
- •Take Advantage of Boost
- •More Libraries That You Should Know About
- •Proper Exception and Error Handling
- •Prevention Is Better Than Aftercare
- •No Exception Safety
- •Basic Exception Safety
- •Strong Exception Safety
- •The No-Throw Guarantee
- •An Exception Is an Exception, Literally!
- •If You Can’t Recover, Get Out Quickly
- •Define User-Specific Exception Types
- •Throw by Value, Catch by const Reference
- •Pay Attention to the Correct Order of Catch Clauses
- •Interface Design
- •Attributes
- •noreturn (since C++11)
- •deprecated (since C++14)
- •nodiscard (since C++17)
- •maybe_unused (since C++17)
- •Concepts: Requirements for Template Arguments
- •The Basics of Modularization
- •Criteria for Finding Modules
- •Focus on the Domain of Your Software
- •Abstraction
- •Choose a Hierarchical Decomposition
- •Single Responsibility Principle (SRP)
- •Single Level of Abstraction (SLA)
- •The Whole Enchilada
- •Object-Orientation
- •Object-Oriented Thinking
- •Principles for Good Class Design
- •Keep Classes Small
- •Open-Closed Principle (OCP)
- •A Short Comparison of Type Erasure Techniques
- •Liskov Substitution Principle (LSP)
- •The Square-Rectangle Dilemma
- •Favor Composition over Inheritance
- •Interface Segregation Principle (ISP)
- •Acyclic Dependency Principle
- •Dependency Inversion Principle (DIP)
- •Don’t Talk to Strangers (The Law of Demeter)
- •Avoid Anemic Classes
- •Tell, Don’t Ask!
- •Avoid Static Class Members
- •Modules
- •The Drawbacks of #include
- •Three Options for Using Modules
- •Include Translation
- •Header Importation
- •Module Importation
- •Separating Interface and Implementation
- •The Impact of Modules
- •What Is Functional Programming?
- •What Is a Function?
- •Pure vs Impure Functions
- •Functional Programming in Modern C++
- •Functional Programming with C++ Templates
- •Function-Like Objects (Functors)
- •Generator
- •Unary Function
- •Predicate
- •Binary Functors
- •Binders and Function Wrappers
- •Lambda Expressions
- •Generic Lambda Expressions (C++14)
- •Lambda Templates (C++20)
- •Higher-Order Functions
- •Map, Filter, and Reduce
- •Filter
- •Reduce (Fold)
- •Fold Expressions in C++17
- •Pipelining with Range Adaptors (C++20)
- •Clean Code in Functional Programming
- •The Drawbacks of Plain Old Unit Testing (POUT)
- •Test-Driven Development as a Game Changer
- •The Workflow of TDD
- •TDD by Example: The Roman Numerals Code Kata
- •Preparations
- •The First Test
- •The Second Test
- •The Third Test and the Tidying Afterward
- •More Sophisticated Tests with a Custom Assertion
- •It’s Time to Clean Up Again
- •Approaching the Finish Line
- •Done!
- •The Advantages of TDD
- •When We Should Not Use TDD
- •TDD Is Not a Replacement for Code Reviews
- •Design Principles vs Design Patterns
- •Some Patterns and When to Use Them
- •Dependency Injection (DI)
- •The Singleton Anti-Pattern
- •Dependency Injection to the Rescue
- •Adapter
- •Strategy
- •Command
- •Command Processor
- •Composite
- •Observer
- •Factories
- •Simple Factory
- •Facade
- •The Money Class
- •Special Case Object (Null Object)
- •What Is an Idiom?
- •Some Useful C++ Idioms
- •The Power of Immutability
- •Substitution Failure Is Not an Error (SFINAE)
- •The Copy-and-Swap Idiom
- •Pointer to Implementation (PIMPL)
- •Structural Modeling
- •Component
- •Interface
- •Association
- •Generalization
- •Dependency
- •Template and Template Binding
- •Behavioral Modeling
- •Activity Diagram
- •Action
- •Control Flow Edge
- •Other Activity Nodes
- •Sequence Diagram
- •Lifeline
- •Message
- •State Diagram
- •State
- •Transitions
- •External Transitions
- •Internal Transitions
- •Trigger
- •Stereotypes
- •Bibliography
- •Index
Bibliography
[Abrahams98] David Abrahams. “Exception-Safety in Generic Components.” Appeared in “Selected Papers from the International Seminar on Generic Programming’
(pp 69–79), Proceedings of the ACM. Springer, 1998.
[Beck01] Kent Beck, Mike Beedle, Arie van Bennekum, et al. “Manifesto for Agile Software Development.” 2001. http://agilemanifesto.org, retrieved 3-21-2021.
[Beck02] Kent Beck. Test-Driven Development: By Example. Addison-Wesley Professional, 2002.
[Beizer90] Boris Beizer. Software Testing Techniques (2nd Edition). Itp – Media, 1990. [Busch96] Frank Buschmann, Regine Meunier, Hans Rohnert, and Peter Sommerlad.
Pattern-Oriented Software Architecture Volume 1: A System of Patterns. Wiley, 1996. [Cohn09] Mike Cohn. Succeeding with Agile: Software Development Using Scrum (1st Edition). Addison-Wesley, 2009.
[Cppcore21] Bjarne Stroustrup, Herb Sutter. C++ Core Guidelines. https://isocpp. github.io/CppCoreGuidelines/CppCoreGuidelines.html, retrieved 3-21-2021.
[Evans04] Eric J. Evans. Domain-Driven Design: Tackling Complexity in the Heart of Software (1st Edition). Addison-Wesley, 2004.
[Feathers07] Michael C. Feathers. Working Effectively with Legacy Code.
Addison-Wesley, 2007.
[Fernandes12] R. Martinho Fernandes. “Rule of Zero.” https://github.com/ rmartinho/flamingdangerzone/blob/master/_posts/cxx11/2012-08-15-rule-of- zero.md, retrieved 3-22-2021.
[Fowler02] Martin Fowler. Patterns of Enterprise Application Architecture. AddisonWesley, 2002.
[Fowler03] Martin Fowler. “Anemic Domain Model.” November 2003. https://martinfowler.com/bliki/AnemicDomainModel.html, retrieved 5-1-2017.
[Fowler04] Martin Fowler. “Inversion of Control Containers and the Dependency Injection Pattern.” January 2004. https://martinfowler.com/articles/injection. html, retrieved 7-19-2017.
477
© Stephan Roth 2021
S. Roth, Clean C++20, https://doi.org/10.1007/978-1-4842-5949-8
BIBLIOGRAPHY
[Gamma95] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.
Design Patterns: Elements of Reusable, Object-Oriented Software. Addison-Wesley, 1995. [GAOIMTEC92] United States General Accounting Office. GAO/IMTEC-92-26:
“Patriot Missile Defense: Software Problem Led to System Failure at Dhahran, Saudi Arabia,” 1992. https://www.gao.gov/products/imtec-92-26, retrieved 3-22-2021.
[Hunt99] Andrew Hunt, David Thomas. The Pragmatic Programmer: From Journeyman to Master. Addison-Wesley, 1999.
[InformIT09] Larry O’Brien. “Design Patterns 15 Years Later: An Interview with Erich Gamma, Richard Helm, and Ralph Johnson.” InformIT/Pearson Education, 2009. https://www.informit.com/articles/article.aspx?p=1404056, retrieved 3-22-2021
[ISO11] International Standardization Organization (ISO), JTC1/SC22/WG21 (The C++ Standards Committee). ISO/IEC 14882:2011, Standard for Programming Language C++.
[ISO14] International Standardization Organization (ISO), JTC1/SC22/WG21 (The C++ Standards Committee). ISO/IEC 14882:2014, Standard for Programming Language C++.
[ISO17] International Standardization Organization (ISO), JTC1/SC22/WG21 (The C++ Standards Committee). ISO/IEC 14882:2017, Standard for Programming Language C++.
[ISO20] International Standardization Organization (ISO), JTC1/SC22/WG21 (The C++ Standards Committee). ISO/IEC 14882:2020, Standard for Programming Language C++.
[Jain15] Naveen Jain. Naveen Jain Blog: “Why You Should Always Bet on Dreams, Not Experts.” http://www.naveenjain.com/why-you-should-always-bet-on-dreams-not- experts/, retrieved 3-22-2021.
[Jeffries98] Ron Jeffries. “You’re NOT Gonna Need It!” http://ronjeffries.com/ xprog/articles/practices/pracnotneed/, retrieved 3-21-2021.
[JPL99] NASA Jet Propulsion Laboratory (JPL). “Mars Climate Orbiter Team Finds Likely Cause of Loss.” September 1999. https://solarsystem.nasa.gov/news/156/ mars-climate-orbiter-team-finds-likely-cause-of-loss/, retrieved 3-22-2021.
[Knuth74] Donald E. Knuth. “Structured Programming with Go To Statements.”
ACM Journal Computing Surveys, 6 (4), December 1974. https://dl.acm.org/ doi/10.1145/356635.356640, retrieved 3-22-2021.
478
BIBLIOGRAPHY
[Koenig01] Andrew Koenig and Barbara E. Moo. “C++ Made Easier: The Rule of Three.” June 2001. http://www.drdobbs.com/c-made-easier-the-rule-of- three/184401400, retrieved 3-22-2021.
[Langr13] Jeff Langr. Modern C++ Programming with Test-Driven Development: Code Better, Sleep Better. Pragmatic Bookshelf, 2013.
[Liskov94] Barbara H. Liskov and Jeanette M. Wing. “A Behavioral Notion of Subtyping.” ACM Transactions on Programming Languages and Systems
(TOPLAS), 16 (6): 1811–1841. November 1994. http://dl.acm.org/citation. cfm?doid=197320.197383, retrieved 12-30-2014.
[Martin03] Robert C. Martin. Agile Software Development: Principles, Patterns, and Practices. Prentice Hall, 2003.
[Meyers05] Scott Meyers. Effective C++: 55 Specific Ways to Improve Your Programs and Designs (Third Edition). Addison-Wesley, 2005.
[Nygard18] Michael T. Nygard. Release It!: Design and Deploy Production-Ready Software (2nd Edition). O'Reilly UK Ltd., 2018.
[OMG17] Object Management Group. OMG Unified Modeling Language (OMG UML), Version 2.5.1. OMG Document Number: formal/17-12-05. http://www.omg.org/ spec/UML/2.5.1, retrieved 3-22-2021.
[Parnas07] ACM Special Interest Group on Software Engineering: ACM Fellow Profile of David Lorge Parnas. http://www.sigsoft.org/SEN/parnas.html, retrieved 9-24-2016.
[Ram03] Stefan Ram. Dr. Alan Kay on the Meaning of “Object-Oriented Programming.” http://www.purl.org/stefan_ram/pub/doc_kay_oop_en, retrieved 3-22-2021.
[Rivera19] Rene Rivera. “C++ Tooling Statistics: Are Modules Fast?” February 2019. https://www.bfgroup.xyz/cpp_tooling_stats/modules/modules_perf_D1441R1. html, retrieved 3-21-2021.
[Sommerlad13] Peter Sommerlad. “Meeting C++ 2013: Simpler C++ with C++11/14.” November 2013. http://wiki.hsr.ch/PeterSommerlad/files/MeetingCPP2013_ SimpleC++.pdf, retrieved 1-2-2014.
[Stroustrup16] Bjarne Stroustrup. “C++11 – The New ISO C++ Standard.” September 2016. https://www.stroustrup.com/C++11FAQ.html, retrieved 3-21-2021.
[Sutter04] Herb Sutter. “The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software.” http://www.gotw.ca/publications/concurrency-ddj.htm, retrieved 3-21-2021.
479
BIBLIOGRAPHY
[Thought08] ThoughtWorks, Inc. (multiple authors). The ThoughtWorks Anthology: Essays on Software Technology and Innovation. Pragmatic Bookshelf, 2008.
[Wipo1886] World Intellectual Property Organization (WIPO): Berne Convention for the Protection of Literary and Artistic Works. https://www.wipo.int/treaties/en/ip/ berne/index.html, retrieved 3-22-2021.
480