1. Concordia University Department of Computer Science and Software Engineering Click to edit Master title style ADVANCED PROGRAMING PRACTICES Code quality Joey Paquet, 2006-2014 1SOEN 6441 - Advanced Programming Practices

2. Concordia University Department of Computer Science and Software Engineering All software must expose some qualities. These necessary qualities are different from one software to another. Many of these qualities are not directly related to the code itself. Though in the end, they are all indirectly related to the code. The code itself has some qualities that are not necessarily externally visible. Introduction Joey Paquet, 2006-2014 2SOEN 6441 - Advanced Programming Practices

3. Concordia University Department of Computer Science and Software Engineering Reliability Modifiability Maintainability Understandability Adaptability Reusability Efficiency Portability Traceability of artifacts Fault tolerance Backward-compatibility Cost-effectiveness High-performance Software qualities Joey Paquet, 2006-2014 3SOEN 6441 - Advanced Programming Practices Good documentation Well-defined interfaces User-friendliness Rapid development Readability Ease of learning Ease of remembering Ease of use Increased productivity Low-cost Flexibility Security Robustness

4. Concordia University Department of Computer Science and Software Engineering Some qualities are cross-related (positively or negatively): Functionality vs. Usability Cost vs. Robustness Efficiency vs. Portability Rapid development vs. Functionality Cost vs. Reusability Backward Compatibility vs. Readability Coupling vs. Maintainability etc Increasing some qualities may decrease or increase other qualities. Cross-related qualities Joey Paquet, 2006-2014 4SOEN 6441 - Advanced Programming Practices

5. Concordia University Department of Computer Science and Software Engineering Achieving quality inevitably implies cost. You want to avoid increasing cost to increase unnecessary qualities. Cost investment towards a certain quality should be proportional to the importance of this quality, i.e. justification is necessary. Thus, determining the right qualities is a primordial activity. Some simple practices can be used to increase quality with minimal cost. Quality vs. cost Joey Paquet, 2006-2014 5SOEN 6441 - Advanced Programming Practices

6. Concordia University Department of Computer Science and Software Engineering Reliability Modifiability Maintainability Adaptability Reusability Efficiency Portability Traceability Fault tolerance Backward-compatibility Robustness Code qualities Joey Paquet, 2006-2014 6SOEN 6441 - Advanced Programming Practices Cohesion Coupling Modularity Information hiding Encapsulation Readability Understandability Low redundancy

7. Concordia University Department of Computer Science and Software Engineering Click to edit Master title style Code qualities Joey Paquet, 2006-2014 7SOEN 6441 - Advanced Programming Practices

8. Concordia University Department of Computer Science and Software Engineering Modularity A good design usually consists of a collection of well- defined, discrete components or modules. There are various ways of organizing the modules (software architecture). The important thing is to avoid a jumble of classes connected in complicated and non-intuitive ways. There are several levels of abstraction in modularity. Modularity does not necessarily lead to good cohesion and coupling. Code qualities Joey Paquet, 2006-2014 8SOEN 6441 - Advanced Programming Practices

9. Concordia University Department of Computer Science and Software Engineering Cohesion A module is cohesive, or has high cohesion, if its internal parts are closely related towards the achievement of a clear purpose. Every sub-component is working towards this goal. Similar concept as for “team cohesion”. A simple test of cohesion is to try to describe the module concisely. A complex module description or complex interface is often an indication of poor cohesion. Code qualities Joey Paquet, 2006-2014 9SOEN 6441 - Advanced Programming Practices

10. Concordia University Department of Computer Science and Software Engineering Cohesion (continued…) Coincidental: Parts are unrelated to one another. Logical: Logically related functions or data elements are placed in the same component, e.g. all “input” features are put in the same component, either from files, or from the network. Temporal: Functions that are executed in sequence in the same process are put in a component, e.g. system initialization procedures. Procedural: Functions that sequentially aim at the production of a result are put in the same component, e.g. capture the data, validate data, create a record, and save the record. Code qualities Joey Paquet, 2006-2014 10SOEN 6441 - Advanced Programming Practices

11. Concordia University Department of Computer Science and Software Engineering Cohesion (continued…) Communicational: Functions are associated because they operate on or produce the same data set, e.g. book inventory is used for both accounting and managing orders. Sequential: The output from one part of a component is input to the next part, e.g. compilers. Functional: Every processing element is essential to the performance of a single functionality, and all essential elements are contained in one component. A functionally cohesive component not only performs the functionality for which it is designed, but also performs only that functionality and nothing else. It is thus more likely that changing this particular functionality will affect only one component. Code qualities Joey Paquet, 2006-2014 11SOEN 6441 - Advanced Programming Practices

12. Concordia University Department of Computer Science and Software Engineering Coupling Two modules are coupled if they depend on each other in any way. Unlike cohesion, less coupling is better. As with cohesion, there are various degrees of coupling. “coupling refers to the strength of a connection between two components. Coupling is a complement to cohesion. Cohesion describes how strongly the internal content of a component are related to each other. Coupling describes how strongly a component is related to other components. The goal is to create components with internal integrity (i.e. strong cohesion) and small, direct, visible, and flexible relations to other components (i.e. loose coupling).” [Constantine 1975, McConnell 1993] Example: façade pattern Precept: “no two dots in a call” Code qualities Joey Paquet, 2006-2014 12SOEN 6441 - Advanced Programming Practices

13. Concordia University Department of Computer Science and Software Engineering Coupling (continued…) Content : One component actually modifies the behavior of another, e.g. one component modifies an internal data item in another component, or a component branches into the middle of another component. Common : Data accessible from a central store in more than one component, e.g. global variables. It can be difficult to determine which component is responsible for having set a variable to a particular value. Control : One component passes parameters to control the execution of another component, e.g. setting a “flag”. Sometimes acceptable, but should minimize the amount of controlling information that must be passed from one component to another and to localize control to a fixed and recognizable set of parameters forming a well-defined interface. Code qualities Joey Paquet, 2006-2014 13SOEN 6441 - Advanced Programming Practices

14. Concordia University Department of Computer Science and Software Engineering Coupling (continued…) Stamp : A data structure is used to pass information from one component to another, and the whole data structure is passed. Bad if some or most of the data is not used. Data : A restriction of stamp coupling, where data is passed to the called component, but where only the necessary information is passed. Ideally, all information is passed as separate parameters, even though they come from the same data structure. Uncoupled : No interconnections at all. Possible? Code qualities Joey Paquet, 2006-2014 14SOEN 6441 - Advanced Programming Practices

15. Concordia University Department of Computer Science and Software Engineering Testability Testability tends to improve many other qualities, as tests permit to measure and monitor quality. Testability lies in reproducibility of testing at minimal cost (e.g. using a testing framework as JUnit). Testability requires clear and simple specifications (requirements, interface specifications). Complicated code is harder to test. Low testability is often a sign of deficient code qualities (modularity, coupling, readability). Code qualities Joey Paquet, 2006-2014 15SOEN 6441 - Advanced Programming Practices

16. Concordia University Department of Computer Science and Software Engineering Reduced redundancy Redundancy is an indication of poor design. Writing tests can often help detect redundancy. The necessity of similar test on different components is an indication. Sometimes its is quicker to code by redundancy. To fix redundancy, use refactoring. Construction of complex objects is often a source of redundancy. Use “encapsulating construction” to avoid it, e.g. through builder or factory patterns. Code qualities Joey Paquet, 2006-2014 16SOEN 6441 - Advanced Programming Practices

17. Concordia University Department of Computer Science and Software Engineering Encapsulation/Information hiding Highly related to cohesion and coupling, but sufficiently important to be separated from them: High coupling and low information hiding are often related High information hiding prevents coupling to be introduced If designers do not follow the principles of information hiding, the system will contain possible dependencies that will make understandability and maintenance a nightmare. For example, if a data member is public, it may or may not be used externally. If it is not, declaring it private makes it clear and eliminates the possibility. Note that information hiding can be overridden by privacy leaks, most notably through passing and returning references to objects. An important quality to be increased through refactoring operations. Code qualities Joey Paquet, 2006-2014 17SOEN 6441 - Advanced Programming Practices

18. Concordia University Department of Computer Science and Software Engineering Readability/Understandability Readable code is more understandable. Readability can be improved by: Consistent use of coding standards and naming convention. Simple, usable and up to date documentation (e.g. using Javadoc). Understandability is also influenced by cohesion and coupling. They both have a great influence on maintainability, and productivity in general, especially in change-prone projects such as when using XP or other incremental software development model. Code qualities Joey Paquet, 2006-2014 18SOEN 6441 - Advanced Programming Practices

19. Concordia University Department of Computer Science and Software Engineering Fault tolerance A good design/code should be tolerant of both external and internal errors. It is important but straightforward to protect the system against most external errors. The key step is to validate all inputs to the system carefully, so that the system rejects inappropriate data and processes only “good” data. Even after validation, internal errors may still cause the system to fail. Dividing by zero or computing the square root of a negative number causes most processes to raise a signal. If the signal is not handled and processed correctly, the system may crash. How to fault tolerance: Write tests first. Component/system duplication. Write fault-detection-enabled mutators. Use exception handling to report and handle errors and prevent crashing. Code qualities Joey Paquet, 2006-2014 19SOEN 6441 - Advanced Programming Practices

20. Concordia University Department of Computer Science and Software Engineering Simplicity Always choose the simplest design when a choice comes in (if both designs meet the requirements/specifications). Designer should try to remove all unnecessary complexity from the system (can be done retroactively through refactoring). Simplification is hard and requires experience. Examples: A design diagram is hard to read if it contains many crossing lines. If you redraw it to reduce the number of intersections, you will understand it better and may be able to simplify it. A large number of links to a class may indicate low cohesion or high coupling. Increasing cohesion and reducing coupling will tend to simplify a design. Don't worry about efficiency during design. Very often, efficiency is not a primary concern. If not, it is not justified to invest effort in increasing it. Code qualities Joey Paquet, 2006-2014 20SOEN 6441 - Advanced Programming Practices

21. Concordia University Department of Computer Science and Software Engineering Click to edit Master title style Practices to achieve quality code Joey Paquet, 2006-2014 21SOEN 6441 - Advanced Programming Practices

22. Concordia University Department of Computer Science and Software Engineering Write tests first Testing after the code has been produced introduces a bias : test cases are written according to the code. Writing test cases before the code forces you to think in advance of what the software is supposed to do and determine how it reacts to normal situations, and to abnormal situations. Then it becomes easier to write the code, and it is less likely that you will have to change the code to adapt it to a situation you did not expect. In other words, the tests help to develop the “code specifications”. Code quality: practices Joey Paquet, 2006-2014 22SOEN 6441 - Advanced Programming Practices

23. Concordia University Department of Computer Science and Software Engineering Write tests first (continued…) Related to: Interface specifications “Designing by interfaces” [Gamma et al.] “Design by contract” [Meyer] Test-driven development [Beck] Refactoring Increases maintainability, understandability of the code. Some find that this is counterproductive. However, when used in combination with a testing framework (e.g. JUnit), it justifies the cost investment by having proper testing in place as the code is being developed and later changed. Code quality: practices Joey Paquet, 2006-2014 23SOEN 6441 - Advanced Programming Practices

24. Concordia University Department of Computer Science and Software Engineering Encapsulate by convention, reveal by need In a famous paper written in 1972, David Parnas set out the principles of information hiding: “The developer of a software component must be provided with all the information necessary to carry out the given responsibilities assigned to the component, and should be provided with no other information.” This principle is very general and can be applied at all abstraction levels and in most software development activities. Code quality: practices Joey Paquet, 2006-2014 24SOEN 6441 - Advanced Programming Practices

25. Concordia University Department of Computer Science and Software Engineering Encapsulate by convention, reveal by need (continued…) According to [Shalloway, Bain], there are several types of encapsulation: Data encapsulation: Hiding data members of a class using private data members and providing accessors and/or mutators. Implementation encapsulation: Do not let a client object know the implementation details of a method. Use clear and minimal interfaces that do not use “control coupling”. Type encapsulation: Hiding the type of objects being used, e.g. factory and abstract factory patterns, abstract classes and polymorphism. Construction encapsulation: Hiding how objects are being constructed, e.g. singleton pattern, builder pattern, factory pattern. Design encapsulation: The internal parts of a component are hidden. A limited interface is provided, e.g. using a façade pattern. Code quality: practices Joey Paquet, 2006-2014 25SOEN 6441 - Advanced Programming Practices

26. Concordia University Department of Computer Science and Software Engineering Avoid redundancy Redundant code is often introduced when a new requirement emerges that is a slight variation of an existing one for which there is already an implemented solution. Quick solution: Copy the code, make a slight change to it to accommodate for differences. Problem: It is then likely that if one is changed, the other also needs to be changed, and that “dependency” is not necessarily apparent. Better solution: Use the same objects/procedure/design and make it provide a solution to both requirements, using if / switch or #ifdef to make the code behave differently in different situations. Code quality: practices Joey Paquet, 2006-2014 26SOEN 6441 - Advanced Programming Practices

27. Concordia University Department of Computer Science and Software Engineering Don’t do more than you need Similar to XP’s “simple design”. However, “simplicity” is subjective. Determine what needs to be done, do it, and don’t invest in unnecessary complexity. Don’t overdo this. It does not mean “don’t try to foresee”, or “software architecture is not important”. Think ahead, but not too much, and don’t invent features that are not expressed needs. Saves time by developing only necessary code/structure. Allows you to concentrate on what is really important now. All code that you write “for later” has to be maintained, documented, etc. before it is actually used. It is also likely that the system changes introduced in the mean time will invalidate this code/solution. Code quality: practices Joey Paquet, 2006-2014 27SOEN 6441 - Advanced Programming Practices

28. Concordia University Department of Computer Science and Software Engineering Treat conceptually similar things the same way Related to “Find what varies and encapsulate it” e.g. strategy pattern, etc [Gamma et al.] “Information hiding” [Parnas] Abstract classes, interfaces, polymorphism. If a client object is using several different objects/services that conceptually do the same thing, all should be exposed to it in the same manner, i.e. using the same interface. That might mean to introduce unnecessary interface elements to simpler components to match the complexity of more complex ones. Leads to adaptable code: One can add more of such similar services, as they are all using the same interface. Client objects can use these new services with minimal changes, e.g. using different parameter values on calling a method. Code quality: practices Joey Paquet, 2006-2014 28SOEN 6441 - Advanced Programming Practices

29. Concordia University Department of Computer Science and Software Engineering Favor composition over class inheritance If you need to vary behavior, don’t achieve it by creating a subclass. Rather, create a separate “behavioral class” hierarchy and use composition to link this behavior to the original class. Positive effects: Encapsulates common behavioral classes, increases maintainability. Permits better reuse through a common interface. Related to many design patterns, e.g. strategy, adapter, decorator. Code quality: practices Joey Paquet, 2006-2014 29SOEN 6441 - Advanced Programming Practices

30. Concordia University Department of Computer Science and Software Engineering Design to interfaces Upon writing any component or class, first design its interface, i.e. determine what information, behavior (or services) it needs to expose to the exterior. Class level: determine what is public and private. Component level: determine what services are necessary to be exposed, use patterns like a façade to expose necessary services, and enforce that only the façade is used to access this component. Related to : “design by contract” [Meyer] UML responsibilities CRC cards [Cunningham] Code quality: practices Joey Paquet, 2006-2014 30SOEN 6441 - Advanced Programming Practices

31. Concordia University Department of Computer Science and Software Engineering Separate use from construction Two important topics in designing software: How instances will be used (i.e. its public interface). How the instances are created (i.e. constructor design). In the case of complex classes, construction can be a complex operation, e.g. when A class is composed of other classes (i.e. has members that are themselves complex classes). These members can take different forms depending on the context of use. As much as possible, the complexity of construction, as well as the variation factors should be hidden from the outside. For example, builder pattern, factory pattern. Code quality: practices Joey Paquet, 2006-2014 31SOEN 6441 - Advanced Programming Practices

32. Concordia University Department of Computer Science and Software Engineering Refactor code as needed “Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet it improves its internal structure.” [Fowler] Examples: Extract a method that needs to be generalized. Move a method. Rename a method. Use polymorphism or templates to generalize common code. Create and reorganize packages. The more changes are likely, the more refactoring is important: Changing software often creates messy code. Better designed/understandable code makes changes easier to apply. Code quality: practices Joey Paquet, 2006-2014 32SOEN 6441 - Advanced Programming Practices

33. Concordia University Department of Computer Science and Software Engineering Prototyping If you are not sure whether a solution will actually work, it may be a good idea to prototype it. Same if you have different alternatives and it is not clear which one is most appropriate. Prototyping means implementing the design in a “quick and dirty” way, in order to get feedback. Development effort of the prototype should be highly focused on getting proper feedback. Be very careful if you reuse the prototype code in the operational version. Code quality: practices Joey Paquet, 2006-2014 33SOEN 6441 - Advanced Programming Practices

34. Concordia University Department of Computer Science and Software Engineering Steve McConnell. Software Project Survival Guide (Developer Best Practice). Microsoft Press, 1997. ISBN-13: 978-1572316218 Larry Constantine. Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design. Yourdon Press, 1979. ISBN-13: 978-0138544713 Bertrand Meyer. Design by Contract, in Advances in Object-Oriented Software Engineering, eds. D. Mandrioli and B. Meyer, Prentice Hall, 1991, pp. 1-50. Kent Beck. Test-Driven Development: By Example. Addison-Wesley Professional, 2002. ISBN-13: 978-0321146533 David Parnas. On the Criteria To Be Used in Decomposing Systems into Modules. Communications of the ACM 15 (12): 1053–58. 1972. doi:10.1145/361598.361623 Alan Shalloway, Scott Bain, Ken Pugh, Amir Kolsky. Essential Skills for the Agile Developer: A Guide to Better Programming and Design. Addison-Wesley Professional, 2011. ISBN-13: 978-0321543738 Shalloway, Bain, Net Objectives. Code qualities and coding practices.Code qualities and coding practices References Joey Paquet, 2006-2014 34SOEN 6441 - Advanced Programming Practices