Team #1 Presentation, Death March Projects

Low-Level Design & Programming

Introduction

We have talked about system analysis, which is comparable to the planning of an entire city. SA looks at the system as a whole and where software might fit in.

We have talked about requirements analysis, which is comparable to planning one house within a city. RA looks at what features we want in a particular piece of software.

We have talked about technical design, which is comparable to designing the blueprint for one house. TD looks at exactly how to create software that contains the features we want.

Now we will talk about low-level design and coding. This is analogous to building a house, once you have the drawings from an architect.

Are there known methods for building a house correctly, given a known design?

The answer is YES.

It is pretty clear how to build a house correctly. There are building codes and books that specify it.

There should be so many 2x4's per foot in the walls, so many nails per foot for wallboard, certain thickness of flooring, etc.

Construction is less "art" and "experience" than architecture is. It is more well-known than design and architecture.

The same is true for software.

Given a good design, it is more well-known how to program the design "correctly".

(Of course, this does not always happen, but it can.)

The "building codes" for software are in Code Complete and Writing Solid Code. If you want to know how to code something well, just look it up. (If you find other good books, bring them in to show us.)

For example -- Don't modify input parameters in a routine. If you need a work variable, create a separate one.

Or (one of my pet peeves) -- Don't use too many levels of nesting for IF statements. It is too hard to understand the logic when reading them. Unwind the IFs with some EXIT or GOTO statements. (Give example on board.)

Topics from CC 19

This chapter is about comments. This may seem like a strange place to start talking about how to program, but it actually makes sense. If your program is readable, it is a good program. If your program is not easily readable, it needs improvement.

Have a student read paragraph at bottom of 454. Explain.

Talk about checked items on pages 456-457. These are really guidelines for good coding. Read them as statements, rather than questions.

Comments about the dialog on pages 458-461? (My take... Code should be mostly self documenting. You don't need long-winded comments everywhere. But you do need comments to explain WHY the code is doing something and how the pieces fit together. It is very hard to make the code itself explain this.)

Talk about the 5 kinds of comments on page 463. Have students explain each one. Only the last two are worthwhile comments.

See examples of bad comment style on page 465. Explain why these are a pain to maintain. Page 466 shows how to do this the right way.

Suggestion -- Write the comments, then write the code. This seems unusual, but it has some strong advantages.

It helps you think through the code. As you write the comments, you think of things you have to take care of, or conditions to check for.

The comments will be correct. They will match the code (unless you have a bug), because you wrote the code based on the comment.

Tip -- Write comments for logical paragraphs of code. You don't need comments on every line of code.

See HOW versus WHY example on page 473.

Tip -- Definitely document surprises or unusual pieces of code. See example on page 474.

Tip -- If you find yourself trying to document a complex (tricky) piece of code, you are better off rewriting the code so it is not so tricky.

Put comment blocks at the start of a routine.

They are a good idea for all routines.

It should contain a SUMMARY of the routine, its change HISTORY, and any SPECIAL NOTES for the next programmer.

Show example on board.

Look at funny example on page 482.

Summary -- Write programs as if they will be taken over by someone less experienced than you. For your class project, assume that your code will be given to a freshman CS class and they should understand it.

Topics from CC 31, 32

Student read quote on page 757. (Read both paragraphs.)

Read checked items on page 757, and explain each one.

TIP: Experiment. If you are using (or thinking about using) a new feature, write a small test program first.

You can learn a lot about the new feature very quickly this way.

You won't confuse yourself with trying to separate errors in the new feature from errors in the bigger program.

Small test programs are a great tool.

TIP: Think before you program. Your code will be a lot better.

If you aren't sure how to code something, research solutions or write some small tests.

If you need fresh ideas, take a walk or play some basketball or go shopping.

(It is possible to over-analyze, but most programmers do too little thinking and too much typing.)

FACT: It doesn't matter how many hours you work, or how much code you write. What matters is how much correct code you write.

Optional: Tell story about my friend Dave you worked many hours and wrote lots of code -- most of it wrong.

TIP: Don't be religious in following any method of software process or design or programming.

Always ask yourself whether your favorite method still makes sense in this case.

Keep an eye on the goal (which may vary with the project) and use methods that help get you there.

FACT: And finally, the simplicity (clarity) of software is the key metric that distinguishes programming ability...

Junior programmers can create simple solutions to simple problems.

Senior programmers create complex solutions to complex problems.

Great programmers find simple solutions to complex problems.

The code written by top-notch programmers may appear easy and obvious, once it is finished. But it is vastly more difficult to create.

Just as the goal of science is to find simplicity and order in a seemingly complex universe, the goal of programming should be to find simple solutions to complex problems.