i know that the best way to learn about debugging and error-checking is experience, but the problem with experience is so much has become intuitive that it's really hard to teach the very basics to beginning students. I can teach them a bit about insights from the error messages (e.g. if it mentions something about a list), but, I think, of all the stuff I teach my students, this is my weakest point, as I tend to do a lot on gut-feel, and can't really explain how and why I suspected where the error actually lay. I sometimes describe what I doing to my students, and give my reasons, but it feels like I'm making it up as I go along :-(.
Is there a very basic cheat sheet, or tips or, some form of more formalised process or something that I could work through with my beginning students to give them a leg up?
For me, I tend to DAIG (debug as I go), so I test each piece of code or logic from the start, by putting the output to a label to see what I am getting, before moving on. This is especially useful when working with local variables, when Do It may not provide the outputs.
Dear Ken,
I'm not a teacher, but I've started to code in assembly language on the early '80ies.
I agree with you that the experience comes with the errorrs, that is to say by solving errors, so how can your students gain experience while they are in trouble with errors ?
Similarly to what @TIMAI2 has already said, what I normally suggest on this forum, and what I typically do, is "to build the house one brick at a time".
That is: understand what are the requirements of what I want to do (or I've been requested to). Possibly write them down on a paper (a file!). Then to start to implement little chunks of code, each one implementing (only) one requirement and test them separately, so to have a limited area of code to debug. Then Integrate those chunks, one at a time, compatibly with their functionality (i.e. the architecture) and debug the incremetally integrated code.
I reckon that all that is extremely similar to the well known V Model, but without spending so much words about theory, what I suggest is resumed in my first statement: make only one step at a time so to have an easier and smaller environment to test (debug).
This will allow your students to take advantage of a "structured way of thinking" so they will, probably, learn how to make "structured" code, though by using a "blocky" programming language.
Probably you already do in this way, and all what I've said is trivial, but let me say that also in an Agile way of programming, in which many coders (students) participate to a unique huge project, if if each one of them believe he is a "fundamental" brick in a "structured" building, he will perceive himself as a "VIP" (Very Important Programmer)
Operatively ?
Try to separate the categories of errors:
with lists, the most common error is the "out of bound"
with numbers, check for division by zero or unallowed operations
with text, take care about uppercase vs lowercase, unprintable characters, lenghts of strings
with communication, be careful about timings and data type (i.e. text vs bytes), strings terminators,
with databases, out of bound, nested records,
An exercise that your students can do, is to prepare such list of common errors for example in an excel file (for ease of searching), enrich the list as soon as they discover a new error, and share among them, and other classrooms, this "dictionary" of errors.
As I said at the beginning: I'm not a teacher, and therefore today's students hate all of this. Anyway when i was the responsible of a developing team, we've got a lot of benefices form this approach.
Best wishes !!!
When dealing with problems, I am often reminded of the four main accounting errors (from my accountancy studies:
4 Common Accounting Errors
Accounting errors that are evident on a trial balance are easy to identify and fix as part of the accounting close. But for the majority of accounting errors — those that are undetectable at the trial balance level — more effort is required. For this reason, it's important to put processes in place to detect these four common accounting errors:
Data entry errors. These are basic accounting mistakes. Data entry errors include transposed numbers, typos and other (often manual) slipups, like a misplaced decimal.
Errors of commission. This category of errors arises from an incorrect action — for example, a transaction is recorded but some part of it is wrong, such as using an incorrect general ledger account number or using a miscalculated or improperly rounded value. Reversed entries, where debits and credits are improperly switched, and duplicated entries are also errors of commission.
Errors of omission. These errors happen when a transaction is overlooked and not recorded. It's simply left out of the accounting records.
Errors of principle. Errors of principle occur when the wrong accounting treatment is applied to a transaction. Errors of principle are significant technical accounting errors, as the resultant transaction will not be in accordance with Generally Accepted Accounting Principles (GAAP), either because the wrong guidance was followed or because it was followed incorrectly.
It's especially tricky to find accounting errors that compensate for each other. Sometimes these errors manage to unintentionally offset each other, masking the underlying mistake. For example, lease expenses for two identical company cars can be duplicated in one department and omitted in another, making totals appear accurate even though individual departmental costs (and associated key performance indicators) are incorrect.
These could also be applied to the work we do when constructing blocks code...
This is modelled after the mantra of TV District Attorneys trying to gather evidence to convict mobsters. Their motto is Follow the Money.
Look for important variables, and search the code for where they are born (global init, procedure parameters,...) and where and how they change their values.
Look for contradictions in the data types assigned to them, for example lazy 'not found' TinyDB lookup results for lists.
Sometimes the name of a variable can be a hint that the author is confused as to their purpose. Look for names like 'list' or 'name'. Look for places where the author should have added a suffix like _List to the variable name to remind them that this will be a list of items, rather than a single item. Some foreign languages don't have plural suffixes like the English 's' suffix.
A big problem can often be divided into smaller problems.
For example, in IOT projects, an AI2 app that fails to talk to an IOT device should be replaced with an off the shelf BlueTooth terminal app, to verify that the IOT device is up and running okay.
Malfunctioning procedures can be located by stubbing them out with small replacement procedures that return constant results.
