Best Practice | Haobin Tan

Best Practices

Tue, 05 Apr 2022 00:00:00 +0000

Beautiful Python Code with PEP 8

Mon, 06 Jul 2020 00:00:00 +0000

Source: How to Write Beautiful Python Code With PEP 8

Naming Conventions

“Explicit is better than implicit.” — The Zen of Python

‼️ Note: Never use l (\ell), O (zero), or I (capital i) single letter names as these can be mistaken for 1 and 0, depending on typeface:

Naming styles

How to choose names

The best way to name your objects in Python is to use descriptive names to make it clear what the object represents.

Always try to use the most concise but descriptive names possible.

❌

# Not recommended
>>> x = 'John Smith'
>>> y, z = x.split()
>>> print(z, y, sep=', ')
'Smith, John'

✅

>>> # Recommended
>>> name = 'John Smith'
>>> first_name, last_name = name.split()
>>> print(last_name, first_name, sep=', ')
'Smith, John'

Code Layout

“Beautiful is better than ugly.” — The Zen of Python

Blank lines

Surround top-level functions and classes with two blank lines

Example:

class MyFirstClass:
 pass

class MySecondClass:
 pass

def top_level_function():
 return None

Surround method definitions inside classes with a single blank line.

Example:

def first_method(self):
 return None

def second_method(self):
 return None

Use blank lines sparingly inside functions to show clear steps.

Example:

def calculate_variance(number_list):
 sum_list = 0
 for number in number_list:
 sum_list = sum_list + number
 mean = sum_list / len(number_list)

 sum_squares = 0
 for number in number_list:
 sum_squares = sum_squares + number**2
 mean_squares = sum_squares / len(number_list)

 return mean_squares - mean**2

Maximum Line Length and Line Breaking

Lines should be limited to 79 characters.

Outlines ways to allow statements to run over several lines:

Assume line continuation if code is contained within parentheses, brackets, or braces:
```
def function(arg_one, arg_two,
 arg_three, arg_four):
 return arg_one
```
Use backslashes to break lines if it is impossible to use implied continuation:
```
from mypkg import example1, \\
 example2, example3
```

if you can use implied continuation, then you should do so.

If line breaking needs to occur around binary operators, like + and *, it should occur before the operator

❌

# Not Recommended
total = (first_variable +
 second_variable -
 third_variable)

✅

# Recommended
total = (first_variable
 + second_variable
 - third_variable)

Indentation

Use 4 consecutive spaces to indicate indentation.
Prefer spaces over tabs.

Indentation Following Line Breaks

When you’re using line continuations to keep lines to under 79 characters, it is useful to use indentation to improve readability. It allows the reader to distinguish between two lines of code and a single line of code that spans two lines.

There are two styles of indentation you can use:

align the indented block with the opening delimiter:
```
 def function(arg_one, arg_two,
 arg_three, arg_four):
 return arg_one
```
Sometimes only 4 spaces are needed to align with the opening delimiter. This will often occur in if statements that span multiple lines as the if, space, and opening bracket make up 4 characters. In this case, it can be difficult to determine where the nested code block inside the if statement begins:

Example:
```
 x = 5
 if (x > 3 and
 x < 10):
 print(x)
```
In this case, PEP 8 provides two alternatives to help improve readability:
- Add a comment after the final condition.
```
x = 5
if (x > 3 and
 x < 10):
 # Both conditions satisfied
 print(x)
```
- Add extra indentation on the line continuation:
```
x = 5
if (x > 3 and
 x < 10):
 print(x)
```
hanging indent: You can use a hanging indent to visually represent a continuation of a line of code.

Example:
```
var = function(
 arg_one, arg_two,
 arg_three, arg_four)
```
‼️ When you’re using a hanging indent, there must not be any arguments on the first line. The following example is not PEP 8 compliant:
```
var = function(arg_one, arg_two,
 arg_three, arg_four)
```
- When using a hanging indent, add extra indentation to distinguish the continued line from code contained inside the function.
  
  ❌
```
# Not Recommended
def function(
 arg_one, arg_two,
 arg_three, arg_four):
 return arg_one
```
  Instead, it’s better to use a double indent on the line continuation. This helps you to distinguish between function arguments and the function body, improving readability:
  
  ✅
```
# Recommended
def function(
 arg_one, arg_two,
 arg_three, arg_four):
 return arg_one
```

Where to Put the Closing Brace

Two options for the position of the closing brace in implied line continuations:

Line up the closing brace with the first non-whitespace character of the previous line:
```
list_of_numbers = [
 1, 2, 3,
 4, 5, 6,
 7, 8, 9
 ]
```
Line up the closing brace with the first character of the line that starts the construct:
```
list_of_numbers = [
 1, 2, 3,
 4, 5, 6,
 7, 8, 9
]
```

Consistency is key, try to stick to one of the above methods.

Comments and Documentations

See: Documenting Python Code

Whitespace in Expressions and Statements

“Sparse is better than dense.”— The Zen of Python

Whitespace Around Binary Operators

Surround the following binary operators with a single space on either side:

Assignment operators (=, +=, -=, and so forth)
Comparisons (==, !=, >, <. >=, <=) and (is, is not, in, not in)
Booleans (and, not, or)

‼️ Note:

When = is used to assign a default value to a function argument, do NOT surround it with spaces.

✅

# Recommended
def function(default_parameter=5):
 # ...

❌

# Not recommended
def function(default_parameter = 5):
 # ...

If there’s more than one operator in a statement, only add whitespace around the operators with the lowest priority. especially when performing mathematical manipulation.

✅

# Recommended
y = x**2 + 5
z = (x+y) * (x-y)

❌

# Not recommended
y = x ** 2 + 5
z = (x + y) * (x - y)

Apply this rule to if statements where there are multiple conditions:

✅

# Recommended
if x>5 and x%2==0:
 print('x is larger than 5 and divisible by 2!')

❌

# Not recommended
if x > 5 and x % 2 == 0:
 print('x is larger than 5 and divisible by 2!')

In slices, colons act as a binary operators. Therefore, the rules outlined in the previous section apply, and there should be the same amount of whitespace either side. The following examples of list slices are valid:

list[3:4]

# Treat the colon as the operator with lowest priority
list[x+1 : x+2]

# In an extended slice, both colons must be
# surrounded by the same amount of whitespace
list[3:4:5]
list[x+1 : x+2 : x+3]

# The space is omitted if a slice parameter is omitted
list[x+1 : x+2 :]

Summary

Surround most operator with whitespace, except:

in function arguments
combining multiple operators in one statement

Programming Recommendations

“Simple is better than complex.”— The Zen of Python

🎯 Goal: readability and simplicity

Don’t compare boolean values to `True` or `False` using the equivalence operator.

❌

# Not recommended
my_bool = 6 > 5
if my_bool == True:
 return '6 is bigger than 5'

✅

# Recommended
if my_bool:
 return '6 is bigger than 5'

Use the fact that empty sequences are falsy in `if` statements.

In Python any empty list, string, or tuple is falsy.

❌

# Not recommended
my_list = []
if not len(my_list):
 print('List is empty!')

✅

# Recommended
my_list = []
if not my_list:
 print('List is empty!')

Use `is not` rather than `not ... is` in `if` statements.

❌

# Not recommended
if not x is None:
 return 'x exists!'

✅

# Recommended
if x is not None:
 return 'x exists!'

Don’t use `if x:` when you mean `if x is not None:`.

❌

# Not recommended
if arg:
 # Do something with arg...

✅

# Recommended
if arg is not None:
 # Do something with arg...

Use `.startswith()` and `.endswith()` instead of slicing.

prefix

❌

# Not recommended
if word[:3] == 'cat':
 print('The word starts with "cat"')

✅

# Recommended
if word.startswith('cat'):
 print('The word starts with "cat"')

suffix

❌

# Not recommended
if file_name[-3:] == 'jpg':
 print('The file is a JPEG')

✅

# Recommended
if file_name.endswith('jpg'):
 print('The file is a JPEG')

Tips and Tricks to Help Ensure Your Code Follows PEP 8

Never ignore PEP 8!!!

Linters

Linters are programs that analyze code and flag errors. They provide suggestions on how to fix the error.

Best linters for Python code:

pycodestyle is a tool to check your Python code against some of the style conventions in PEP 8.

Install pycodestyle using pip:
```
$ pip install pycodestyle
```
flake8 is a tool that combines a debugger, pyflakes, with pycodestyle.

Install flake8 using pip:
```
$ pip install flake8
```

Autoformatters

Autoformatters are programs that refactor your code to conform with PEP 8 automatically. Once such program is black, which autoformats code following most of the rules in PEP 8.

Install black using pip. It requires Python 3.6+ to run:

$ pip install black

Documenting Python Code

Mon, 06 Jul 2020 00:00:00 +0000

Source: Documenting Python Code: A Complete Guide

Commenting vs. Documenting Code

	Description	Audience
Commenting	Purpose and design of code	Maintainers and developers
Documenting	Use and functionality of code	Users

Commenting Code

Comments are created in Python using the pound sign (#) and should be brief statements no longer than a few sentences.

def hello_world():
 # A simple comment preceding a simple print statement
 print("Hello World!")

According to PEP 8, comments should have a maximum length of 72 characters. This is true even if your project changes the max line length to be greater than the recommended 80 characters.

def hello_long_world():
 # A very long statement that just goes on and on and on and on and
 # never ends until after it's reached the 80 char limit
 print("Hellooooooooooooooooooooooooooooooooooooooooooooooooooooooo World")

Purpose of Commenting Code

Planning and reviewing When developing new portion of code, first use comments as a way of planning or outlineing that section of code. Remember to remove these comments once the actual coding has been implemented and reviewed/tested
```
def new_function():
 # Step 1
 # Step 2
 # Step 3
```
Code description Explain the intent of specific sections of code
Algorithmic description When algorithms are used, especially complicated ones, it can be useful to explain how the algorithm works or how it’s implemented within your code.
```
# Using quick sort for performance gains
```
Tagging: The use of tagging can be used to label specific sections of code where known issues or areas of improvement are located. Some examples are: BUG, FIXME, and TODO.
```
# TODO: Add condition for when val is None### 
```

Rules of Commenting

Should be kept brief and focused
Avoid using long comments when possible

Essential rules as suggested by Jeff Atwood:

Keep comments as close to the code being described as possible.
Don’t use complex formatting (such as tables or ASCII figures).
Don’t include redundant information. Assume the reader of the code has a basic understanding of programming principles and language syntax.
Design your code to comment itself. 💪

Commenting Code via Type Hinting (Python 3.5+)

Type hinting was added to Python 3.5 and is an additional form to help the readers of your code.

Example

def hello_name(name: str) -> str:
 return ("Hello {name}")

You can immediately tell that

the function expects the input name to be of a type str, or string.
the expected output of the function will be of a type str, or string, as well.

Documenting Code Base using Docstrings

Docstings Background

Docstrings are built-in strings that, when configured correctly, can help your users and yourself with your project’s documentation.

Python also has the built-in function help() that prints out the objects docstring to the console.

Example:

def say_hello(name):
 """A simple function that says hello"""
 print(f"Hello {name})

>>> help(say_hello)
Help on function say_hello in module __main__:

say_hello(name)
 A simple function that says hello

Docstring Types

Docstring conventions:

Are described within PEP 257
Purpose: provide your users with a brief overview of the object.
Should be kept concise enough to be easy to maintain but still be elaborate enough for new users to understand their purpose and how to use the documented object.

In all cases, the docstrings should use the triple-double quote (""") string format. This should be done whether the docstring is multi-lined or not.

At a bare minimum, a docstring should be a quick summary of whatever is it you’re describing and should be contained within a single line:

"""This is a quick summary line used as a description of the object."""

Multi-lined docstrings are used to further elaborate on the object beyond the summary. All multi-lined docstrings have the following parts:

A one-line summary line
A blank line proceeding the summary
Any further elaboration for the docstring
Another blank line

"""This is the summary line

This is the further elaboration of the docstring. Within this section,
you can elaborate further on details as appropriate for the situation.
Notice that the summary and the elaboration is separated by a blank new
line.
"""

# Notice the blank line above. Code should continue on this line.

All docstrings should have the same max character length as comments (72 characters).

Three major categories:

Class Docstrings: Class and class methods
Package and Module Docstrings: Package, modules, and functions
Script Docstrings: Script and functions

Class Docstrings

class SimpleClass:
 """Class docstrings go here."""

 def say_hello(self, name: str):
 """Class method docstrings go here."""

 print(f'Hello {name}')

Class docstrings should contain the following information:

A brief summary of its purpose and behavior
Any public methods, along with a brief description
Any class properties (attributes)
Anything related to the interface for subclassers, if the class is intended to be subclassed

The class constructor parameters should be documented within the __init__ class method docstring.

Individual methods should be documented using their individual docstrings. Class method docstrings should contain the following:

A brief description of what the method is and what it’s used for
Any arguments (both required and optional) that are passed including keyword arguments
Label any arguments that are considered optional or have a default value
Any side effects that occur when executing the method
Any exceptions that are raised
Any restrictions on when the method can be called

Example:

class Animal:
 """
 A class used to represent an Animal

 ...

 Attributes
 ----------
 says_str : str
 a formatted string to print out what the animal says
 name : str
 the name of the animal
 sound : str
 the sound that the animal makes
 num_legs : int
 the number of legs the animal has (default 4)

 Methods
 -------
 says(sound=None)
 Prints the animals name and what sound it makes
 """

 says_str = "A {name} says {sound}"

 def __init__(self, name, sound, num_legs=4):
 """
 Parameters
 ----------
 name : str
 The name of the animal
 sound : str
 The sound the animal makes
 num_legs : int, optional
 The number of legs the animal (default is 4)
 """

 self.name = name
 self.sound = sound
 self.num_legs = num_legs

 def says(self, sound=None):
 """Prints what the animals name is and what sound it makes.

 If the argument `sound` isn't passed in, the default Animal
 sound is used.

 Parameters
 ----------
 sound : str, optional
 The sound the animal makes (default is None)

 Raises
 ------
 NotImplementedError
 If no sound is set for the animal or passed in as a
 parameter.
 """

 if self.sound is None and sound is None:
 raise NotImplementedError("Silent Animals are not supported!")

 out_sound = self.sound if sound is None else sound
 print(self.says_str.format(name=self.name, sound=out_sound))

Package and Module Docstrings

Package Docstrings:

Should be placed at the top of the package’s __init__.py file
Should list the modules and sub-packages that are exported by the package

Module Docstrings:

Placed at the top of the file even before any imports
Should include:
- A brief description of the module and its purpose
- A list of any classes, exception, functions, and any other objects exported by the module
- Docstring for a module function should include the same items as a class method

Script Docstrings

Scripts: single file executables run from the console.

Docstrings for scripts:

Placed at the top of the file
should be documented well enough for users to be able to have a sufficient understanding of how to use the script
Should be usable for its “usage” message, when the user incorrectly passes in a parameter or uses the -h option

Any custom or third-party imports should be listed within the docstrings to allow users to know which packages may be required for running the script

Example:

"""Spreadsheet Column Printer

This script allows the user to print to the console all columns in the
spreadsheet. It is assumed that the first row of the spreadsheet is the
location of the columns.

This tool accepts comma separated value files (.csv) as well as excel
(.xls, .xlsx) files.

This script requires that `pandas` be installed within the Python
environment you are running this script in.

This file can also be imported as a module and contains the following
functions:

 * get_spreadsheet_cols - returns the column headers of the file
 * main - the main function of the script
"""

import argparse

import pandas as pd


def get_spreadsheet_cols(file_loc, print_cols=False):
 """Gets and prints the spreadsheet's header columns

 Parameters
 ----------
 file_loc : str
 The file location of the spreadsheet
 print_cols : bool, optional
 A flag used to print the columns to the console (default is
 False)

 Returns
 -------
 list
 a list of strings used that are the header columns
 """

 file_data = pd.read_excel(file_loc)
 col_headers = list(file_data.columns.values)

 if print_cols:
 print("\n".join(col_headers))

 return col_headers


def main():
 parser = argparse.ArgumentParser(description=__doc__)
 parser.add_argument(
 'input_file',
 type=str,
 help="The spreadsheet file to pring the columns of"
 )
 args = parser.parse_args()
 get_spreadsheet_cols(args.input_file, print_cols=True)


if __name__ == "__main__":
 main()

Docstring Formats

Some of the most common formats are the following:

Formatting Type	Description	Supported by Sphinx	Formal Specification
Google docstrings	Google’s recommended form of documentation	Yes	No
reStructured Text	Official Python documentation standard; Not beginner friendly but feature rich	Yes	Yes
NumPy/SciPy docstrings	NumPy’s combination of reStructured and Google Docstrings	Yes	Yes
Epytext	A Python adaptation of Epydoc; Great for Java developers	Not officially	Yes

The selection of the docstring format is up to you, but you should stick with the same format throughout your document/project. The following are examples of each type to give you an idea of how each documentation format looks.

pre-commit

Mon, 01 Nov 2021 00:00:00 +0000

TL;DR

Before committing any staged Python files, pre-commit automatically formats the code, validates compliance to PEP8, and performs different types of checking to keep the code and the project clean. This automatical process can greatly save our time on code formatting so that we can concentrate on code logic.

Basic pre-commit workflow (source: Automate Python workflow using pre-commits: black and flake8)

What is `pre-commit`?

pre-commit is a multi-language package manager for pre-commit hooks. You specify a list of hooks you want and pre-commit manages the installation and execution of any hook written in any language before every commit.

Quick start

Install pre-commit package manager
- pip
```
pip install pre-commit
```
- conda
```
conda install -c conda-forge pre-commit
```
Check if the installation is successful:
```
pre-commit --version
```
If successful, you can see the version information
(Optional) Add pre-commit to requirements.txt
Add a pre-commit configuration
1. Create a file named .pre-commit-config.yaml in the root of the project
2. Define hooks/plugins in .pre-commit-config.yaml (More see: Adding pre-commit plugins)
  
  You can generate a very basic configuration using pre-commit sample-config
Install the git hook scripts (prerequisite: git is already initialized)
```
pre-commit install
```
Now pre-commit will run automatically on every git commit (usually pre-commit will only run on the changed files during git hooks).
(Optional) Run pre-commit against all the files
```
pre-commit run --all-files
```

Adding pre-commit plugins

Once you have pre-commit installed, adding pre-commit hooks/plugins to your project is done with the .pre-commit-config.yaml configuration file, which describes what repositories and hooks are installed.

The top-level of .pre-commit-config.yaml is a map. Among them, the most important key is repos, which is a list of repository mappings. For other keys see: .pre-commit-config.yaml - top level.

`repos`

The repository mapping tells pre-commit where to get the code for the hook from.

`repo`	the repository url to `git clone` from
`rev`	the revision or tag to clone at. (new in 1.7.0: previously `sha`)
`hooks`	A list of hook mappings.

Example

repos:
-  repo: https://github.com/pre-commit/pre-commit-hooks
 rev: v1.2.3
 hooks:
 -  ...

`hooks`

The hook mapping configures which hook from the repository is used and allows for customization.

The necessary key is id, telling which hook from the repository to use. Other keys are optional.
All optional keys will receive their default from the repository’s configuration.

Example

repos:
-  repo: https://github.com/pre-commit/pre-commit-hooks
 rev: v1.2.3
 hooks:
 -  id: trailing-whitespace

Useful repos and hooks

We briefly introduce some important and useful hooks. For supported hooks, check the website of pre-commit.

`pre-commit-hooks`

Some out-of-the-box hooks for pre-commit.

Example

 - repo: https://github.com/pre-commit/pre-commit-hooks
 rev: v4.0.1
 hooks:
 - id: check-added-large-files # Prevent giant files from being committed.
 - id: check-ast # Simply check whether files parse as valid python.
 - id: check-byte-order-marker
 - id: check-case-conflict # Check for files with names that would conflict on a case-insensitive filesystem like MacOS HFS+ or Windows FAT
 - id: check-docstring-first # Checks for a common error of placing code before the docstring.
 - id: check-json # Attempts to load all json files to verify syntax.
 - id: check-yaml # Attempts to load all yaml files to verify syntax.
 - id: end-of-file-fixer # Makes sure files end in a newline and only a newline.
 - id: trailing-whitespace # Trims trailing whitespace.
 - id: mixed-line-ending # Replaces or checks mixed line ending.

black

The black code formatter in Python is an “uncompromising” tool that formats your code in the best way possible.

Example

 - repo: https://github.com/psf/black
 rev: 20.8b1
 hooks:
 - id: black
 args:
 - --line-length=119

isort

isort is a Python utility / library to sort imports alphabetically, and automatically separated into sections and by type.

To allow customizations to be integrated into any project quickly, isort supports various standard config formats. Check the documentation for all supported formats. I personally prefer setup.cfg.

When applying configurations, isort looks for the closest supported config file, in the order files are listed below. You can manually specify the settings file or path by setting --settings-path from the command-line. Otherwise, isort will traverse up to 25 parent directories until it finds a suitable config file.

For projects that officially use both isort and black, it is recommended to set the black profile in a config file.

Example: setup.cfg

[isort]
multi_line_output = 3
include_trailing_comma = True
force_grid_wrap = 0
use_parentheses = True
line_length = 88
profile = black

Sometimes the skip options do not work well, to skip some file for some reasons, check: Action Comments.

flake8

flake8 is a command-line utility for enforcing style consistency across Python projects. It is a popular lint wrapper for python. Under the hood, it runs three other tools and combines their results:

pep8 for checking style
pyflakes for checking syntax
mccabe for checking complexity

A good practice to customized flake8 checking is to define custom configurations in setup.cfg and specify its path with --args in .pre-commit-config.yaml:

setup.cfg

[flake8]
max-line-length = 119
max-complexity = 11
ignore = C901, W503, W504, E203, F401

[isort]
multi_line_output = 3
include_trailing_comma = True
force_grid_wrap = 0
use_parentheses = True
line_length = 88
profile = black

and in .pre-commit-config.yaml

 - repo: https://github.com/PyCQA/flake8
 rev: 4.0.1
 hooks:
 - id: flake8
 args:
 - --config=setup.cfg

GitHub Gist

My personal pre-commit config for python projects.

Reference

Documentation of pre-commit
Automate Python workflow using pre-commits: black and flake8: a simple tutorial on pre-commit
Running Python Linters with Pre-commit Hooks: Another tutorial on pre-commit
Python教程:如何建立完美自动化的Python-starter项目
Python Pre-Commit Hooks Setup in a single video!: Video tutorial
Some good examples of .pre-commit-config.yaml
- https://github.com/NCAS-CMS/cfunits/blob/master/.pre-commit-config.yaml
- https://github.com/open-mmlab/mmsegmentation/blob/master/.pre-commit-config.yaml: .pre-commit-config.yaml of mmsegmentation

STAR Method

Sun, 03 Apr 2022 00:00:00 +0000

A good way to provide more information about skills and qualification listed in the resume is to tell stories using the STAR method.

What is STAR?

Situation: What was the context of the story?
Task: What ws your role in the situation?
Assessment/Action: What did you do?
Results: What did your action lead to? What was the accomplishment?
- If possible, always try to include something quantifiable in your success statement

Example

STAR example

Situation: “as a lead project manager placed in the challenging project”
Task: “managed the overhaul of our product’s design and user experience”
Assessment/Action: “ensure the project met its deadlines and help eliminate process inefficiencies”
Results: “saved the company more than $15,000”

Common Phrases for Cover Letter

Sun, 03 Apr 2022 00:00:00 +0000

Introduction

At present, I am studying at…..
At the moment, I am working for…..
For the last 5 years, I have been working in the position of…..
My current job title is…

Reason For Writing

Explain why you are contacting the reader.

I am writing in response to an advertisement which was placed in…….
I am enquiring as to whether you currently have any positions in the area of……
I am writing to apply for the position of…

Education And Previous Experience

I have experience in…..and have worked at…….for the last…..years.
My education includes a degree from XY university.
I have been studying (subject) for 3 years.
I am a native English speaker and have ample knowledge of Spanish and Chinese.

What Makes You Ideal For This Position?

Convince the reader that you are the best option for this position.

I am a driven and ambitious person who is keen to learn new skills.
I believe I am the best choice for this position as I have a lot of experience in my previous role.
I feel that I am the most suitable candidate for this job because of my ambition and drive to make a change.
I am excited to have the opportunity to be able to work with a reputable company like yours.

Closing Statement

Thank you for taking the time to read through my application.
Please contact me at any time should you wish to arrange a meeting.
Please do not hesitate to contact me for any further information.
I appreciate your consideration for this application and look forward to hearing from you.

Additional Tipps

Comman phrases for writing a cover letter

Steps to write a cover letter

Reference

How To Write A Cover Letter: Useful Tips, Phrases and Examples

Best Practice

Wed, 11 May 2022 00:00:00 +0000

CI/CD

Wed, 11 May 2022 00:00:00 +0000

CI/CD (Source: Synopsys)

What is CI/CD?

A method to frequently deliver apps to customers by introducing automation into the stages of app development.
- CI = Continuous Integration
- CD = Continuous Delivery and Deployment
Introduces ongoing automation and continuous monitoring throughout the lifecycle of apps, from integration and testing phases to delivery and deployment.

Continuous Integration (CI)

An automation process for developers
- New code changes to an app are regularly built, tested, and merged to a shared repository.
This process is automated to ensure that teams can build, test, and package their applications in a reliable and repeatable way.
Helps streamline code changes, thereby increasing time for developers to make changes and contribute to improved software.
A solution to the problem of having too many branches of an app in development at once that might conflict with each other.

Cotinuous Delivery and/or Deployment (CD)

Continuous delivery
- The automated delivery of completed code to environments like testing and development.
  - I.e., a developer’s changes to an application are automatically bug tested and uploaded to a repository
- Provides an automated and consistent way for code to be delivered to these environments.
Continuous deployment
- Next step of continuous delivery
- Every change that passes the automated tests is automatically placed in production, resulting in many production deployments.
- Addresses the problem of overloading operations teams with manual processes that slow down app delivery

They are related concepts that sometimes get used interchangeably. Both are about automating further stages of the pipeline, but they’re sometimes used separately to illustrate just how much automation is happening.

Difference between CI and CD

CI is a set of practices performed as developers are writing code, and CD is a set of practices performed after the code is completed.

How CI/CD pipeline works?

The CI/CD pipeline works like an infinity loop:

CI/CD (Source: Synopsys)

Developers write the code
Build or compile the code
Test the code for bugs
Release the code if all tests are passed
Deploy the change in production
End users or customers operate the new change
Project owner or project manager monitors and gets feedback
Plan the next step based on the feedback
Back to step 1: Write code based on the plan

Why is CI/CD Important?

Allows organizations to ship software quickly and efficiently.
Facilitates an effective process for getting products to market faster than ever before, continuously delivering code into production, and ensuring an ongoing flow of new features and bug fixes via the most efficient delivery method.

Benefit of CI/CD

Automated testing enables continuous delivery, which ensures software quality and security and increases the profitability of code in production.
CI/CD pipelines enable a much shorter time to market for new product features, creating happier customers and lowering strain on development.
The great increase in overall speed of delivery enabled by CI/CD pipelines improves an organization’s competitive edge.
Automation frees team members to focus on what they do best, yielding the best end products.
Organizations with a successful CI/CD pipeline can attract great talent. By moving away from traditional waterfall methods, engineers and developers are no longer bogged down with repetitive activities that are often highly dependent on the completion of other tasks.

##Reference

What is CI/CD?
CICD
Video tutorials
- DevOps CI/CD Explained in 100 Seconds
- CI/CD Explained | How DevOps Use Pipelines for Automation

Best Practice | Haobin Tan

Best Practices

Beautiful Python Code with PEP 8

Naming Conventions

Naming styles

How to choose names

Code Layout

Blank lines

Maximum Line Length and Line Breaking

Indentation

Indentation Following Line Breaks

Where to Put the Closing Brace

Comments and Documentations

Whitespace in Expressions and Statements

Whitespace Around Binary Operators

Summary

Programming Recommendations

Don’t compare boolean values to True or False using the equivalence operator.

Use the fact that empty sequences are falsy in if statements.

Use is not rather than not ... is in if statements.

Don’t use if x: when you mean if x is not None:.

Use .startswith() and .endswith() instead of slicing.

Tips and Tricks to Help Ensure Your Code Follows PEP 8

Linters

Autoformatters

Documenting Python Code

Commenting vs. Documenting Code

Commenting Code

Purpose of Commenting Code

Rules of Commenting

Commenting Code via Type Hinting (Python 3.5+)

Documenting Code Base using Docstrings

Docstings Background

Docstring Types

Class Docstrings

Package and Module Docstrings

Script Docstrings

Docstring Formats

pre-commit

TL;DR

What is pre-commit?

Quick start

Adding pre-commit plugins

repos

hooks

Useful repos and hooks

pre-commit-hooks

black

isort

flake8

GitHub Gist

Reference

STAR Method

What is STAR?

Example

Common Phrases for Cover Letter

Introduction

Reason For Writing

Education And Previous Experience

What Makes You Ideal For This Position?

Closing Statement

Additional Tipps

Reference

Best Practice

CI/CD

What is CI/CD?

Continuous Integration (CI)

Cotinuous Delivery and/or Deployment (CD)

Difference between CI and CD

How CI/CD pipeline works?

Why is CI/CD Important?

Benefit of CI/CD

Don’t compare boolean values to `True` or `False` using the equivalence operator.

Use the fact that empty sequences are falsy in `if` statements.

Use `is not` rather than `not ... is` in `if` statements.

Don’t use `if x:` when you mean `if x is not None:`.

Use `.startswith()` and `.endswith()` instead of slicing.

What is `pre-commit`?

`repos`

`hooks`

`pre-commit-hooks`