1. SE: CHAPTER 7 Writing The Program
Standards for Programming
Guidelines for Reuse
Using Design to Frame the Code
Internal Documentation
External Documentation

2. Writing the Program This task can be daunting for several reasons
The designers may not have addressed all of the idiosyncrasies of the platform and programming environment
Structures and relationships that are easy to describe with charts and tables are not always straightforward to write as code
We must write the code in a way that is understandable not only to us, but also to others as the system evolves over time
We must take advantages of the characteristics of the designer’s organization, the data structures, and the programming language’s constructs, while still creating code that is easily reusable
The guidelines are generally applicable to any implementation

3. 7.1 Programming Standards and Procedures
You must know your organization’s standards and procedures before you begin to write code
Companies usually insist that their code conform to style, format, and content standards
So the code and the associated documents should be written clear to everyone who will read them

4. Standards for You Standards and Procedures
They can help you to organize your thoughts and avoid mistakes
Some of the procedures involve methods of documenting your code, so it is clear and easy to follow
Good documentation allows you to leave and return to your work without losing track of what you had been doing
Standardized documentation also helps in locating faults and making changes
They also help in translating design to code
Possibility of error is minimized

5. Standards for Others Standards for others
Once your code is complete, others are likely to use it in a variety of ways
So, it is essential that you organize, format, and document your code to make it easy for others to understand what it does and how it works
Example see p.309

6. Matching Design with Implementation
The most important Standards
Is the need for a direct correspondence between the program design and the program code
The entire design process is of little value if the design’s structure is not carried forward into the code
The design characteristics , such as low coupling, high cohesion, and well-defined interfaces should also be program characteristics
Any change to the program should be made first to the high-level design and then are traced through lower design levels to the code

7. 7.2 Programming Guidelines
Remember that
The design is a guide to the function or purpose of each component, but the programmer has great flexibility in implementing the design as code
We will discuss several guidelines that apply to programming in general
Regardless of the programming languages
Each program component involves
At least three major aspects: control structures, algorithms, and data structures

8. Control structures Program structure should reflect the design
Many of the control structures are suggested by the architecture and design
In the more procedural designs, control depends on the structure of the code itself
It is important for your program to reflect the design’s control structure
Many guidelines and standards suggest that the code be written so you can read it easily
It is helpful whenever possible to have the required action follow soon after the decision that generates it

9. Control structures Modularity is a good design attribute
By building a program from modular blocks,
we can hide implementation details at different levels
Making the entire system easier to understand, test and maintain
We can use macros, procedures, subroutines, methods and inheritance to hide details
While enhancing understandability

10. Control structures Generality is a virtue
In writing your code, keep in mind that generality is a virtue
Do not make your code more specialized than it needs to be
Do not make your components so general that performance and understanding are affected
Remember to use parameter names and components to exhibit component coupling
Use global variables as less as possible
Indicate clearly the parameters being passed to and back
Dependence among components must visible
Components should hide calculation details

11. Algorithms Take great discretion in performance
Or efficiency of your implementation
Making the code faster may involve hidden costs
The cost to write and modify the faster code
The cost and time to test the code
The cost of time for users to understand
you should balance execution time with design quality, standards and customer requirements
Compiler may make your seemingly faster optimized code actually slow down

12. Data Structures Make data format or store straightforward
Keeping the program simple
Data manipulation can influence your choice of data structures
See example in p
The calculation are simplified just by changing the way the data are defined
This makes the program easier to understand, test and modify
Using data structures to determine a program structure
Data structures can influence the organization and flow of a program, including the choice of language

13. General Guidelines
General guidelines in preserving design quality in your code
Localizing input and output
Including pseudo-code
Revising and rewriting, not patching
Reuse
Producer reuse
Creating components to be reused in subsequent applications
Consumer reuse
Using components that were originally developed for other projects

14. 7.3 Documentation Program documentation
The written description that explain what the programs do and how they do it
Internal documentation
The descriptive material written directly within the code
External documentation
All other documentation

15. Internal Documentation
Herder comment block
It includes:
What, who, where, when, why, how
More detailed information
Other program comments
Additional comments enlighten readers
Statements are formatted clearly
Labels, variables and data names are descriptive and easy to distinguish
Comments can break the code into phases
Update comments to reflect the change
State the intention, rather than the behavior itself
Write the comments as you write the code
Beware of code that is difficult to comment
This often suggest that the design should be simplified

16. Internal Documentation
Other program comments
Meaningful variable names and statement labels
Formatting to enhance understanding
Proper indentation and spacing of statements to reflect the basic control structure
Documenting data

17. External Documentation
It answers the same questions
Who, what, why, where, how
It often includes an overview of the system’s components
Diagrams with narrative description
Show how data are shared and used
The contents
Describing the problem
Explain the problem that is being addressed
What options were considered for solutions
Why a particular solution was chosen
When the components is invoked and why it is needed

18. External Documentation
The contents
Describing the algorithm
The choice of the algorithm
Explain each algorithm used
Explain the special cases and how they are handled
Explain your rationale and the description of any error handling
Describing the data
Data structures used
Data flow among components
Overview of classes and objects
Interactions of objects

19. Exercises
On Page 330
Problem 5
Problem 6
Problem 9
Problem 11