Contents

Structuring Your Repository....................................................................................................................1

License....................................................................................................................................................1
README...............................................................................................................................................1
Module Code..........................................................................................................................................1
setup.py..................................................................................................................................................2
requirements.txt.....................................................................................................................................2
Documentation.......................................................................................................................................2
Tests........................................................................................................................................................2
Code Structure...........................................................................................................................................2
Variable Naming Conventions..............................................................................................................2
Variable Access......................................................................................................................................2
Avoid Redundant code & Labeling......................................................................................................3
Avoid Deep Nesting...............................................................................................................................3
Avoid Explicit Comparisons (when possible)......................................................................................3
Avoid Long Lines...................................................................................................................................3
One Statement per Line........................................................................................................................3
Strive for Simplicity...............................................................................................................................3
Commenting...........................................................................................................................................3

Python Best Practices

Structuring Your Repository
For Python, in particular there are a few components that should exist within your repo and you
must have all of these, at least in a basic skeletal form, before actual code begins.

License – [Root-Folder]: The representation of a set of license rights in a text or binary file,

typically digitally signed and/or encrypted in order to prove authenticity.

README – [Root-Folder]: Getting a basic README file in place can help you describe

your project, define its purpose, and outline the basic functionality.

Module Code – [Root-Folder] or [/module]: Be sure to place your actual code inside a

properly-named sub-directory (e.g. /module), or for a single-file project, within root itself.
 setup.py – [Root-Folder]: A basic setup.py script is very common in Python projects,
allowing “Distutils” to properly build and distribute the modules your project needs.

requirements.txt – [Root-Folder]: It can be used to specify development modules and

other dependencies that are required to work on the project properly.

Documentation – [/docs]: Documentation is a key component to a well-structured project,

and typically it is placed in the /docs directory.

Tests – [/tests]: Just like documentation, tests also typically exist in most projects, and
should be placed in their own respective directory.

Code Structure

Variable Naming Conventions

● camelCase I.e. Ball_Radius (You should always use CamelCase for class names)

● Underscore

o between words also known as snake case -> ball_radius (Snake case is the practice
of writing compound words or phrases in which the elements are separated with one
underscore )
o at start (private/protected) -> _speed ( “_” is a simple convention at the start to
distinguish private and protected variables from the public ones )
● Uppercase for constants I.e. GRAVITY

● Capitalize first word for classes I.e. Person()

Variable Access
● Avoid global variables unless it drastically simplifies code
○ If the variable is used throughout the entire program, global is probably fine
● Avoid public variables for classes. Enforce the idea of encapsulation
○ Instead of public variables, create getters and setters

Avoid Redundant code & Labeling

Eliminate redundancy and reuse existing code in order to create more readable code
Avoid Deep Nesting
Nested loops are frequently (but not always) bad practice, because they're frequently (but not
always) overkill for what you're trying to do. In many cases, there's a much faster and less
wasteful way to accomplish the goal you're trying to achieve.

Avoid Explicit Comparisons (when possible)

Use comparison operators only where necessary to speed up the program execution time
If attr == True:
Print(‘True!’)
VS
If attr:
Print(“attr is true!”)

Avoid Long Lines

Too many operations per line is confusing to read
Points =
np.asarray(open(sys.argv[1]).read().strip().replace(“\n , ”
”).split(“ )).astype(np.float).reshape((-1, 2))

One Statement per Line

Don’t write multiple statements in one line

Strive for Simplicity

code should be explicit and straight forward

Commenting
● Explain logic in a clear and understandable manner
● Keep them up to date
○ Outdated comments lead to more confusion
● Avoiding obvious comments
#print the age
print(age)
● When possible, rewrite the code so no comments are necessary

Exception Handling – Try, Except, Finally

If exceptions are not handled properly, the program may terminate prematurely. It can cause data
corruption or unwanted results. So Always try to handle the exception in the code to avoid abnormal
termination of the program.

Logging in Lambda :
Log exception in your CloudWatch log Groups To output logs from your function code, you can
use  any logging library such as logging that writes to stdout or stderr.

Custom exception classes

Python has many built-in exceptions which forces your program to output an error when
something in it goes wrong. However, sometimes you may need to create custom exceptions that
serves your purpose. In Python, users can define such exceptions by creating a new class

Python version and installation

Always try to install Python from its official website for authenticity and to keep yourself safe
from viruses and always try to use the latest version for writing Python code if there is no
dependency of version .

Using Lambda with Cloud Formation

Whenever creating a lambda in a cloud formation template keep lambda in a separate file and
use AWS CLI to package and deploy the cloud formation template