Programming common mistakes

Common mistakes

• Confusing a character with a string

  Treating a character and a string as the same data type.

  Fix itA character stores one character, whereas a string stores a sequence of characters.

• Assuming a pre-condition loop always runs once

  Assuming that an indefinite loop executes its body at least once regardless of where its condition is tested.

  Fix itA condition at the start is tested before the body, so the body may execute zero times. A condition at the end is tested after the body, so the body executes at least once.

• Confusing integer division with the remainder

  Treating 17 // 5 and 17 % 5 as the same operation or expecting both to produce 3.

  Fix itUse // for the integer-division result, which is 3, and % for the remainder, which is 2.

• Confusing equality with assignment

  Writing = when testing whether two values are equal, such as score = 50.

  Fix itUse == for an equality comparison, such as score == 50. The required equality operator is different from the single equals symbol.

• Confusing OR with XOR

  Assuming OR requires exactly one input to be True.

  Fix itOR is True when at least one input is True, including when both inputs are True. XOR is True only when exactly one input is True.

• Confusing a meaningful name with a constant

  Assuming that any value with an uppercase or descriptive name is automatically a constant in every programming language.

  Fix itExplain that a constant is intended not to change and, where relevant, use the language's appropriate constant declaration, such as const in C#.

• Concatenating a number without converting it

  Attempting to join a string and an integer directly, such as "Score: " + score in Python 3.

  Fix itConvert the integer to a string first, for example "Score: " + str(score).

• Excluding the upper limit

  Writing random.randint(1, 5) when values from 1 to 6 are required.

  Fix itRemember that Python randint includes both limits, so use random.randint(1, 6) for the range 1 to 6 inclusive.

• Putting the risky statement outside the try block

  The code that may cause the exception is written before the try block, so the exception is not handled by the associated except block.

  Fix itPlace the potentially failing operation, such as input conversion, inside the try block and put the planned response inside the except block.

• Confusing a subroutine with a variable

  Describing a subroutine as a place used to store a value.

  Fix itA subroutine is a named block of executable code. A variable and a subroutine have different purposes.