Clear Code
  • Introduction
    • About This Book
    • Timeline
    • Software Killers
    • Billion Dollar Mistakes
    • Clear Code Overview
    • Clear Code Rules
  • Data Processing
    • Separate Data Collection And Processing
    • Create Data Models
    • Separate Use Cases
    • Data Should Be Immutable
  • Examples
    • Separate Use Cases With Data Model
  • Maintenance Cost
    • Consider the Maintenance Cost
    • The Software Exists In Time
    • Don't Feed the Monsters
  • OOP
    • Separate Data And Procedures
    • Do Not Use Inheritance
    • When To Avoid Inheritance?
    • What Is The Problem With Abstract Frameworks?
  • VARIOUS
    • The Real Single Responsibility Principle
    • The problem with Clean Code's name
    • How To Handle Warnings
    • Do Not Create Constant Collection Classes
  • Externals
    • Links
    • Quotes
    • Funny
  • Technology
    • Git Tutorials
  • Clean Code
    • Clean Code Introduction
      • Origin & Overview
      • Advanced
      • Typical Issues
    • Clean Code Outline
      • Why Clean Code?
      • Clean Code
      • Clean Code Approaches
      • Specification & Design
      • Duplication
      • Refinement & Refactoring
      • Conventions
      • Names
      • Types
      • Methods
      • Nulls and Validity Checks
      • Comments
      • Dead Code
      • Error Handling
      • Classes
      • Code Formatting
      • Unit Tests
      • Special Cases
      • Object Oriented Programming
      • General Code Smells
    • Clean Code Links
    • Clean Code TOC
    • Effective Java TOC
Powered by GitBook
On this page
  • Object-oriented programming
  • High number of branching
  • Automation
  • Common code that is not common
  • Incorrect data processing

Was this helpful?

  1. Introduction

Billion Dollar Mistakes

DRAFT

Last updated 1 year ago

Was this helpful?

This page narrows down the problems to the few biggest ones. They make code very hard to maintain so they make coding a very time-consuming activity.

Unfortunately, they are all part of our usual coding practices. We don't even treat them as issues. We think that they are what we call programming. I'd like to point out that they shouldn't be.

Object-oriented programming

OOP results in very hard-to-read and hard-to-write code. It hides the business logic, which is the opposite of what the code should do.

It is the most expensive way of coding. Most of the coding time is spent solely on understanding and maintaining class hierarchies. This time is missing from working on the business requirements. A lot of time is wasted.

Using OOP is not necessary. (At least in most of the programming situations.) So the price/benefit ratio is extremely high.

After separating data and procedures we don't have classes. As a consequence most of the OOP rules we know become invalid.

Use the Composite pattern.

Model the real-life domain entities with the data model and not with the procedural components.

High number of branching

Branchings increase the cyclomatic complexity of the program. It is measured only for single methods but not for the entire program. We have a blind spot for this problem.

We write ifs and other forms of branching everywhere in the code. We create class hierarchies and other patterns that are based on branching. We do it in an irresponsible way; we don't care how many branching we create.

Separate use cases only once and as early as possible.

Automation

We write code that automates the program in runtime.

Frameworks, common code.

This is not the program we should write.

Everything that is known in coding time should be written in the code and explicitly called from use cases.

Common code that is not common

This problem goes hand-in-hand with the branching problem and the automation.

Incorrect data processing

We never identify a program as a "data processing code".

We should write components with clearly defined input and output data structures.

A "backend" is a data processing code.

.

.

The high number of branching is also a consequence of antipatterns, like passing and returning nulls or controlling the program flow with nulls. (Spaghetti code, , .)

.

.

I took the click-bait title from this speech: .

Quit OOP
Separate data and procedures
Separate use cases
Null References: The Billion Dollar Mistake
Insider trading
Common code that is not common
Separate everything