Writing Quality Code


Published on

Most developers write code to fulfil a business requirement, however the cost of project is not decided by the development but by the effort maintenance. So the emphasis should be to write quality , clean code that minimizes time spent on maintenance.

Published in: Software, Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Writing Quality Code

  1. 1. “Writing Quality Code” By Indika Maligaspe ““Give a man a fish and you feed him for a dayGive a man a fish and you feed him for a day Teach him how to fish and you feed him for a lifetime”Teach him how to fish and you feed him for a lifetime”
  2. 2. Intro...Intro... Indika Maligaspe  K. Indika Maligaspe  Developer, Designer, Architect , Trainer  Tech Geek specialized in JAVA and .Net  Over 14 years if experience in IT / Web Technologies  Lover of almost all sports...  http://www.linkedin.com/profile/view?id=201732082&trk=nav_responsive_tab_profile
  3. 3. ContributorsContributors  David Bernstein  Alan Shalloway  Steve McConnell  Martin Fowler  Gamma, Helms, Johnson, Vlissides (GoF)  James Coplien
  4. 4. Seminar AgendaSeminar Agenda  What effects Software Quality?  How to accommodate change?  What are Code Qualities?  Principles vs. Practices  Principles of Coding (Rules of Thumb)  Organizing Principles  Clarity Principles (good practices)  Summary  Q&A
  5. 5. What effects Software Quality?What effects Software Quality? Two questions…..Two questions….. • How many of you have been involvedHow many of you have been involved inin  A totally successful project?  A totally failed project?  A "challenged" project?
  6. 6. What effects Software Quality?What effects Software Quality? Two questions…..Two questions….. • When Adding FunctionalityWhen Adding Functionality Where was the Problem?Where was the Problem?  Is it writing the new code?  Is it integrating it into the system?  Why?
  7. 7. How can we design toHow can we design to accommodate change?accommodate change?  We are not trying to anticipate change, per se, as much as writing our code to accommodate change better. Trying to anticipate change can lead to “paralysis by analysis”  To do this we need  A way to avoid change when possible (outside of the scope of this document)  Componentized Architectures (CBA / SBC etc…)  Use of Design Patterns  Agile concepts  A way to make change less risky when one cannot avoid it  Code clarity and maintainability  Refactoring
  8. 8. What are Code Qualities?What are Code Qualities? • A computer has no concept of "well- written“ source code. However, from a human point of view source code can be written in a way that has an effect on the effort needed to comprehend its behavior. • Many source code programming style guides, which often stress readability and usually language-specific conventions are aimed at reducing the cost of source code maintenance by having code predictability.
  9. 9. PredictabilityPredictability  We can’t predict how our requirements are going to change  However we can predict how our code will adapt to unpredictable requirement changes  How can we increase our predictive abilities?  Pay attention to code quality
  10. 10. Six Code QualitiesSix Code Qualities  Cohesive  Correct Coupling  Non Redundant  Encapsulated  Testable  Assertive
  11. 11. Principles vs. PracticesPrinciples vs. Practices  Principle  A standard  Theory  Practice  How you put a principle to practice i.e. Principle - The need to be clean Practice - Wash hands
  12. 12. CohesionCohesion  Cohesion refers to how “closely the operations in a routine [or class] are related ” (Code complete – Steve McConnell)  Strong cohesion is related to clarity and understanding.  No "schizophrenic classes”  No “10000 - line classes”  No “10 page methods"‐
  13. 13. Good StrongGood Strong cohesioncohesion  Class Cohesion - A class has a single responsibility, and everything in the class is about fulfilling that responsibility.  Using design patterns and OO concepts (strategy / encapsulation / open – close etc…)  Method Cohesion - Each method is about fulfilling one functional aspect of the classes responsibility.  Programming by intention can help us to code with better method cohesion from the beginning
  14. 14. Class Cohesion - exampleClass Cohesion - example Class cohesion will be covered in detail in future sessions
  15. 15. Method cohesion – programmingMethod cohesion – programming by intentionby intention
  16. 16. Method cohesion – programmingMethod cohesion – programming by intentionby intention
  17. 17. What “programming by intention”What “programming by intention” will bringwill bring  Method cohesion  Cohesion of perspective  Sergeant is the controller (very little implementation)  Private’s do the work (implementation)  Ease of refactoring  Ease of applying/forming design patterns  Easier to test
  18. 18. CouplingCoupling  Coupling refers “to the strength of a connection between two routines [or classes] Coupling is complement to cohesion. Cohesion describes how strongly the internal contents of a routine [or class] are related to each other. Coupling describes how strongly a routine is related to other routines. The goal is to create routines [and classes] with internal integrity (strong cohesion) and small, direct, visible, and flexible relations to other routines [and classes] (loose coupling).”*  Tight coupling is related to highly interconnected code * Code Complete Steve McConnell 1993 p 22 Copyright
  19. 19. Correct CouplingCorrect Coupling  How interconnected Objects are  Loosely coupled – Objects should be independent and should mind their own business.  One employee should not know about salary details of other employees in the company  Tight coupled – Objects are interconnected and intertwined. Change one place and “All hell breaks loose”  Every employee knows the salaries of all the employees in the company. Give increment to one – MAJOR PROBLEM
  20. 20. Sample CouplingSample Coupling  Tight Coupling  Loose Coupling
  21. 21. Types of couplingTypes of coupling  Identity  One type to the fact that coupled another type exists.  Representational  One type coupled to the interface of another.  Inheritance  Subtypes are coupled to their superclass, in that any change in the superclass will propagate downward.  Subclass  One type coupled to the fact that there are subclasses to a type, and what specific subclasses exist. Writing Quality code David Bernstein – 2008 p24 Copyright
  22. 22. No Redundancy –No Redundancy – Avoiding duplicationAvoiding duplication  "One Rule in One Place"  Redundancy is not just:  Redundant state  Redundant functions  It can also be redundant relationships, design, construction, etc…  Anything that is redundant will cause maintenance problem
  23. 23. Avoid RedundancyAvoid Redundancy  The “once and only once” rule  If you are going to copy and paste, ask yourself  What is the code I want to reuse?  Can I make a new method that can be used by both my current method and the place I need to use this similar functionality?  If 2 entities need to do this, how likely will there be a third, fourth, etc… Writing Quality code David Bernstein – 2008 p27 Copyright
  24. 24. Encapsulation – Information hidingEncapsulation – Information hiding  Two commonly used encapsulation methods  Data : The data needed for a class to fulfill it's responsibilities is hidden from other entities  Implementation: How a class implements a particular function, or whether it implements it itself or delegates to other objects, is hidden  Not so commonly used  Type: Abstract classes and interfaces can hide their implementing classes  Design: Assembling, collaborating classes with an object factory keeps clients decoupled from the way they are designed (abstract factory)  Construction: Encapsulation of construction means wrapping "new" in, at least, a separate method, giving you control over the return type (use of getInstance)
  25. 25. TestabilityTestability  Class responsibility should be individually testable (unit testing)  Considering how to test before developing or designing leads to  Correctness  Good OO design  OO design patterns  And forces you to look at:  the public method definitions  what the responsibilities of the object are  Easy testability is achieved by strong cohesion, loose coupling, good encapsulation and non redundancy
  26. 26. Role of TestabilityRole of Testability  You should always do unit testing. It helps in code correctness  Whether you agree or not ask two things  You should always ask “ How will I test my design / code?”  If you see that your code/ unit or design is not testable, then there is something wrong in it. Ask your self “How can I make this more testable”
  27. 27. Assertive or InquisitiveAssertive or Inquisitive  In a relationship between two entities A and B  Should A ask the state of B and then use it (inquisitive)  Should A tell B to do the task involving the state (Assertive)  It does not increase the code or design, just who takes the code and responsibility  Which is better?
  28. 28. Assertive vs. Inquisitive –Assertive vs. Inquisitive – which is better?which is better?  The more Assertive you code / design is the more decoupled you code or design is  Remember the “Gang of Four”: Design to interfaces. An object's state is generally a part of its implementation. We should not design to that, as it is highly likely to change  "He who holds the state should hold the function"  Favor Assertiveness over Inquisitiveness (tell but not Ask principle)
  29. 29. Organizing Principles  Cohesion is an organizing principle in that it helps us decide where new entities belong  Coupling is an organizing principle in that it helps us decide how different entities should talk to each other (the interfaces)  Eliminating redundancy is an organizing principle because it tells us to bring together redundant methods/rules into a single place
  30. 30. Clarity Principles  How to document code  Implementation details (documentation) should be in the code, not as comments  If you have to write comments explaining “names”, your naming conventions might be having issues  There is BIG difference between comments about “what” you are doing and comments “why” (business rules)  Conceptual information can often be documented in abstract classes and interfaces  Naming is not always easy. It is often a good idea to pair on naming issues  Always format code properly (refer http://tutorials.rezg.net/Java/CodeConventions.pdf )  Try not have more the  100 characters per line  30 lines in a method  30 methods per class
  31. 31. SummarySummary  Remember the Code QualitiesRemember the Code Qualities T – TestabilityT – Testability R – Non RedundancyR – Non Redundancy E – EncapsulationE – Encapsulation C – CohesionC – Cohesion C – Correct CouplingC – Correct Coupling A – AssertiveA – Assertive T.R.E.C.C.A.T.R.E.C.C.A. Writing Quality code David Bernstein – 2008 p54 Copyright
  32. 32. Summary – In a NutshellSummary – In a Nutshell  In order of importance  Be testable  Contain no duplication (once and only once)  Loose coupling, strong cohesion and clarity  When writing, always program by intention  Methods and classes should be implemented so they can be understood totally from their names and their public interfaces. This flows naturally from up front testing, and decreases coupling‐  Classes should organize ideas in a readily understandable way  Use intention revealing names so you don't have to explain‐ method, member or class names with additional comments  Adhere to a coding standard
  33. 33. Thank YouThank You