writing quality code
DESCRIPTION
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.TRANSCRIPT
“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 dayTeach him how to fish and you feed him for a lifetime”Teach him how to fish and you feed him for a lifetime”
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
ContributorsContributors
David Bernstein Alan Shalloway Steve McConnell Martin Fowler Gamma, Helms, Johnson, Vlissides (GoF) James Coplien
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
What effects Software Quality?What effects Software Quality?Two questions…..Two questions…..
• How many of you have been involved inHow many of you have been involved in
A totally successful project? A totally failed project? A "challenged" project?
What effects Software Quality?What effects Software Quality?Two questions….. Two questions…..
• When Adding FunctionalityWhen Adding FunctionalityWhere was the Problem?Where was the Problem? Is it writing the new code? Is it integrating it into the system?
Why?
How can we design to How 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
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.
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
Six Code QualitiesSix Code Qualities
Cohesive Correct Coupling Non Redundant Encapsulated Testable Assertive
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
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"
Good Strong Good 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
Class Cohesion - exampleClass Cohesion - example
+PKIencrypt()+PKIdecrypt()+PGPencrypt()+PGPdecrypt()+sendMessage()+getInputStream()+getOutputStream()
Socket
UDPSocket TCPSocket
Class cohesion will be covered in detail in future sessions
+sendMessage()+getInputStream()+getOutputStream()
Socket
+encrypt()+decrypt()
Encryption
PKIEncryption PGPEncryption
1
*
UDPSocket TCPSocket
using Stratergy Pattern
Method cohesion – programming Method cohesion – programming by intentionby intention
public Socket(String actionType) { // Add code to read data through the socket and get a input stream System.out.println("Socket.java - Getting InputStream"); if (1 == (Integer.parseInt(actionType))) { // Add code to do PKI encryption System.out.println("Socket.java - PKI encrypting"); } else if (2 == (Integer.parseInt(actionType))) { // Add code to do PKI decryption System.out.println("Socket.java - PKI decrypting"); } else if (3 == (Integer.parseInt(actionType))) { // Add code to do PGP encryption System.out.println("Socket.java - PGP encrypting"); } else if (4 == (Integer.parseInt(actionType))) { // Add code to do PGP decryption System.out.println("Socket.java - PGP decrypting"); } else if (5 == (Integer.parseInt(actionType))) { // Add code to do GZip compression System.out.println("Socket.java - GZip compression "); }
}
}
Method cohesion – programming Method cohesion – programming by intentionby intention
public Socket(String actionType[]) { this.socketInputStream = getInputStream(); this.socketOutputStream = getOutputStream(); doEncryption(Integer.parseInt(actionType[0])); doDecryption(Integer.parseInt(actionType[1])); doCompression(Integer.parseInt(actionType[1])); }
private InputStream getInputStream() { // Add code to read data through the socket and get a input stream System.out.println("Socket.java - Getting InputStream"); return null; }
private OutputStream getOutputStream() { // Add code to write data through the socket and get a output stream System.out.println("Socket.java - Getting OutputStream"); return null; }
private void doEncryption(int encryptionType) { if (1 == encryptionType) { doPKIEncryption(); } else if (2 == encryptionType) { doPGPEncryption(); } }
PrivateMethods
SergeantMethod
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
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
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
Sample CouplingSample Coupling
Tight Coupling
Loose Coupling
Employee
+getSalaries() : Object
Company
1*
Employee
+getInstance() : Company+getSalary(in empNo : string) : long double
Company
* * +getSalarie(in empNo : long) : double
«interface»Employees
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
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
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
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)
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
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”
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?
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)
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
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
SummarySummary
Remember the Code QualitiesRemember the Code QualitiesT – TestabilityT – Testability
R – Non RedundancyR – Non Redundancy
E – EncapsulationE – Encapsulation
C – CohesionC – Cohesion
C – Correct CouplingC – Correct Coupling
A – Assertive A – Assertive
T.R.E.C.C.A. T.R.E.C.C.A. Writing Quality code David Bernstein – 2008 p54 Copyright
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
Thank YouThank You