Skip to main content

Command Palette

Search for a command to run...

Art of Writing Code in Python! : a Cheat Sheet.

Updated
4 min read
Art of Writing Code in Python! : a Cheat Sheet.
J
Passionate and results-driven Senior Software Engineer with over 7 years of experience building scalable backend systems, designing cloud-native architectures, and automating deployments. Specialized in Python, AWS cloud services, k8s, Docker, Golang, GitHub Actions with a strong focus on performance, security, and reliability.

We know that Python is easy to learn, write and read. in fact, that’s why it makes itself different from other languages. People get confused with the weird syntax of other languages, even programmer but not in the case of Python. The reason why most people prefer Python because of its simplicity not because of its performance hehe! and we should keep simple as it is. remember the KISS principle?

Why python is best because it readability!

As a developer, we often do changes when writing code but if you haven’t written a good one! then probably you get stuck while changing code. in fact, even you visit it after some days and then you could not read because you did not write efficiently or maybe your colleagues have to work on your code then what do think? How are they gonna it?

Any fool can write code that computers can understand, but good programmers write code that humans can understand!

Every developer complains about the change request, but you write human-readable code not computer-readable than the developer won’t! Code that hard to read causes many issues like hard refracting code, hard to debug also and time-consuming. as a developer, we read code 10x than we write a code!

Don’t be selfish, be a good team-member and try to be writer and not just coder!

So here some tips for the formatting, documentations(comments), naming conventions!

Line length

Here is one thumb rule if you are reaching 79* characters per line, then probably you are doing some wrong.

# good bad dict

context={"first_name": user.first_name.capitalize(),"company": g.user.get_company_name,"last_name": g.user.last_name.capitalize(),"username": user.username,"password": password}
# difficult to debug and difficult to find a bug

# good dict
context = {
    "first_name": user.first_name.capitalize(),
    "company": g.user.get_company_name,
    "last_name": g.user.last_name.capitalize(),
    "username": user.username,
    #     "email": user.email,
    "password": password,
}


""" best thing about this, you can comment code easily! same goes 
with tuple and list"""

""" code that runs without compiling because you would have a clear picture
 in front of you what you have written that will save your time and energy."""
#bad 
def create_from_partner_onboarding( created_by, pipeline_id, pipeline_type, doc_id, doc_name, count=1):
    pass

def create_from_partner_onboarding(
    created_by, pipeline_id, pipeline_type, doc_id, doc_name, count=1
):
    """
        good one
    """
    pass
#good one
def create_from_partner_onboarding(


    created_by=1,
    pipeline_id=2,
    pipeline_type,
    doc_id,
    doc_name,
    count=1

):
  pass
# or you can create dict and access the values 
# bad import 
from sqlalchemy import Boolean, Column, create_engine, DateTime, ForeignKey, Integer, MetaData, String, Table, Text

# good import 
from sqlalchemy import (
    Boolean,
    Column,
    create_engine,
    DateTime,
    ForeignKey,
    Integer,
    MetaData,
    String,
    Table,
    Text,
)
# black standards

Naming Conversation [FROM PEP8 DOCS]

Use the function naming rules: lowercase with words separated by underscores as necessary to improve readability.



def names():
    pass


def hello_world():
    pass


def hey_hello_world():
    pass


class Circle:
    pass


class UserView:
    pass


class OnboardingJourney:
    def _get_steps():
        pass

Use one leading underscore only for non-public methods and instance variables.

Class names should normally use the CapWords convention.

Variable names follow the same convention as function names.

Constants are usually defined on a module level and written in all capital letters with underscores separating words.

Documentations(docstrings)

Write docstrings for all public modules, functions, classes, and methods. Docstrings are not necessary for non-public methods, but you should have a comment that describes what the method does. This comment should appear after the def line. These docstring will be accessible through __doc__ and python’s built-in function help()

Rules of Thumb👍

  1. Often Look back at the code!

  2. Use IDE auto formatter and after using check it what changes IDE has made and think about why. here why is important!

  3. Explore different type of auto formatter in IDE, find out which one suits you and your project! in python there is PEP8, Black, yapf

  4. Pair programming or share thoughts with your colleague

  5. Spare your team player!😉

  6. Read this poem and understand deep meaning behind it [there is magic in poem word!]

  7. Get Your Hands Dirty!

  8. Instead of using print use logger that way will both requirements will be satisfied.

Conclusion, Reference and Goodbye!

My conclusion is simple, these three things, formatting, documenting (comments), naming conventions is so basic yet so essential.

There are tones of it, i brought some of it. Want to learn about PEP8 standards then follows Reference link in response(comment) box.

Share on twitter if you have liked❤️

If you have enjoyed this article, then hit the claps👏…!

Catch you later, keep coding and have fun ❤
Jamil.