Chapter 5 Coding Ronald J Leach Copyright Ronald

Chapter 5: Coding Ronald J. Leach Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 1

Coding Practices Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 2

Standard Interfaces • Defined APIs • Languages – ANSI C, Ada, C++, Java • Operating System – Linux, UNIX, POSIX, Windows, Macintosh, i. OS, Android • Software – Database, spreadsheet, communications Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 3

Standard Interfaces, cont. • User Interfaces – X, UIL, Windows, SDK • Formats: – TIF, GIF, RTF, JPEG. . . • Local standards – coding standards, interface standards Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 4

Standards for Coding include: • White space – Blank lines – Spacing – Indentation – Continuation lines – Braces and parentheses • Comments Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 5

Standards for Coding include: • Standard naming conventions – Name formats – General guidelines for variable names Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 6

Standards for Program Organization • • • Program files Encapsulation and information hiding Readme file Header files Source files Makefiles Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 7

Standards for File Organization • File prolog • Header file (class definition) (*. h) • Order of contents – Format of class declarations – Method (function) documentation in header file • Method function implementation and documentation in source file Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 8

Coding Issues Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 9

Interfaces and coupling • Consider the nature of coupling between components. • There are many coupling metrics that measure the interconnection between program units. • Generally speaking, the less coupling between modules, the better, at least from the perspective of using modules as components. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 10

Coupling can guide test effort • Coupling-based testing is based on the premise that system errors occur most frequently at unit boundaries and where they interface. • Modules with the most coupling must require the most testing effort. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 11

Coupling can also guide reuse • There are many types of coupling. • We will present them in the order of greatest amount of coupling to smallest amount, under the assumption that we should test in the places where errors are most likely to occur. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 12

Coupling and reuse • If there is coupling, both components must be examined, before either is reused. • We cannot simply reuse a component, unless we know about coupling and interface issues. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 13

Coupling types • • Content coupling Common coupling Control coupling Stamp and data coupling External coupling Message coupling No coupling Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 14

Content coupling • Content coupling is the highest level of coupling between modules. • One module modifies or relies on the internal local data of another module. • Changing one module’s data (location, type, timing) will change the dependent module. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 15

Content coupling, cont. Unit 1 • … • Exception occurs • … Unit 2 • … • Exception is handled • … Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 16

Content coupling, cont. • Systems with modules having content coupling can be tested using recovery testing ideas. • The flow of control is managed in a systematic way by exception handlers. • Ideally, exception handlers bring software execution back to a “safe state. ” • There may be problems if multiple content coupling occurs in a distributed system. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 17

Content coupling, cont. • Content coupling can also cause a disaster in systems. • The problems may be very hard to test. • In languages such as C, using the system calls setjmp and longjmp makes problems hard to test, locate, and fix. • Avoid these non-local GOTO statements whenever possible. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 18

Common coupling • Two modules share the same global data (e. g. a global variable). • Changing the shared resource implies changing all the modules using it. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 19

Common coupling, cont. Unit 1 • … • Use global data • … Unit 2 • … • Use global data • … Global data Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 20

Control coupling • One module controls the logic of another, by passing it information on what to do (e. g. passing a what-to-do flag). • Execution of a loop or program branch depends upon the parameter. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 21

Control coupling, cont. Unit 1 • … • parameter sent • … Unit 2 • … • if (parameter > 0) do this • else do that… Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 22

Data coupling • Modules share data through parameters. • Parameter may be used in a calculation, but does not affect logical flow (loops, branches) of receiving module. • Some researchers call this stamp coupling. – (Others use stamp coupling to mean that only one field of a multi-field record is actually used. ) Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 23

Data coupling, cont. Unit 1 • … • Parameter sent • … Unit 2 • … • Parameter is used, but not for control of program unit. • … Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 24

External coupling • Two modules use data that is external to both. • The external data may have a specified format, communications protocol, or device interface. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 25

External coupling, cont. Unit 1 • … • Use externally specified data • … Unit 2 • … • Use externally specified data • … Communications such as a specified socket Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 26

Message coupling • A very low level of coupling. • Modules do not communicate with each other through parameters. • They use a public interface, such as messages or events, to exchange parameter-less messages. • This is more prevalent in object-oriented systems. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 27

Message coupling, cont. Unit 1 • … • Use external message • … Unit 2 • … • Use external message • … Message such as a mouse click Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 28

The lowest form of coupling • No coupling: modules do not appear to communicate with one another at all. • A minor concern: – Each module might use up system resources, making it hard for the other module to execute. – Very hard to find such errors without extreme stress testing Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 29

No coupling, cont. Unit 1 • … • … Unit 2 • … • … Available memory, virtual memory limits Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 30

Coding Metrics Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 31

Mc. Cabe Cyclomatic Complexity Metric • Based on analysis of the program graph • E – V + 2 P – Here E is the number of edges in the graph – V is the number of vertices – P is the number of parts (= the number of subprograms called, including the main program) Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 32

Mc. Cabe Cyclomatic Complexity Metric Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 33

How Many Regions? Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 34

Why is this metric important? • Study by Enerjy Co. – Classes with a combined cyclomatic complexity of 11 had a fault probability of 0. 28. – Classes with a combined cyclomatic complexity of 74 had a fault probability of 0. 98. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 35

Why is this metric important? • HP’s Medical Products System (now part of Agilent) made anyone writing a function with cyclomatic complexity >= 10 have meetings with two supervisors to explain testing strategy. • Reduced complexity = simpler program logic = better quality programs Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 36

Coding Inspections Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 37

Issues in Coding Inspections • The source code may be examined for adherence to coding standards. • The directory structure may be examined for adherence to naming conventions. • The inputs or outputs from each function may be checked by hand for correctness. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 38

Issues in Coding Inspections • The invariants of each loop may be checked to make sure that the loop exit conditions are met. • Objects may be checked for completeness of coverage of all conditions if some of the object’s methods are overloaded. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 39

Coding and Configuration Management Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 40

Configuration Management • Essential for all but the most trivial projects • Especially important for team projects Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 41

The Razor system Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 42

The Agile Development Case Study: Coding Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 43

Perspectives • The object of coding in an agile development process is to create a high-quality system as rapidly as possible. • As little effort placed on non-coding-related issues during the coding process as is humanly possible. • Little effort placed on coding standards. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 44

Perspectives, cont. • Source code written by different members of the agile team may not follow coding standards about indentation and the actual physical presentation of the formatting. • Standards, if any, will be those used by the IDE. The use of configuration management tools for version control is almost universal. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 45

Perspectives, cont. • Internal documentation of the code will be a lower priority than the actual development and testing of the source code. • The testing of the code is paramount. It is primarily focused on the interfaces between components, COTS products, and subsystems. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 46

Perspectives, cont. • It is not clear if lack of adherence to coding standards in an agile development process will have any effect on the maintenance of such a system over time. • For systems that are expected to have short deployment lifetimes, any maintenance problems that do occur are not likely to be major ones. Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 47

Coding of the Continuing Major Software Development Project Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 48

Coding standards • Have we followed them? • Have we been consistent with naming conventions? Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 49

Requirements Traceability • Have we listed our source code in the RTM? • Has every requirement been implemented? Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 50

Coding and Project Management, Cont. • Perform a status check. • Are we ahead of schedule (unlikely), behind schedule (likely), or approximately on target? • Have there been any unpleasant surprises, any portions of the system that were more difficult than we expected? Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 51

Coding and Project Management • Does any portion of the system require extra attention, perhaps additional resources? • Have technology or market pressures rendered any portion of the system obsolete? Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 52

Coding and Project Management • Perform a status check. • Are we ahead of schedule (unlikely), behind schedule (likely), or approximately on target? • Have there been any unpleasant surprises, any portions of the system that were more difficult than we expected? Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 53

Coding and Project Management • Does any portion of the system require extra attention, perhaps additional resources? • Have technology or market pressures rendered any portion of the system obsolete? (Recall that we did this status check earlier. ) Copyright Ronald J. Leach, 1997, 2009, 2014, 2015 54