Recall there are several different ways to get help:
Gradescope will be most effective if you use it throughout the development process instead of right before the due date. You will likely have two kinds of failing tests: 1) your code doesn’t do what you think it does, and 2) your code works as intended, but there is a difference between your interpretation of the assignment and what was intended. When trying to fix a failing test, investigate both possibilities.
A couple of cautions before submitting Lab 3:
Using constants, e.g., in fools_encrypt
Recall that literal values in functions, e.g., “3” in fools_encrypt, are
good candidates to be made into constants. This value is a particularly
useful place for a constant since fools_encrypt and fools_decrypt need
to be in sync, and you could easily want to the change the expansion.
Notice that in the provided
fools_decrypt, the
expansion is implemented as a constant.
“Dead code”
Be on the look-out for “dead code”, that is code that doesn’t do anything. For example
for letter in 'abc':
s.find(letter)
index = s.find(letter)
The first expression in the loop s.find(letter) does not do
anything. The result value is not assigned to variable, and the code itself
is repeated on the next line. While dead code does not affect correctness,
it is not without cost. It makes our programs run slower (for no benefit)
and makes it harder to reason about the code. Always review your
implementation for dead code.
Unnecessary parentheses
Avoid unneccessary parentheses, e.g., ALPHABET[:(index)].
These parentheses don’t impact correctness but are not “good style” because
they increase the cognitive burden of reading your code. When parentheses
seem unneccessary, more effort is required because the reader starts to
wonder if they misunderstood your code and in fact the parentheses are
needed. And in doing so the reader spends more time thinking about your
code than if there were no parentheses.
Testing code left in programs
Be sure to remove testing code in your programs, including that at the global level (that is outside a function definition). Unless otherwise specified, you shouldn’t have any function invocations or expressions that execute when your script is run with the green arrow in Thonny.
Break long lines
Break long comments, Python expressions, etc., into multiple lines, e.g.,
# A really long comment that is very hard to read will get awkwardly wrapped when my code is printed making life hard for the graders and anyone else who reads my code
# A really long comment that is nicely split onto multiple lines
# making life easier for anyone reading my code