UNIT 1 - Programming

Week [09] – Coding Standards

1
Lesson Learning Outcome

Pass Merit Distinction

LO4 Determine the debugging process and explain the

importance of a coding standard.

P4 Explain the debugging M4 Evaluate how the D4 Critically evaluate why a

process and explain the debugging process can be coding standard is necessary
debugging facilities available used to help develop more in a team as well as for the
in the IDE. secure, robust applications. individual.

P5 Outline the coding

standard that you have used
in your code.

2
General Rules

▪ Rule #1 : Explicit is better than implicit.

▪ Rule #2 : Simplicity is always better than functionality.
▪ Rule #3 : Beautiful is better than ugly.
▪ Rule #4 : Readability counts.
▪ Rule #5 : Make sure anybody can fix anything.

3
Rule #1: Explicit is better than Implicit

Bad Good

def make_complex(*args): def make_complex(x, y):

x, y = args return {'x': x, 'y': y}
return dict(**locals())

▪ In the good code above, x and y are explicitly received from the
caller, and an explicit dictionary is returned.
▪ The developer using this function knows exactly what to do by
reading the first and last lines, which is not the case with the bad
example.
4
General Naming Guidelines
▪ Variables, functions, methods, packages, modules
lower_case_with_underscores

▪ Classes and Exception

CapWords

▪ Protected methods and internal functions

_single_leading_underscore(self, ...)

▪ Private methods
__double_leading_underscore(self, ...)

▪ Constants
ALL_CAPS_WITH_UNDERSCORES

5
Naming Conventions – contd.

Avoid one letter names (especially i, o, l) Fine

Exception: In very short blocks, when the meaning for e in elements:

is clearly visible from the immediate context e.mutate()

Avoid redundant labelling

Bad Good
import audio import audio

core = audio.AudioCore() core = audio.Core()

controller = audio.AudioController()
controller = audio.Controller()

6
Naming Conventions – contd.

Prefer "Reverse notation"

Bad Good
elements = ... elements = ...
elements_active = ... active_elements = ...
elements_defunct = ... defunct_elements ...

Avoid getter and setter methods

Bad Good

person.set_age(42) person.age = 42

7
Indentation & Imports
▪ Use four(4) spaces - and never use tabs.

▪ Import entire modules instead of individual symbols within a module. For

example, for a top-level module canteen that has a file canteen/sessions.py

Bad Good

from canteen import get_user import canteen

From canteen.sessions import import canteen.sessions
get_session from canteen import sessions

8
Use of Comments
▪ Use meaningful comments but use them sparingly
Bad
# If the sign is a stop sign
if sign.color == 'red' and sign.sides == 8:
stop()

Good
def is_stop_sign(sign): Prefer code readability to
return sign.color == 'red' and sign.sides == 8 writing a lot of comments.
Often, small methods are
if is_stop_sign(sign):
more effective than
stop()
comments.

9
Line Lengths

▪ Don't stress over it. 80-100 characters is fine.

▪ Use parentheses for line continuations.

Good
wiki = (
"The Colt Python is a .357 Magnum caliber revolver formerly manufactured "
"by Colt's Manufacturing Company of Hartford, Connecticut. It is sometimes "
'referred to as a "Combat Magnum". It was first introduced in 1955, the '
"same year as Smith & Wesson's M29 .44 Magnum."
)

10
One Statement per line
Bad
print('one'); print('two')
if x == 1: print('one')
if <complex comparison> and <other complex comparison>:
# do something

While some compound statements such as list comprehensions are allowed

and appreciated for their brevity and their expressiveness, it is bad practice
to have two disjointed statements on the same line of code.

11
One Statement per line – Contd.
Good
print('one')
print('two')
if x == 1:
print('one')
cond1 = <complex comparison>
cond2 = <other complex comparison>
if cond1 and cond2:
# do something

12
Lesson Summary

▪ General Rules
▪ Explicit is better than implicit
▪ Naming conventions
▪ Use of comments
▪ Indentation & Imports
▪ Line lengths
▪ One Statement per line

13