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
  • Warnings
  • Logging
  • Java

Was this helpful?

  1. Clean Code
  2. Clean Code Outline

Special Cases

Warnings

  • Do not ignore compiler/IDE warnings

  • Each warning is a potential/existing bug

  • Do not suppress warnings - Find the correct solution instead

  • Use the capabilities of your IDE - Turn on most of the possible warnings

  • Do not add new code with warnings!

  • Use code checkers - CheckStyle, FindBugs, PMD, Sonar, etc.

Example: Bad: Suppressed warnings

// Many tricks for one unused parameter

// CHECKSTYLE:OFF
@SuppressWarnings("unused")
private void addDescription(Type type, Contract contract, String comment) { // NOSONAR
    contract.setDescription(createDescription(contract.getType(), comment));
}
// CHECKSTYLE:ON

Example: Good: Fixed problems

private void addDescription(Contract contract, String comment) {
    contract.setDescription(createDescription(contract.getType(), comment));
}

Logging

  • Use correct logging levels

  • Log stack trace only for unexpected program errors

  • Create (concatenate) expensive message only if logged - see SLF4J capabilities

Java

  • Never use raw types - always use generics correctly

  • Avoid using reflection

  • Know you API - use utility methods

Last updated 5 years ago

Was this helpful?