Page 117 - DCAP405_SOFTWARE_ENGINEERING

Software Engineering

Notes

Notes These can be useful pieces of software, new techniques or whatever; the important
thing is that it gives you at least one more good option for writing your code.

Maintain your Flow

Flow is a psychological state that you get into when you’re absorbed in your work (sportsmen
call it being “in the zone”). Have you ever gotten really into your work, so much so that
suddenly an hour has passed without you noticing? That’s flow! In this state, you tend to be very
productive and very focused on the task at hand. Therefore, you want to try to stay in this state
for as much of the time as possible. It can take as much as 15 minutes to get into the flow, so it’s
important to minimise things that will pull you out of the flow (once you’re out, that’s
15 minutes largely wasted). That means try to avoid distractions, turn off the e-mail alert beep,
listen to music to block out background noise, turn off your web browser. Whatever it takes!
Make your Code Unsurprising

When someone glances at a chunk of code, they can often form a quick impression of what that
chunk of code does. It is convenient when this impression is accurate; it can be a real problem if
the impression is misleading and they makes changes to the code before they realise. The
‘principle of least surprise’ is that you should try to make your code’s actual functionality as
close as possible to the typical quick impression. Or, to put it another way, you should try to
write your code so that it communicates its functionality accurately in a very short (pain-free)
amount of time. This means doing things like picking informative variable/function names,
writing informative (and succinct) comments, and making the layout easy to read.

Don’t Program by Coincidence

‘Programming by coincidence’ is what happens when you “just get started coding” without
thinking about what it is you actually want to achieve. You write some code and it seems to
work. Great. So you write some more. That also seems to works. So you keep on doing this until
one day you add some code and your software falls over. And you have no idea why. Think of
this as the coding equivalent of a random walk; sure, you’re moving, but are you going to end
up in the right place? To avoid this, realise that a bit of planning and careful thought (including
as the project progresses) is a very good thing.

Code Entropy

Disordered code is bad, because it’s more likely to contain bugs. Higher entropy is more
disordered which is bad. So you should try to keep the entropy of your code as low as possible.
This means taking care to keep things neat and tidy as you write the code. It also means fixing
bugs and refactoring messy bits of code. One important aspect of code entropy is that any time
you make a change to your code, the level of entropy will tend to increase (unless you’re very
careful; fixing a bug, for example). If you’re constantly rewriting your code, you’ll be introducing
new bugs all the time and invalidating the testing you’ve done on that code.

Task “So bear in mind that a bit of stability in your code is a good thing.” Analyze this
statement.

110 LOVELY PROFESSIONAL UNIVERSITY