Page 116 - DCAP405_SOFTWARE_ENGINEERING

Unit 7: Software Engineering Practice

Notes
Example: Assert (x >= 0)

If the variable x is less than zero then the program will immediately stop at this point.
During development this kind of information is invaluable and since the program has stopped
at the first point it spotted something wrong, you don’t have to work backwards from a garbage
final output to find where the program failed.

Handle Errors Nicely

Asserts are a great way of validating data and are very useful during development, however
once a program is in the hands of the users you want your error handling to be a little nicer than
stopping the program immediately. There is nothing more frustrating than a program that just
dies without warning or explanation. Most modern languages have support for handling
problems your code encounters using Exceptions. Exceptions are generated when something
goes wrong and bubble up until they are caught and dealt with. The advantage of exceptions is
that they can be used without your code having to pass around error-code results from function
to function. Using exceptions properly is a complex subject, because the exception handling
represents a different path through the code, but a simple rule of thumb is: ‘Throw an exception
when a problem is first encountered, catch it at the first point that can deal with it’. In programs
with a GUI (Graphical User Interface) this usually means there is a catchall at the user interface
layer that displays a message to the user (or something similar) before attempting to save the
data and then shutting down.

Keep it Simple

The simpler your code is, the easier it is to construct and maintain. So, subject to the constraints
of our objectives, the simpler you can make your code the better. This has a connection to
premature optimisation (see this post ), because optimised code tends to be less simple. We
think a reasonable rule-of-thumb is that unless most simple way of doing something will be
obviously too inefficient, it’s worth trying. You can always change it later and, because it’s
simple code, this shouldn’t be too hard. One way to describe this is to paraphrase Albert Einstein:
Code should be as simple as possible, but no simpler.

Tidy up after Yourself

Once you start to leave one or two things unfixed, it becomes much easier to leave “just one
more”, and soon your code is a wreck. There should not be a single “broken window” in the
code you’re building (the phrase “broken window” comes from a study that showed that a
major indicator of the state of a building was a single broken window; once one is broken,
people care a lot less about maintaining the rest, it seems). The book “The Pragmatic Programmer”
has a nice description of this.

Learn New Tools

If all you have is a hammer, then all your problems tend to look like nails. The way to avoid this
is to have more than one tool. In general, you want to have a good, broad selection of tools with
which to write your code. A good way to acquire this is to try to learn the occasional new tool as
you go along.

LOVELY PROFESSIONAL UNIVERSITY 109