Skip to content
This repository has been archived by the owner on Sep 26, 2023. It is now read-only.
/ pysanity Public archive

Opinionated coding guidelines and best practices in Python

License

Notifications You must be signed in to change notification settings

rednafi/pysanity

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation


````¯¯¯¯\____philosophy____/¯¯¯¯````

__Practicality Beats Purity__ ___Automation Brings Salvation___ ____Abstraction is Chaos, Concealed by Confusion____

 

 

What is this?

This is an ever evolving, battle tested and marginally opinionated python coding guideline that is currently being enforced at my company ShopUp. Primarily, it is an attempt to document some of the implicit lessons and good practices that we have picked up while writing, maintaining and documenting python code in production. You may not agree with all the conventions mentioned here but other than the style guide where everyone has different ideas about how code should be formatted, the conventions mentioned here are almost universally accepted as good practices by the python community. The aim is not to have a strict guideline that is imposed upon every codebase, rather it exists to provide a baseline and reduce unnecessary cognitive overload that arises from disagreements during internal code reviews. The guideline is divided into three major segments.

Styling Guideline: A mashup of simplified pep8, pep257 and a few tools for styling automation

Coding Guideline: Conventions, best practices and design patterns

Documentation Guideline: An attempt to streamline API documentation

 

Read the guideline here.

 

Contribution Instructions

Fork the repo
Go to docs/README.md
Make your edit, push to a new branch & send a pull request

About

Opinionated coding guidelines and best practices in Python

Topics

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published