The Clean Code

Published: 2020-05-19, Updated: 2020-05-23

Pensamentos

Código bom e código ruim

O mesmo código feito nas coxas é o que levanta e derruba a mesma empresa, traz a vida um produto rapidamente e o mata por bugs, dificuldade na sustentação e criação de novas features.

Two decades later I met one of the early employees of that company and asked him what had happened. The answer confirmed my fears. They had rushed the product to market and had made a huge mess in the code. As they added more and more features, the code got worse and worse until they simply could not manage it any longer. It was the bad code that brought the company down.

LeBlanc’s law

Later equals never

Sobre mexer em um código bagunçado

Every change they make to the code breaks two or three other parts of the code. No change is trivial

Sobre criar novos sistemas para substituir sistemas antigos e ruins

This race can go on for a very long time. I’ve seen it take 10 years. And by the time it’s done, the original members of the tiger team are long gone, and the current members are demanding that the new system be redesigned because it’s such a mess.

Sobre fazer o que precisa ser feito

When hand-washing was first recommended to physicians by Ignaz Semmelweis in 1847, it was rejected on the basis that doctors were too busy and wouldn’t have time to wash their hands between patient visits.

A diferença de um programador que sabe fazer um bom código do que não sabe

A programmer without “code-sense” can look at a messy module and recognize the mess but will have no idea what to do about it. A programmer with “code-sense” will look at a messy module and see options and variations. The “code-sense” will help that pro- grammer choose the best variation and guide him or her to plot a sequence of behavior preserving transformations to get from here to there.

Sobre o código ser objetivo

Our code should be matter-of-fact as opposed to speculative. It should contain only what is necessary. Our readers should perceive us to have been decisive

Sobre como fazer um código fácil para evoluir

if you want your code to be easy to write, make it easy to read.

O que seu código tem que ter

Sobre nome de variáveis, classes, métodos, etc.

The length of a name should correspond to the size of its scope

Code samples

Example 1

Bad

public List<int[]> getThem() {
  List<int[]> list1 = new ArrayList<int[]>();
  for (int[] x : theList)
    if (x[0] == 4)
      list1.add(x);
  return list1;
}

Good

public List<int[]> getFlaggedCells() {
  List<int[]> flaggedCells = new ArrayList<int[]>();
  for (int[] cell : gameBoard)
    if (cell[STATUS_VALUE] == FLAGGED)
      flaggedCells.add(cell);
    return flaggedCells;
}

Better

public List<Cell> getFlaggedCells() {
  List<Cell> flaggedCells = new ArrayList<Cell>();
  for (Cell cell : gameBoard)
    if (cell.isFlagged())
      flaggedCells.add(cell);
  return flaggedCells;
}

Example 2

Bad

public static void copyChars(char a1[], char a2[]) {
  for (int i = 0; i < a1.length; i++) {
    a2[i] = a1[i];
  }
}

Good

public static void copyChars(char source[], char destination[]) {
  for (int i = 0; i < source.length; i++) {
    destination[i] = source[i];
  }
}

Junit 5 Examples Ast Bookmarks

Comments