code complete(2)

 

Programmers may be similarly influenced by their languages. The words available in a programming language for expressing your programming thoughts certainly determine how you express your thoughts and might even determine what thoughts you can express.

 

 

Understanding the distinction between programming in a language and programming into one is critical to understanding this book. Most of the important programming principles depend not on specific languages but on the way you use them. If your language lacks constructs that you want to use or is prone to other kinds of problems, try to compensate for them. Invent your own coding conventions, standards, class libraries, and other augmentations.

 

Checklist: Major Construction Practices

Coding

• Have you defined how much design will be done up front and how much will be done at the keyboard, while the code is being written?

• Have you defined coding conventions for names, comments, and layout?

• Have you defined specific coding practices that are implied by the architecture, such as how error conditions will be handled, how security will be addressed, what conventions will be used for class interfaces, what standards will apply to reused code, how much to consider performance while coding, and so on?

• Have you identified your location on the technology wave and adjusted your approach to match? If necessary, have you identified how you will program into the language rather than being limited by programming in it?

Teamwork

• Have you defined an integration procedure—that is, have you defined the specific steps a programmer must go through before checking code into the master sources?

• Will programmers program in pairs, or individually, or some combination of the two?

Quality Assurance

• Will programmers write test cases for their code before writing the code itself?

• Will programmers write unit tests for their code regardless of whether they write them first or last?

• Will programmers step through their code in the debugger before they check it in?

• Will programmers integration-test their code before they check it in?

• Will programmers review or inspect each other's code?

 

Tools

• Have you selected a revision control tool?

• Have you selected a language and language version or compiler version?

• Have you selected a framework such as J2EE or Microsoft .NET or explicitly decided not to use a framework?

• Have you decided whether to allow use of nonstandard language features?

• Have you identified and acquired other tools you'll be using—editor, refactoring tool, debugger, test framework, syntax checker, and so on?

Horst Rittel and Melvin Webber defined a "wicked" problem as one that could be clearly defined only by solving it, or by solving part of it (1973).

 

making mistakes is the point of design—it's cheaper to make mistakes and correct designs than it would be to make the same mistakes, recognize them after coding, and have to correct full-blown code. Design is sloppy because a good solution is often only subtly different from a poor one.

 

Software's Primary Technical Imperative: Managing Complexity

Level 1: Software System

 

Level 2: Division into Subsystems or Packages

   If all subsystems can communicate with all other subsystems, you lose the benefit of   separating them at all. Make each subsystem meaningful by restricting communications.

 a program shouldn't contain any circular relationships

Common Subsystems [Business rules Business rules;User interface ;Database access; System dependencies ]

 

Level 3: Division into Classes

 

Level 4: Division into Routines

 

Level 5: Internal Routine Design