Successfully reported this slideshow.
CLEAN CODE
A Summary
What is Clean Code?
Easy for
others to
change
Easy for others
to read
Focused on a
particular ‘thing’
Completely
covered b...
Why is Clean Code Important?
 Easy to Read, Easy to Change
The ratio of time spent reading vs. writing is well
over 10:1....
Causes of Poor Code Quality
 Inexperience
 Lack of time
 Laziness
 Broken Window Theory
Boy Scout Rule
 Leave the campground cleaner
than you found it.
Naming Guidelines
 Names should reveal intent
 You may change them repeatedly
 Avoid misleading names
 If you can’t pr...
Nouns vs Verbs
• Nouns
• Representing
things in the real
world
Classes/Objects
• Verbs
• An action being
taken by the obje...
Private Constructors & Static
Methods
 Consider using static factory methods to call
parameterized constructors
Student.C...
Rules of Thumb
 Keep methods as short as possible (< 20
lines)
 If statements & loops should only contain
method calls
Single Responsibility Principle
Be one thing, do one thing
Comments
 Comments describe things that our code
cannot
 int temp = 0; // temperature in celsius
 int temperatureInCels...
Bad Comments - Continued
Useless or
Redundant
Comments
Incorrect
Comments
Outdated
Code
Good Comments
 Warnings of bad things if
code is deleted
 Future things that need to
be added
Prochain SlideShare
Chargement dans…5
×

Why Clean Code needed Software Development

461 vues

Publié le

“You know you are working on clean code when each routine you read turns out to be pretty much what you expected.” – Ward Cunningham

Publié dans : Logiciels
  • Soyez le premier à commenter

Why Clean Code needed Software Development

  1. 1. CLEAN CODE A Summary
  2. 2. What is Clean Code? Easy for others to change Easy for others to read Focused on a particular ‘thing’ Completely covered by tests
  3. 3. Why is Clean Code Important?  Easy to Read, Easy to Change The ratio of time spent reading vs. writing is well over 10:1.  “You know you are working on clean code when each routine you read turns out to be pretty much what you expected.” – Ward Cunningham
  4. 4. Causes of Poor Code Quality  Inexperience  Lack of time  Laziness  Broken Window Theory
  5. 5. Boy Scout Rule  Leave the campground cleaner than you found it.
  6. 6. Naming Guidelines  Names should reveal intent  You may change them repeatedly  Avoid misleading names  If you can’t pronounce it, don’t use it  Longer names > Shorter names  Avoid prefixes & type encoding
  7. 7. Nouns vs Verbs • Nouns • Representing things in the real world Classes/Objects • Verbs • An action being taken by the object Methods
  8. 8. Private Constructors & Static Methods  Consider using static factory methods to call parameterized constructors Student.CreateStudentFirstNameLastName(“Jas on”, “Rosado”); vs new Student(“Jason”, “Rosado”);
  9. 9. Rules of Thumb  Keep methods as short as possible (< 20 lines)  If statements & loops should only contain method calls
  10. 10. Single Responsibility Principle Be one thing, do one thing
  11. 11. Comments  Comments describe things that our code cannot  int temp = 0; // temperature in celsius  int temperatureInCelsius= 0;  Use more descriptive names instead of comments
  12. 12. Bad Comments - Continued Useless or Redundant Comments Incorrect Comments Outdated Code
  13. 13. Good Comments  Warnings of bad things if code is deleted  Future things that need to be added

×