Good-Programming-Practices

First of all, a few very important related topics (at least to me):

• Manifesto for Agile Software Development (AKA “the Agile Manifesto”)

  • The Four Values of the Agile Manifesto
  • The Twelve Principles of the Agile Manifesto

• Servant leadership philosophy (article in the Expert Program Management site)

• Avoiding a low bus factor

Some great reminders:

• On Professionalism:

  • “Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best.” -- Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

  • “We feel that there is no point in developing software unless you care about doing it well.” -- Andrew Hunt, David Thomas, The Pragmatic Programmer: From Journeyman to Master

• On Bad Code and Good Code:

  • “It was the bad code that brought the company down.” -- Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship
  • “Code is like humor. When you have to explain it, it’s bad.” -- Cory House
  • “... good code matters ...” -- Kent Beck, Implementation Patterns

• On Technical Debt:

  • “Later equals never.” -- LeBlanc’s law.

• On Performance Management Objectives:

  • “Measuring programming progress by lines of code is like measuring aircraft building progress by weight.” -- Bill Gates

Software Quality

• Wikipedia entry on Software quality

Principles of Software Development

• From STUPID code to SOLID code (slides by William Durand)

  • STUPID code

    • S: Singleton > I.3: Avoid singletons
    • T: Tight Coupling
    • U: Untestability
    • P: Premature Optimization
    • I: Indescriptive Naming (and just Naming, for that matter)

      “Choosing good names takes time but saves more than it takes. So take care with your names and change them when you find better ones.” -- Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

      “You should name a variable using the same care with which you name a first-born child.” -- James O. Coplien, in the Foreword of Robert C. Martin’s Clean Code: A Handbook of Agile Software Craftsmanship

    • D: Duplication, also known as WET (We Edit Terribly, We Enjoy Typing...) vs the recommended DRY (Don’t Repeat Yourself)

  • SOLID code

    Acronym for five design principles intended to make software designs more understandable, flexible and maintainable.

    • S: Single responsibility principle

      A class should have only a single responsibility (i.e. changes to only one part of the software’s specification should be able to affect the specification of the class).

      [...] The reason it is important to keep a class focused on a single concern is that it makes the class more robust.

      Another way to think of SRP: Gather together things that change for the same reasons and at the same times. Separate things that change for different reasons or at different times. [A tweet by @unclebobmartin on July 29, 2018]

    • O: Open/closed principle

      “Software entities ... should be open for extension, but closed for modification.”

    • L: Liskov substitution principle

      “Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.”

    • I: Interface segregation principle

      “Many client-specific interfaces are better than one general-purpose interface.”

    • D: Dependency inversion principle

      One should “depend upon abstractions, [not] concretions”

• DAMP (Descriptive And Meaningful Phrases) vs DRY (Don’t Repeat Yourself) in unit tests

• KISS (Keep It Simple, Stupid) principle

• OAOO (Once and Only Once) principle

• Principle of Least Astonishment

• Principle of Least Privilege: From TrueScript’s Variable Declarations: “Applying the principle of least privilege, all declarations other than those you plan to modify should use const.”

• YAGNI (You Aren’t Gonna Need It) principle, a principle of XP

Rules

• The Boy Scout rule: “Leave your code better than you found it.” You can also check the Boy Scout rule in coding, in the context of Clean Code.

Guidelines, Best Practices, and Coding Standards

C++

• C++ Core Guidelines, an open source project on GitHub, led by Bjarne Stroustrup, to build modern authoritative guidelines for writing C++ code
  • Kate Gregory, 10 Core Guidelines You Need to Start Using Now (talk), CppCon 2017
    1. C.45: Don’t define a default constructor that only initializes data members; use in-class member initializers instead, and C.48: Prefer in-class initializers to member initializers in constructors for constant initializers
    2. F.51: Where there is a choice, prefer default arguments over overloading
    3. C.47: Define and initialize member variables in the order of member declaration
    4. I.23: Keep the number of function arguments low
    5. ES.50: Don’t cast away const
    6. I.11: Never transfer ownership by a raw pointer (T*) or reference (T&)
    7. F.21: To return multiple “out” values, prefer returning a tuple or struct
    8. Enum.3: Prefer enum classes over “plain” enums
    9. I.12: Declare a pointer that must not be null as not_null
    10. ES.46: Avoid lossy (narrowing, truncating) arithmetic conversions
  • My own incomplete list of selected guidelines:
    • On constness: ES.25: Declare an object const or constexpr unless you want to modify its value later on
    • On pointers: ES.24: Use a unique_ptr<T> to hold pointers
    • On reducing verbosity: T.44: Use function templates to deduce class template argument types (where feasible)
• cppbestpractices, a Collaborative Collection of C++ Best Practices, led by Jason Turner
• Herb Sutter, Andrei Alexandrescu, C++ Coding Standards: 101 Rules, Guidelines, and Best Practices, Addison Wesley Professional, 2004
• LLVM Coding Standards
• JUCE Coding Standards
• Comments:
  • “The proper use of comments is to compensate for our failure to express ourself in code.” -- Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship
  • “Don’t comment bad code—rewrite it.” -- Brian W. Kernighan and P. J. Plaugher, The Elements of Programming Style
  • Coding Without Comments article by Jeff Atwood (from his computer programming blog Coding Horror)

Python

• PEP 8 – Style Guide for Python Code

Unit Testing

• “Code, without tests, is not clean.” -- Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

Frameworks

• List of unit testing frameworks
• Google Mock (gMock), the Google C++ mocking framework
  • googlemock repo
  • README.md
  • Cheat Sheet
  • Cook Book
• GUnit, Google.Test/Google.Mock/Cucumber on steroids on steroids, by Kris Jusiak

Criticism

• Peter Sommerlad, Mocking Frameworks considered harmful (talk), CppCon 2017

Principles+

• Given-When-Then (GWT), Four-Phase Test, Arrange-Act-Assert (AAA)

  • From Martin Fowler’s article:

    It’s an approach developed by Dan North and Chris Matts as part of BDD. [...] You can also look at it as a reformulation of the Four-Phase Test pattern.

    Four-Phase Test pattern: 1. Setup 2. Execute 3. Check 4. Teardown

    	GWT	Four Ph.	AAA
    1	Given	Setup	Arrange
    2	When	Execute	Act
    3	Then	Check	Assert
    4		Teardown

  • Example of the naming convention introduced to me by Angel Costela: Given_state_A_When_B_happens_Then_these_conditions_must_be_met()

  • Example (written as pseudo-code):

    void Given_state_A_When_B_happens_Then_these_conditions_must_be_met() {
      set_state_A();                      // Given | Setup    | Arrange
      B();                                // When  | Execute  | Act
      assert(condition_1 and condition2); // Then  | Check    | Assert
      ;                                   //       | Teardown |
    }

• From C++Now 2017, Kris Jusiak’s “Towards Painless Testing” (video) (published on Jun 13, 2017)

Patterns

Some software design patterns:

• Adapter

  ... is a software design pattern (also known as Wrapper, an alternative naming shared with the Decorator pattern) that allows the interface of an existing class to be used as another interface. It is often used to make existing classes work with others without modifying their source code.

On bugs

Since the cost of fixing a software bug soars depending on how far in the software development life cycle it is found. We should then try to locate them as sooner as possible.

Some of the most nefarious bugs we might find are heisenbugs and those caused by code with undefined behavior.

First and foremost: Compilers and static analyzers are our friends

Compilers, not compiler

Zero compiler warnings policy

The first tool against software bugs, perhaps right after writing clean code, and right before using static analyzers, should be using adequate compiler(s) warning flags, and achieving zero warnings. During my career I’ve suffered time and again bugs in production very hard to pinpoint that could have been eradicated simply by taking care of compiler warnings. This has a high cost in time and money, in addition to experiencing a high level of frustration.

It is important to point out that the goal is not simply “get rid of the warning” (or, in other words, “satisfy the compiler”), but to actually fix the code. In the past I’ve seen “fixes” to satisfy the compiler that actually introduced bugs--not a good tradeoff!

Preventive coding

Whenever possible, take advantage of static assertions to discover coding problems at the compilation stage. In C++ I’m also an advocate of extensive use of the keyword const (ES.25), and, from C++11, forbid NULL favoring nullptr instead (ES.47).

Static analyzers

I’m a huge fan of Cppcheck, since it has helped me identifying coding bugs which could have slipped through. These coding bugs were sometimes, but not always, also detected by the compiler as warnings or even errors! Another helping tool you might consider using is SonarLint.

• List of tools for static code analysis

Code Reviews

(c) 2008 Focus Shift/OSNews/Thom Holwerda

Code reviews represent opportunities to learn and share good stuff from the C++ Core Guidelines.

The aim of the guidelines is to help people to use modern C++ effectively. By “modern C++” we mean C++11, C++14, and C++17.

Incomplete list of favorite gurus

Sort of alphabetically sorted:

• Andrei Alexandrescu @incomputable
• Andrew Hunt, Andy Hunt @PragmaticAndy
• Andrew Sutton: asutton
• Bjarne Stroustrup @stroustrup
• Dave Thomas @pragdave
• Herb Sutter @herbsutter
• Jeff Atwood @codinghorror · Coding Horror blog
• Jason Turner: @lefticus lefticus
• Kate Gregory @gregcons
• Kent Beck @KentBeck
• Krzysztof/Kris Jusiak: @krisjusiak krzysztof-jusiak, kris.jusiak.net
• Martin Fowler @martinfowler
• Michael Feathers @mfeathers
• Nicolai Josuttis @NicoJosuttis
• Robert C. Martin @unclebobmartin | Clean Code Collection quotes (from Clean Code plus Clean Coder)
• Ron Jeffries @RonJeffries
• Scott Meyers aristeia.com
• Ward Cunningham @WardCunningham

List of selected great books

• Andrew Hunt and David Thomas, The Pragmatic Programmer, From Journeyman To Master
• Martin Fowler, Kent Beck, John Brant, William Opdyke and Don Roberts, Refactoring: Improving the Design of Existing Code
• Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship
  • Notes on GitHub: jbarroso/clean-code
• Robert C. Martin, Agile Software Development, Principles, Patterns, and Practices