Book Image

Clean Code in Python

By : Mariano Anaya

2 (1)

Book Image

Clean Code in Python

2 (1)

By: Mariano Anaya

Overview of this book

Python is currently used in many different areas such as software construction, systems administration, and data processing. In all of these areas, experienced professionals can find examples of inefficiency, problems, and other perils, as a result of bad code. After reading this book, readers will understand these problems, and more importantly, how to correct them. The book begins by describing the basic elements of writing clean code and how it plays an important role in Python programming. You will learn about writing efficient and readable code using the Python standard library and best practices for software design. You will learn to implement the SOLID principles in Python and use decorators to improve your code. The book delves more deeply into object oriented programming in Python and shows you how to use objects with descriptors and generators. It will also show you the design principles of software testing and how to resolve software problems by implementing design patterns in your code. In the final chapter we break down a monolithic application to a microservice one, starting from the code as the basis for a solid platform. By the end of the book, you will be proficient in applying industry approved coding practices to design clean, sustainable and readable Python code.

Preface

Who this book is for

What this book covers

To get the most out of this book

Free Chapter

Introduction, Code Formatting, and Tools

Introduction, Code Formatting, and Tools

The meaning of clean code

The importance of having clean code

Docstrings and annotations

Pythonic Code

Indexes and slices

Context managers

Properties, attributes, and different types of methods for objects

Iterable objects

Container objects

Dynamic attributes for objects

Callable objects

Summary of magic methods

Caveats in Python

General Traits of Good Code

General Traits of Good Code

Design by contract

Defensive programming

Separation of concerns

Acronyms to live by

Composition and inheritance

Arguments in functions and methods

Final remarks on good practices for software design

The SOLID Principles

The SOLID Principles

Single responsibility principle

The open/closed principle

Liskov's substitution principle

Interface segregation

Dependency inversion

Using Decorators to Improve Our Code

Using Decorators to Improve Our Code

What are decorators in Python?

Effective decorators – avoiding common mistakes

The DRY principle with decorators

Decorators and separation of concerns

Analyzing good decorators

Getting More Out of Our Objects with Descriptors

Getting More Out of Our Objects with Descriptors

A first look at descriptors

Types of descriptors

Descriptors in action

Analysis of descriptors

Using Generators

Using Generators

Technical requirements

Creating generators

Iterating idiomatically

Asynchronous programming

Unit Testing and Refactoring

Unit Testing and Refactoring

Design principles and unit testing

Frameworks and tools for testing

More about unit testing

A brief introduction to test-driven development

Common Design Patterns

Common Design Patterns

Considerations for design patterns in Python

Design patterns in action

The null object pattern

Final thoughts about design patterns

Clean Architecture

Clean Architecture

From clean code to clean architecture

Software components

Summing it all up

Other Books You May Enjoy

Other Books You May Enjoy

Leave a review - let other readers know what you think

Customer Reviews

2 (1)

5 star

0

4 star

0

3 star

0

2 star

100%

1 star

0

Dependency inversion

This is a really powerful idea that will come up again later when we explore some design patterns in Chapter 9, Common Design Patterns, and Chapter 10, Clean Architecture.

The dependency inversion principle (DIP) proposes an interesting design principle by which we protect our code by making it independent of things that are fragile, volatile, or out of our control. The idea of inverting dependencies is that our code should not adapt to details or concrete implementations, but rather the other way around: we want to force whatever implementation or detail to adapt to our code via a sort of API.

Abstractions have to be organized in such a way that they do not depend on details, but rather the other way around—the details (concrete implementations) should depend on abstractions.

Imagine that two objects in our design need to collaborate, A and B. A works...