code review, style guides and tools for pythin

CODE REVIEW FOR PYTHON AND TOOLS @MEHDI_HADJI

CODE REVIEWS CAN BE FRUSTRATING @ABOULLAITE DID YOU SAID CODE REVIEW ?

CODE REVIEW FRUSTRATIONS > Adds time demand > Adds process > Adds more tensions > “smart” devs think they don’t need it

CODE REVIEW BENEFITS > Identify: ● Design flaws ● bugs > Case Studies on Review *: And can be remedied before the code is complete ! productivity by 15% bug rate by 80% * https://blog.codinghorror.com/code-reviews-just-do-it/

CODE REVIEW BENEFITS > find bugs > share ownership > share knowledge > reduce “lottery Factor”

CONSISTENT CODE > Your code isn’t yours, it belongs to your company > Code should fit your company’s expectations and style (not your own)

CODE REVIEWS NEED TO BE UNIVERSAL & FOLLOW GUIDELINES > Doesn’t matter how senior / junior you are > Only senior devs reviewing == bottleneck* *occurs when workloads arrive too quickly for the production process to handle. https://www.investopedia.com/terms/b/bottleneck.asp

STYLE GUIDE > Distinguishes personal taste from opinion > Should be agreed upon beforehand > Keep calm and follow PEP 8

FIRSTLY, WHAT IS PEP? > Stands for Python Enhancement Proposal. > Is a design document providing information to the Python community, or describing a new feature for Python or its processes or environment. > Each bear a number. > Some are accepted, others postponed, but all are open to debate.

PEP 8 ? > aims to define a common style guide for Python code : ● Code layout ● Docstring ● Imports ● Whitespaces ● Naming convention ● ...

PEP 8 > CODE LAYOUT > A line must contain 79 characters maximum. > Indentation must be 4 spaces. > Add two empty lines between two high level elements, classes for example, for ergonomic reasons. > Separate each function with an empty line.

PEP 8 > IMPORTS > They precede the Docstrings. > One line per library. > The import must follow the following order: ● Standard libraries ● third-party libraries ● local imports.

PEP 8 > DOCSTRING > Is a set of words that documents a piece of code. > Each part of the code should contain a Docstring: ● all public modules ● all functions ● all the classes and all the methods of these classes

PEP 8 > WHITESPACE IN INSTRUCTIONS > Follows the Anglo-Saxon syntax > No space before : but one after; > Operators: a space before and an after: # Beautiful: {"eggs": 2} # Uggly: {"eggs" : 2} {"eggs" :2} # Beautiful: i = i + 1

PEP 8 > WHITESPACE IN INSTRUCTIONS > Parameter of a function: No spaces before and after an = sign when you assign a value. Example: > Immediately inside parentheses, brackets or braces: # Beautiful: def elephant(trunk=True, legs=4) # Beautiful: spam(ham[1], {eggs: 2}) # Uggly: spam( ham[ 1 ], { eggs: 2 } )

PEP 8 > NAMING CONVENTION Modules: short name, all lowercase, underscore if necessary: packages: short name, all lowercase, underscores strongly not recommended: classes: capital letter at the beginning of the word: exceptions: similar to classes but with an Error at the end: my_module package MyLovelyClass MyLovelyError * A package is a collection of Python modules: while a module is a single Python file

PEP 8 > NAMING CONVENTION > functions: lowercase and underscore: > methods: lowercase, underscore and self as the first parameter: > variables: identical to functions. > constants: all in capital letters with underscores if necessary: > private: preceded by two underscores: > protected: preceded by a dash: my_function() my_method(self) I_WILL_NEVER_CHANGE __i_am_private _i_am_protected

ZEN OF PYTHON > You can think of them as guides of conduct that help you write better code and understand the mindset of language *Zen : religion or philosophy.

Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those! ZEN OF PYTHON

ZEN OF PYTHON > Beautiful is better than ugly:

ZEN OF PYTHON > Explicit is better than implicit:

TOOLS > Formatters > Code analysis > Pre commit

FORMATTERS -autopep8 -black -yapf

DEMO - autopep8 / black autopep8 black

CODE ANALYSIS -Pylint > Is a Python static code analysis tool which analyzes the code according to PEP 8 standards > looks for programming errors, helps enforcing a coding standard, sniffs for code smells and offers simple refactoring suggestions.

Pre commit -flake8 > is a command-line utility for enforcing style consistency with respect to PEP 8 >it will also run third-party extensions if they are found and installed.

CONSISTENT CODE IS EASIER TO MAINTAIN BY A TEAM

CODE REVIEW IS DONE BY YOUR PEERS

TO KEEP IN MIND > Universal code review. > Performed by Peers. > Style guides & formatters for consistency. > No blame culture.

code review, style guides and tools for pythin

More Related Content

Similar to code review, style guides and tools for pythin

Recently uploaded

code review, style guides and tools for pythin