* for writing in general:
The Elements of Style - Strunk and White
for programming-writing:
The Elements of Programming Style - Kernighan
* Literate Programming (Donald Knuth) -
taking ideas from MMM Chapter 15 even further
in terms of writing readable code;
* computer programs are made to be read by people, not just
computers...
* avoid obvious-to-the point-of-insulting comments...
int x;
...
x = x + 1; /* add 1 to x */
* think of "why" based comments as building premises to a
conclusion!
* smidgen related to white-box testing:
; say my test suite includes: blah being true; blah being false; beah being true; beah being false; moo truel meh true
; make sure that you see that that test suite of test cases does provide statement coverage,
; but NOT branch coverage (didn't exercise the branch of not entering the while loop and skipping its body;
; didn't exercise the branch of if (meh) being false...
if (blah)
{
do this;
do that;
if (beah)
{
ook;
}
else
{
ack;
}
}
while (moo)
{
if (meh)
{
ok;
}
}
* back to black-box testing:
* consider equivalence class partitioning;
* consider the inputs as partitioned into classes for which the
software's behavior should be the same,
make sure you test at least one value from each equivalence class;
* it isn't enough to just pull some number of test cases
from each equivalence class;
...you also need to do boundary value analysis,
and include test cases for boundary values;
* getting into stricter SW engineering terms,
ideally you don't test JUST boundary,
but also also values just outside the "edges", both ways!
* absolute value?
* 0 is a boundary, so you'd test with 0 as an input;
* -0.1 is just less than that boundary, it could work as
a value just outside the 0 boundary in one direction
* 0.1 is just greater than that boundary, it could work
as a value just outside the 0 boundary in the other direction