* 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