Clean Code: A Handbook of Agile Software CraftsmanshipPearson Education, 2008. gada 1. aug. - 464 lappuses Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn’t have to be that way. Noted software expert Robert C. Martin presents a revolutionary paradigm with Clean Code: A Handbook of Agile Software Craftsmanship. Martin has teamed up with his colleagues from Object Mentor to distill their best agile practice of cleaning code “on the fly” into a book that will instill within you the values of a software craftsman and make you a better programmer–but only if you work at it. What kind of work will you be doing? You’ll be reading code–lots of code. And you will be challenged to think about what’s right about that code, and what’s wrong with it. More importantly, you will be challenged to reassess your professional values and your commitment to your craft. Clean Code is divided into three parts. The first describes the principles, patterns, and practices of writing clean code. The second part consists of several case studies of increasing complexity. Each case study is an exercise in cleaning up code–of transforming a code base that has some problems into one that is sound and efficient. The third part is the payoff: a single chapter containing a list of heuristics and “smells” gathered while creating the case studies. The result is a knowledge base that describes the way we think when we write, read, and clean code. Readers will come away from this book understanding
|
No grāmatas satura
1.–5. rezultāts no 45.
vii. lappuse
... .................23 Member Prefixes...............................................................................24 Interfaces and Implementations.......................................................24 Avoid vii Contents.
... .................23 Member Prefixes...............................................................................24 Interfaces and Implementations.......................................................24 Avoid vii Contents.
viii. lappuse
... ...............................................................................24 Interfaces and Implementations.......................................................24 Avoid Mental Mapping......................................
... ...............................................................................24 Interfaces and Implementations.......................................................24 Avoid Mental Mapping......................................
xxii. lappuse
... interface is the program, and that its structures have much to say about our program structure, it is crucial to continuously adopt the humble stance that the design lives in the code. And while rework in the manufacturing metaphor ...
... interface is the program, and that its structures have much to say about our program structure, it is crucial to continuously adopt the humble stance that the design lives in the code. And while rework in the manufacturing metaphor ...
24. lappuse
... interface. I just want them to know that it's a ShapeFactory. So if I must encode either the interface or the implementation, I choose the implementation. Calling it ShapeFactoryImp, or even the hideous CShapeFactory, is preferable to ...
... interface. I just want them to know that it's a ShapeFactory. So if I must encode either the interface or the implementation, I choose the implementation. Calling it ShapeFactoryImp, or even the hideous CShapeFactory, is preferable to ...
38. lappuse
... interface. My general rule for switch statements is that they can be tolerated if they appear only once, are used to create polymorphic objects, and are hidden behind an inheritance Listing 3-5 Employee and Factory public abstract class ...
... interface. My general rule for switch statements is that they can be tolerated if they appear only once, are used to create polymorphic objects, and are hidden behind an inheritance Listing 3-5 Employee and Factory public abstract class ...
Saturs
17 | |
31 | |
Comments | 53 |
Formatting | 75 |
Objects and Data Structures | 93 |
Error Handling | 103 |
Boundaries | 113 |
Unit Tests | 121 |
Concurrency | 177 |
Successive Refinement | 193 |
JUnit Internals | 251 |
Refactoring SerialDate | 267 |
Smells and Heuristics | 285 |
Concurrency II | 317 |
orgjfreedateSerialDate | 349 |
Cross References of Heuristics | 409 |
Citi izdevumi - Skatīt visu
Clean Code: A Handbook of Agile Software Craftsmanship Robert C. Martin Ierobežota priekšskatīšana - 2009 |
Bieži izmantoti vārdi un frāzes
abstract class Agile Software Development algorithm APRIL argChar Args Args.java argument ArgumentMarshaler AspectJ assertEquals BooleanArgumentMarshaler booleanValue byte-code catch ArgsException clean code concurrent constant create currentArgument day-of-the-week duplication elementId enum error errorArgumentId errorCode errorParameter example final String FitNesse function IllegalArgumentException implementation import instanceof integer IntegerArgumentMarshaler interface Java Javadoc JUnit Kent Beck Law of Demeter level of abstraction lines marshalers.put(elementId method module month null object package param parameter private boolean private int private Map<Character private static private String private void problem production code public abstract public boolean public class public int public public public public static final public String public void refactored return true SerialDate Single Responsibility Principle SpreadsheetDate static final int StringArgumentMarshaler stringToMonthcode stringToweekdayCode stringValue suffixLength Test-Driven Development things threaded code threads throw new ArgsException throws ArgsException throws Exception unit tests variables write