Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Clean code quotes - Citações e provocações

Nessa apresentação mostro algumas citações do livro de Clean Code de Robert C. Martin de modo a provocar o leitor.

  • Login to see the comments

Clean code quotes - Citações e provocações

  1. 1. Clean Code Quotes A Handbook of Agile Software Craftsmanship Citações e Provocações
  2. 2. Sobre mim ● Java desde 2006 (1.4) ● Spring Framework desde 2008 (2.5) ● Ritmista da Mocidade Alegre desde 2000 @aignacio83 andrefontanaignacio ignacio83
  3. 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. 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. 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. 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. 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. 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. 9. About naming things - Refactor time
  10. 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. 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. 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. 13. About comments - Refactor time
  14. 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. 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. 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. 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. 18. About Switchs - Refactor time
  19. 19. About variables declaration "Variables should be declared as close to their usage as possible."
  20. 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. 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. 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. 23. About Data Structures and Objects - Refactor time
  24. 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. 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. 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. 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. 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. 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. 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. 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. 32. About duplications "Duplication is the primary enemy of a well-designed system. It represents additional work, additional risk, and additional unnecessary complexity."
  33. 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. 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. 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. 36. O livro Clean Code - A Handbook of Agile Software Craftsmanship Robert C. Martin (Uncle Bob)
  37. 37. Recomendações
  38. 38. Obrigado Perguntas? @aignacio83andrefontanaignacio ignacio83