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
  • Avoid NullPointerExceptions (NPE)
  • Defensive Programming
  • Parameters
  • Unit Test of Inputs
  • Error Handling

Was this helpful?

  1. Clean Code
  2. Clean Code Outline

Nulls and Validity Checks

Avoid NullPointerExceptions (NPE)

  • Check at the beginning - Unhappy path, Happy path

  • Consider using helper methods

  • Check each object which is de-referenced in the method - and only these ones

Example: Bad: Null check at the wrong place

void doSomething(MyClass input) {
    if(input != null) { // Unnecessary here
        doStuff(input);
    }
}

void doStuff(MyClass input) {
    input.setData(10); // Would be necessary here
}

Example: Good: Null check always and only when dereferencing

void doSomething(MyClass input) {
    doStuff(input);
}

void doStuff(MyClass input) {
    if(input == null) {
        return;
    }
    input.setData(10);
}

Defensive Programming

Also known as Secure Programming. A larger topic, but some elements:

Inputs

  • Never trust data coming from outside - user input, external systems

  • Fail early, Fail clean

  • Create and use immutable types

Outputs

  • Do not modify a data through getters

  • Prevent it if possible - unmodifiable collections

  • Create and use immutable types

Example: Bad: Unclear validity check

// What to do when input source is null?
// Why is the entire content indented?
public final void parse(final Config[] configs, final boolean flushAfterParse) {
    if (getInputSource() != null) {
        final EdifactParser parser = new EdifactParser(getInputSource(), getHandler());
        for (final Config config : configs) {
            parser.addConfig(config);
        }
        parser.convert();
        if (flushAfterParse) {
            getHandler().flush(true);
        }
    }
}

Example: Good: Validity check at the beginning

public final void parse(final Config[] configs, final boolean flushAfterParse) {
    // Unhappy path
    if (getInputSource() == null) {
        return; // Do nothing, return default or throw exception
    }
    // Happy path or Normal flow
    final EdifactParser parser = new EdifactParser(getInputSource(), getHandler());
    for (final Config config : configs) {
        parser.addConfig(config);
    }
    parser.convert();
    if (flushAfterParse) {
        getHandler().flush(true);
    }
}

Parameters

  • Do not pass explicitly null - it is a "cheating", _allow it with an overloaded method

Unit Test of Inputs

  • Unit test will nulls and empty values in all possible ways

    • null object

    • entire collection or array is null

    • collection or array element is null

Error Handling

  • Do not return null - rather throw exception

Things must not be multiplied beyond necessity. The simplest solution is the best. (Occam’s Razor)

Last updated 5 years ago

Was this helpful?