Robert C. Martin is a software engineer since 1970 who has edited and written several books. He co-authored the Agile Manifesto. The book Clean Code discusses principles of clean code such as functions doing one thing, avoiding duplications, and refactoring code in small steps. Tests are important to keep code flexible and readable by being fast, independent, repeatable, self-validating, and timely. Writing clean code is a craft that requires writing dirty code first and then cleaning it.

1. Clean Code Quotes
A Handbook of Agile Software Craftsmanship
Citações e Provocações

2. Sobre mim
● Java desde 2006 (1.4)
● Spring Framework desde 2008 (2.5)
● Ritmista da Mocidade Alegre desde 2000
@aignacio83
andrefontanaignacio
ignacio83

3. Robert C. Martin - Uncle Bob
Robert Cecil Martin é um engenheiro de software desde 1970. Ele
editou e escreveu diversos livros. É co-autor do Manifesto Ágil.
Também é editor chefe na revista C++ Report e serviu para o primeiro
presidente da aliança ágil.

4. About bad code
"Nothing has a more profound and long-term degrading effect
upon a development project than bad code. Bad schedules can
be redone, bad requirements can be redefined. Bad team
dynamics can be repaired. But bad code rots and ferments,
becoming an inexorable weight that drags the team down."

5. About Learn to write Clean code
"You must practice it yourself, and watch yourself fail. You
must watch others practice it and fail. You must see them
stumble and retrace their steps. You must see them agonize
over decisions and see the price they pay for making those
decisions the wrong way."

6. About managers
"If I don’t do what my manager says, I’ll be fired. Probably
not. Most managers want the truth, even when they don’t act
like it. Most managers want good code, even when they are
obsessing about the schedule."
"They may defend the schedule and requirements with passion;
but that’s their job."

7. About unit tests
"Code, without tests, is not clean. No matter how elegant it
is, no matter how readable and accessible, if it hath not
tests, it be unclean."

8. About naming things
"The name of a variable, function, or class, should answer
all the big questions. It should tell you why it exists, what
it does, and how it is used. If a name requires a comment,
then the name does not reveal its intent."

9. About naming things - Refactor time

10. About functions
"Functions should do one thing. They should do It well. They
should do It only."
The first rule of functions is that they should be small. The
second rule of functions is that they should be smaller than
that.

11. About naming functions
"Don’t be afraid to make a name long. A long descriptive name
is better than a short enigmatic name. A long descriptive
name is better than a long descriptive comment."

12. About comments
"The proper use of comments is to compensate for our failure
to express ourself in code. Note that I used the word
failure. I meant it. Comments are always failures. We must
have them because we cannot always figure out how to express
ourselves without them, but their use is not a cause for
celebration."

13. About comments - Refactor time

14. About comments and Bad code
"We write a module and we know it is confusing and
disorganized. We know it’s a mess. So we say to ourselves,
“Ooh, I’d better comment that!”
No! You’d better clean it!"

15. About source of truth
"Truth can only be found in one place: the code. Only the
code can truly tell you what it does. It is the only source
of truly accurate information. Therefore, though comments are
sometimes necessary, we will expend significant energy to
minimize them."

16. About Switchs
"By their nature, switch statements always do N things.
Unfortunately we can’t always avoid switch statements, but we
can make sure that each switch statement is buried in a low-
level class and is never repeated. We do this, of course,
with polymorphism."

17. About Switchs - Close Looking
"There are several problems with this
function. First, it’s large, and when
new employee types are added, it will
grow. Second, it very clearly does more
than one thing. Third, it violates the
Single Responsibility Principle because
there is more than one reason for it to
change. Fourth, it violates the Open
Closed Principle (OCP) because it must
change whenever new types are added. But
possibly the worst problem with this
function is that there are an unlimited
number of other functions that will have
the same structure."

18. About Switchs - Refactor time

19. About variables declaration
"Variables should be declared as close to their usage as
possible."

20. About dependent functions
"If one function calls another, they should be vertically
close, and the caller should be above the callee, if at all
possible. This gives the program a natural flow."

21. About encapsulation
"There is a reason that we keep our variables private. We
don’t want anyone else to depend on them. We want to keep the
freedom to change their type or implementation impulse. Why,
then, do so many programmers automatically add getters and
setters to their objects, exposing their private variables as
if they were public?"

22. About Data Structures and Objects
"Objects hide their data behind abstractions and expose
functions that operate on that data. Data structure expose
their data and have no meaningful functions."

23. About Data Structures and Objects - Refactor time

24. About Procedural code and OO
"Procedural code (code using data structures) makes it easy
to add new functions without changing the existing data
structures. OO code, on the other hand, makes it easy to add
new classes without changing existing functions.
The complement is also true:
Procedural code makes it hard to add new data structures
because all the functions must change. OO code makes it hard
to add new functions because all the classes must change."

25. About Train Wreck
"This kind of code is often called a train wreck because it
look like a bunch of coupled train cars. Chains of calls like
this are generally considered to be sloppy style and should
be avoided. It is usually best to split them up as follows:"
Options opts = ctxt.getOptions();
File scratchDir = opts.getScratchDir();
String outputDir = scratchDir.getAbsolutePath();
final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();

26. About Checked Exceptions
"The price of checked exceptions is an Open/Closed Principle
violation. If you throw a checked exception from a method in
your code and the catch is three levels above, you must
declare that exception in the signature of each method
between you and the catch. This means that a change at a low
level of the software can force signature changes on many
higher levels."
"Encapsulation is broken because all functions in the path of
a throw must know about details of that low-level exception."

27. About pass null
"Returning null from methods is bad, but passing null into
methods is worse. Unless you are working with an API which
expects you to pass null, you should avoid passing null in
your code whenever possible."

28. About clean Tests
"If you don’t keep your tests clean, you will lose them. And without
them, you lose the very thing that keeps your production code
flexible. Yes, you read that correctly. It is unit tests that keep
our code flexible, maintainable, and reusable. The reason is simple.
If you have tests, you do not fear making changes to the code!
Without tests every change is a possible bug.
What makes a clean test? Three things. Readability, readability, and
readability."

29. About Tests readability
"Each of the tests is clearly split into three parts. The first part
builds up the test data, the second part operates on that test data,
and the third part checks that the operation yielded the expected
results."

30. Yet About tests - F.I.R.S.T.
"Fast: If you don’t run them frequently, you won’t find problems early enough
to fix them easily."
"Independent: You should be able to run each test independently and run the
tests in any order you like."
"Repeatable: If your tests aren’t repeatable in any environment, then you’ll
always have an excuse for why they fail. You’ll also find yourself unable to
run the tests when the environment isn’t available."
"Self-validating: If the tests aren’t self-validating, then failure can become
subjective and running the tests can require a long manual evaluation."
"Timely: If you write tests after the production code, then you may find the
production code to be hard to test. You may decide that some production code
is too hard to test. You may not design the production code to be testable."

31. About classes
"So breaking a large function into many smaller
functions often gives us the opportunity to split
several smaller classes out as well. This gives our
program a much better organization and a more
transparent structure."

32. About duplications
"Duplication is the primary enemy of a well-designed
system. It represents additional work, additional
risk, and additional unnecessary complexity."

33. About writing concurrency code
"First and foremost, follow the Single Responsibility
Principle. Break your system into POJOs that separate thread-
aware code from thread-ignorant code. Make sure when you are
testing your thread-aware code, you are only testing it and
nothing else. This suggests that your thread-aware code
should be small and focused."

34. About refactoring
"Refactoring is a lot like solving a Rubik’s cube.
There are lots of little steps required to achieve a
large goal. Each step enables the next."

35. About writing Clean code
"I am not expecting you to be able to write clean and elegant
programs in one pass. If we have learned anything over the
last couple of decades, it is that programming is a craft
more than it is a science. To write clean code, you must
first write dirty code and then clean it."

36. O livro
Clean Code - A Handbook of Agile
Software Craftsmanship
Robert C. Martin (Uncle Bob)

37. Recomendações

39. Obrigado
Perguntas?
@aignacio83andrefontanaignacio ignacio83