Pythonic কোড — PEP 8, idiom আর ruff

১ · কোড পড়া হয় বেশি, লেখা হয় কম — “Pythonic” মানে কী

রাজশাহীর একটি কোচিং সেন্টারের ফলাফল তৈরির স্ক্রিপ্ট লিখেছিলেন তানভীর, দুই বছর আগে। স্ক্রিপ্টটি ঠিকঠাক চলে। এখন তানভীর চাকরি নিয়ে ঢাকায়, আর স্ক্রিপ্টে একটি নতুন নিয়ম যোগ করার দায়িত্ব পেয়েছেন নুসরাত। তিনি ফাইল খুলে দেখলেন: ভ্যারিয়েবলের নাম a, tmp2, lst; একটি ফাংশন দুশো লাইনের; পাঁচ স্তর গভীর if; কোথাও কোথাও 40 আর 33 সংখ্যা, কোনো ব্যাখ্যা ছাড়া। একটি লাইন বদলাতে নুসরাতের লাগল দুই দিন — এক দিন শুধু বুঝতেই।

স্ক্রিপ্টটি “ভুল” ছিল না। কম্পিউটার ঠিকই বুঝেছিল। সমস্যা ছিল মানুষের বোঝায়। এখানেই এই পর্বের মূল কথা: কোড একবার লেখা হয়, কিন্তু পড়া হয় বহুবার — বাগ খুঁজতে, নতুন ফিচার যোগ করতে, review করতে, শিখতে। PEP 8-এর শুরুর দিকেই লেখা আছে Guido van Rossum-এর এই উপলব্ধি: কোড যতবার লেখা হয়, তার চেয়ে অনেক বেশিবার পড়া হয়। তাই লেখার সময় দুই মিনিট বেশি খরচ করে যদি পড়ার সময় দুই ঘণ্টা বাঁচে, সেটাই লাভ।

এই প্রচলিত ধাঁচের নাম idiom — ভাষার এমন প্রকাশভঙ্গি, যা ওই ভাষার লোকেরা স্বাভাবিকভাবে ব্যবহার করেন। বাংলায় “মাথা খাওয়া” বললে সবাই বোঝেন, যদিও শব্দ ধরে অনুবাদ করলে অর্থহীন। আর যে কোড Python-এর idiom ব্যবহার করে লেখা, তাকে বলে Pythonic. উল্টোটা হলো অন্য ভাষার অভ্যাস Python-এ টেনে আনা: C-এর মতো সূচক ধরে লুপ, Java-র মতো প্রতিটি attribute-এর getter. এগুলো চলে, কিন্তু Python প্রোগ্রামারের চোখে “বিদেশি উচ্চারণ”-এর মতো লাগে — বুঝতে একটু বেশি চেষ্টা লাগে, আর ভুল লুকানোর জায়গা বাড়ে।

Zen of Python — পাঁচটি নীতি, কোডে

Python-এর দর্শন সবচেয়ে সংক্ষেপে লেখা আছে Zen of Python-এ — Tim Peters-এর লেখা ১৯টি ছোট বাক্য, পরে PEP 20 হিসেবে সংরক্ষিত। মজার ব্যাপার, এটি Python-এর ভেতরেই লুকানো: import this লিখলেই ছাপা হয়। নিচের প্রোগ্রামটি পুরো Zen পড়ে, তার থেকে পাঁচটি নীতি বেছে দেখায় — আর প্রোগ্রামটি নিজেও Pythonic ধাঁচে লেখা:

import contextlib
import io

buffer = io.StringIO()
with contextlib.redirect_stdout(buffer):
    import this  # noqa: F401 — import করলেই পুরো Zen ছাপা হয়, এখানে ধরে রাখছি

lines = buffer.getvalue().splitlines()
aphorisms = lines[2:]  # প্রথম লাইন শিরোনাম, দ্বিতীয়টি ফাঁকা
print(lines[0], f"— মোট {len(aphorisms)}টি নীতি")
for number in (1, 3, 7, 13, 17):
    print(f"{number:>2}. {aphorisms[number - 1]}")

এই পাঁচটি নীতি কোডে কেমন দেখায়:

• Beautiful is better than ugly: total=price*qty+vat নয়, total = price * qty + vat — একই কাজ, চোখের আরাম আলাদা।
• Simple is better than complex: নিজে dict-এ গণনা না করে collections.Counter(words); নিজের sort না লিখে sorted().
• Readability counts: d নয়, days_since_payment. নাম লম্বা হলেও পাঠক থামেন না।
• There should be one obvious way to do it: list-এর প্রতিটি উপাদানে সূচকসহ লুপ? enumerate. দুটি list পাশাপাশি? zip. প্রচলিত একটি পথ থাকলে সবাই সেটি চেনে।
• If the implementation is hard to explain, it's a bad idea: কোড রিভিউতে যদি এক লাইন বোঝাতে পাঁচ মিনিট লাগে, লাইনটি নতুন করে লিখুন।

২ · PEP 8-এর মূল কথা — নাম, লাইন আর ফাঁকা জায়গা

PEP 8 হলো Python কোডের অফিসিয়াল style guide — ২০০১ সালে লেখা, এখনো হালনাগাদ হয়। এটি আইন নয়; Python interpreter PEP 8 না মানলেও কোড চালায়। কিন্তু প্রায় সব Python লাইব্রেরি, কোম্পানি আর open-source প্রকল্প এটিকে ভিত্তি ধরে। তাই PEP 8 জানা মানে Python জগতের “প্রমিত বানান” জানা। পুরোটা মুখস্থের দরকার নেই — টুল বেশিরভাগ মনে রাখে (অংশ ৭)। তবে মূল কথাগুলো জানা চাই, কারণ টুল কী বলছে আর কেন, সেটা বুঝতে হবে।

নামের নিয়ম — নাম দেখেই জাত চেনা

নামের ধাঁচ শুধু সৌন্দর্য নয় — এটি তথ্য বহন করে। Student(...) দেখলেই বোঝেন একটি class থেকে object বানানো হচ্ছে; student(...) হলে এটি একটি ফাংশন। PASS_MARK দেখলে বোঝেন এটি বদলানোর জিনিস নয়। আর _parse_row বলে দেয়: “এটি module-এর বাইরের কারও জন্য নয়, যেকোনো সময় বদলাতে পারে।”

লাইনের দৈর্ঘ্য — ৭৯, ৮৮ না ৯৯?

PEP 8 বলে: কোডের লাইন সর্বোচ্চ ৭৯ অক্ষর, আর docstring ও comment ৭২ অক্ষর। কারণগুলো বাস্তব — পাশাপাশি দুটি ফাইল খোলা, diff দেখার টুল, ছোট ল্যাপটপ বা মোবাইলে review. তবে PEP 8 নিজেই ছাড় দেয়: দল একমত হলে কোডের সীমা ৯৯ পর্যন্ত বাড়ানো যায়। আর black (অংশ ৭) ঠিক করেছে ৮৮ — তাদের যুক্তি, ৮০-র চেয়ে একটু বেশি জায়গায় অনেক অপ্রয়োজনীয় লাইন-ভাঙা কমে, অথচ ১০০-র মতো লম্বাও হয় না। আজ অনেক প্রকল্প ৮৮ ব্যবহার করে। কোনটি “ঠিক”, তা নিয়ে তর্কের চেয়ে জরুরি হলো: প্রকল্পে একটি সংখ্যা ঠিক করে টুলে লিখে দিন, তারপর আর ভাববেন না।

লম্বা লাইন ভাঙার Pythonic উপায় হলো বন্ধনী — (), [], {}-এর ভেতরে Python নিজেই লাইন জোড়া ধরে নেয়। পুরোনো ধাঁচের \ দিয়ে লাইন ভাঙা এড়িয়ে চলুন; তার পরে ভুল করে একটি space থাকলেই SyntaxError.

# এড়িয়ে চলুন
total = first_term_marks + second_term_marks + \
    practical_marks + attendance_bonus

# Pythonic — বন্ধনীর ভেতরে, অপারেটর লাইনের শুরুতে
total = (
    first_term_marks
    + second_term_marks
    + practical_marks
    + attendance_bonus
)

ফাঁকা জায়গা আর ফাঁকা লাইন

• অপারেটরের দুই পাশে একটি space: x = a + b, if count >= 3:. তবে keyword argument বা default-এ =-এর পাশে space নয়: print(msg, end=""), def greet(name="অতিথি"): — কিন্তু type hint থাকলে আবার space: def greet(name: str = "অতিথি"):.
• কমার পরে space, বন্ধনীর ভেতরে নয়: f(a, b), [1, 2, 3] — f( a,b ) নয়।
• Indentation চার space, tab নয় (পর্ব ০৪)।
• ফাঁকা লাইন: top-level ফাংশন আর class-এর আগে-পরে দুটি; class-এর ভেতরে method-এর মাঝে একটি; ফাংশনের ভেতরে যুক্তির “অনুচ্ছেদ” আলাদা করতে মাঝেমধ্যে একটি।

“A Foolish Consistency…” — কখন নিয়ম ভাঙবেন

PEP 8-এর একটি অংশের শিরোনাম মার্কিন লেখক Ralph Waldo Emerson-এর বিখ্যাত বাক্য থেকে নেওয়া: A Foolish Consistency is the Hobgoblin of Little Minds — নির্বোধ ধারাবাহিকতা ছোট মনের ভূত। এর বক্তব্য: style guide-এর উদ্দেশ্য পাঠযোগ্যতা; যেখানে নিয়ম মানলে কোড কম পাঠযোগ্য হয়, সেখানে নিয়ম ভাঙুন। PEP 8 কয়েকটি বৈধ কারণ বলে: নিয়ম মানলে পড়া কঠিন হয়; আশেপাশের পুরোনো কোড অন্য ধাঁচে লেখা আর সেখানে মিল রাখা জরুরি; কোডটি নিয়মের আগের; বা পুরোনো Python version-এর সাথে মিল রাখতে হয়। মনে রাখার সূত্র: একটি প্রকল্পের ভেতরে ধারাবাহিকতা PEP 8-এর চেয়েও জরুরি, আর একটি ফাংশনের ভেতরে ধারাবাহিকতা সবচেয়ে জরুরি.

উদাহরণ: গণিতের সূত্র কোডে লিখছেন — y = a*x**2 + b*x + c. এখানে গুণের পাশে space না দিয়ে যোগের পাশে দেওয়া আসলে অগ্রাধিকার চোখে দেখায়; PEP 8 নিজেই এমন উদাহরণ দেয়। বা একটি লাইব্রেরি camelCase ব্যবহার করে (যেমন পুরোনো unittest-এর setUp) — তার subclass-এ আপনিও সেই নাম রাখবেন, PEP 8 না মেনে।

৩ · import সাজানো — তিন দল, একটি ক্রম

একটি ফাইলের শুরুর import-গুলো তার “উপকরণের তালিকা” — কী কী লাগছে, কোথা থেকে আসছে। এলোমেলো তালিকা পড়ে বোঝা কঠিন: কোনটি Python-এর সাথেই আসে, কোনটি pip দিয়ে বসাতে হবে, কোনটি আমাদেরই প্রকল্পের? PEP 8-এর নিয়ম: প্রতিটি import আলাদা লাইনে, ফাইলের একদম শুরুতে (module docstring আর comment-এর পরে), আর তিনটি দলে — মাঝে একটি করে ফাঁকা লাইন। ধাপে ধাপে দেখুন:

from shop.models import Product
import requests
import os, sys
from pathlib import Path
import pandas as pd
from .utils import money
import json
from collections import defaultdict
from math import *

import json
import os
import sys
from collections import defaultdict
from pathlib import Path
# ... বাকিগুলো এখনো সাজানো হয়নি

import json
import os
import sys
from collections import defaultdict
from pathlib import Path

import pandas as pd
import requests

import json ... from pathlib import Path

import pandas as pd
import requests

from shop.models import Product
from shop.utils import money

import json
import os
import sys
from collections import defaultdict
from pathlib import Path

import pandas as pd
import requests

from shop.models import Product
from shop.utils import money

৪ · আগে-পরে: প্রতিদিনের Python idiom

এই কোর্সের আগের পর্বগুলোতে প্রতিটি idiom আলাদা আলাদা শিখেছেন। এখানে সেগুলো একসাথে, আগে-পরে জোড়ায় — যাতে অন্যের কোড (বা AI-এর কোড) পড়ার সময় “আগে”-র ধাঁচ দেখলেই চিনতে পারেন। প্রতিটি “আগে” কোড ঠিকঠাক চলে; সমস্যা পাঠযোগ্যতা আর লুকানো ভুলের ঝুঁকি। বিষয় অনুযায়ী ট্যাব বেছে নিন:

# আগে                                   # পরে
if len(items) > 0:                      if items:
if done == True:                        if done:
if result == None:                      if result is None:
if city == "ঢাকা" or city == "চট্টগ্রাম":  if city in {"ঢাকা", "চট্টগ্রাম"}:
if mark >= 40 and mark <= 100:          if 40 <= mark <= 100:
found = False                           found = any(m < 33 for m in marks)
for m in marks:
    if m < 33:
        found = True

# আগে
for i in range(len(names)):
    print(i + 1, names[i])
for i in range(len(names)):
    print(names[i], marks[i])
squares = []
for n in nums:
    if n % 2 == 0:
        squares.append(n * n)

# পরে
for roll, name in enumerate(names, start=1):
    print(roll, name)
for name, mark in zip(names, marks, strict=True):
    print(name, mark)
squares = [n * n for n in nums if n % 2 == 0]

# আগে                                  # পরে
temp = a; a = b; b = temp              a, b = b, a
first = row[0]; rest = row[1:]         first, *rest = row
if key in stock:                       qty = stock.get(key, 0)
    qty = stock[key]
else:
    qty = 0
if area not in groups:                 groups = defaultdict(list)
    groups[area] = []                  groups[area].append(shop)
groups[area].append(shop)
msg = "নাম: " + name + ", বয়স: " + str(age)   msg = f"নাম: {name}, বয়স: {age}"
# নিজে লেখা bubble sort (১২ লাইন)       ranked = sorted(students, key=lambda s: s.gpa)

# আগে
f = open("marks.csv", encoding="utf-8")
data = f.read()
f.close()                       # মাঝে error হলে বন্ধই হয় না
if os.path.exists(path) and os.path.isfile(path):
    size = os.path.getsize(os.path.join(folder, "a.txt"))

# পরে
with open("marks.csv", encoding="utf-8") as f:
    data = f.read()             # যা-ই ঘটুক, ফাইল বন্ধ হবে
try:
    size = (folder / "a.txt").stat().st_size
except FileNotFoundError:
    size = 0

# আগে — mutable default আর গভীর nesting
def add_item(item, cart=[]):
    cart.append(item)
    return cart

def discount(order):
    if order.paid:
        if order.total > 1000:
            if not order.used_coupon:
                return order.total * 0.1
    return 0

# পরে
def add_item(item, cart=None):
    cart = [] if cart is None else cart
    cart.append(item)
    return cart

def discount(order):
    if not order.paid or order.used_coupon:
        return 0
    if order.total <= 1000:
        return 0
    return order.total * 0.1

৫ · একটি ফাংশন, পাঁচটি idiom — ধাপে ধাপে refactor

পর্ব ২১-এর মাঝপথের প্রজেক্টের মতো একটি ফলাফল-স্ক্রিপ্টের কথা ভাবুন। কেউ একজন — হয়তো C থেকে আসা, হয়তো তাড়াহুড়োয় — একটি ফাংশন লিখেছেন: শিক্ষার্থীদের নাম আর নম্বরের দুটি list নেয়, আর যাঁদের নম্বর ৪০ থেকে ১০০-র মধ্যে, তাঁদের "নাম: নম্বর" লেখার list ফেরত দেয়। ফাংশনটি ১৫ লাইনের, আর ঠিকঠাক চলে।

এখন একে Pythonic বানাব। নিয়ম একটাই: প্রতিটি ধাপে একটিমাত্র বদল, আর প্রতিটি ধাপের পরে আচরণ হুবহু একই. একেই বলে refactoring — বাইরের আচরণ না বদলে ভেতরের গঠন উন্নত করা। একসাথে সব বদলালে কোথাও ভুল ঢুকলে খুঁজে পাওয়া কঠিন; এক ধাপে এক বদল হলে প্রতিটি ধাপ যাচাই করা সহজ।

def GetPassedList(names, marks):
    result = []
    # মুছে গেল: i = 0 / while i < len(names): / name = names[i]
    #           mark = marks[i] / i = i + 1
    for name, mark in zip(names, marks, strict=True):
        if mark >= 40:
            if mark <= 100:
                line = name + ": " + str(mark)
                result.append(line)
    if len(result) == 0:
        return []
    else:
        return result

def GetPassedList(names, marks):
    result = []
    for name, mark in zip(names, marks, strict=True):
        if 40 <= mark <= 100:
            line = name + ": " + str(mark)
            result.append(line)
    if len(result) == 0:
        return []
    else:
        return result

def GetPassedList(names, marks):
    result = []
    for name, mark in zip(names, marks, strict=True):
        if 40 <= mark <= 100:
            result.append(f"{name}: {mark}")
    if len(result) == 0:
        return []
    else:
        return result

def GetPassedList(names, marks):
    result = []
    for name, mark in zip(names, marks, strict=True):
        if 40 <= mark <= 100:
            result.append(f"{name}: {mark}")
    return result
    # খালি হলে result নিজেই [] — আলাদা শাখার দরকার ছিল না

PASS_MARK, MAX_MARK = 40, 100


def passed_students(names, marks):
    """পাসের সীমার ভেতরের শিক্ষার্থীদের 'নাম: নম্বর' list."""
    return [
        f"{name}: {mark}"
        for name, mark in zip(names, marks, strict=True)
        if PASS_MARK <= mark <= MAX_MARK
    ]

দাবি করা সহজ যে “আচরণ একই আছে”; প্রমাণ করুন। নিচের প্রোগ্রামে আগের আর পরের দুটি ফাংশনই আছে, একই ডেটায় চালিয়ে ফল মেলানো হয়েছে:

def GetPassedList(names, marks):
    result = []
    i = 0
    while i < len(names):
        name = names[i]
        mark = marks[i]
        if mark >= 40:
            if mark <= 100:
                line = name + ": " + str(mark)
                result.append(line)
        i = i + 1
    if len(result) == 0:
        return []
    else:
        return result


PASS_MARK, MAX_MARK = 40, 100


def passed_students(names, marks):
    """পাসের সীমার ভেতরের শিক্ষার্থীদের 'নাম: নম্বর' list."""
    return [
        f"{name}: {mark}"
        for name, mark in zip(names, marks, strict=True)
        if PASS_MARK <= mark <= MAX_MARK
    ]


names, marks = ["Rafi", "Mitu", "Sabbir", "Nadia"], [72, 35, 104, 40]
print(passed_students(names, marks))
print(GetPassedList([], []), passed_students([], []))
print("একই ফল?", GetPassedList(names, marks) == passed_students(names, marks))

চালাক বনাম স্পষ্ট — একটি এক-লাইনারের গল্প

উল্টো দিকের ভুলও আছে: “ছোট মানেই Pythonic” ভেবে সব এক লাইনে লেখা। একটি দোকানের পণ্য-বিবরণের লেখা থেকে সবচেয়ে বেশি আসা তিনটি শব্দ বের করার এই এক-লাইনারটি দেখুন — বুদ্ধিদীপ্ত, কিন্তু পড়তে গেলে থামতে হয়:

top = sorted({w: text.split().count(w) for w in set(text.split())}
             .items(), key=lambda p: -p[1])[:3]

top = sorted({w: text.split().count(w) for w in set(text.split())}
             .items(), key=lambda p: -p[1])[:3]
# ① set(...) — অনন্য শব্দ   ② প্রতিটির জন্য আবার split + count
# ③ dict → items → উল্টো ক্রমে sort   ④ প্রথম তিনটি

# n শব্দ, k অনন্য শব্দ
for w in set(words):        # k বার
    words.count(w)          # প্রতিবার পুরো n শব্দ গোনা
# মোট প্রায় k × n — দশ হাজার শব্দে কোটির ঘরে

from collections import Counter

words = text.split()
top = Counter(words).most_common(3)

# চালাক রূপ: set-এর ক্রম নিশ্চিত নয় → সমান হলে ফল
#            একেক রান-এ একেক রকম হতে পারে
# Counter.most_common: সমান হলে প্রথম দেখার ক্রমে —
#            একই ইনপুটে সবসময় একই ফল

৬ · নাম, docstring, comment আর type hint

ভালো নাম — অর্ধেক documentation

“প্রোগ্রামিংয়ের সবচেয়ে কঠিন দুটি কাজের একটি হলো নাম দেওয়া” — এই রসিকতা প্রোগ্রামারদের মধ্যে বহুদিনের। কয়েকটি সহজ নিয়ম অনেকটা পথ এগিয়ে দেয়:

• ফাংশন = ক্রিয়া, ডেটা = বিশেষ্য: calculate_vat(), send_reminder(), load_students(); ডেটা students, vat_rate, due_date. True/False ফেরত দেওয়া ফাংশন বা bool ভ্যারিয়েবল প্রশ্নের মতো: is_paid, has_discount, can_vote().
• বহুবচনে সংগ্রহ: for student in students: নিজেই একটি বাক্য। for x in lst: কিছুই বলে না।
• একক থাকলে মান নয়, অর্থ: timeout_seconds = 30, price_taka — timeout = 30 দেখে বোঝা যায় না ৩০ সেকেন্ড না মিলিসেকেন্ড।
• টাইপ নামে লিখবেন না: str_name, lst_marks, dict_stock — এটি Hungarian notation-এর ধাঁচ, যা পুরোনো C/Windows কোডে প্রচলিত ছিল। Python-এ type বদলাতে পারে (list থেকে tuple), তখন নামটি মিথ্যা বলে; আর type জানানোর আসল জায়গা type hint.
• সংক্ষেপ এড়িয়ে চলুন, শুধু সর্বজনীনগুলো ছাড়া (url, id, html, লুপে i). cust_addr_ln2 নয়, customer_address_line2. আর ফেলে দেওয়া মানের জন্য পর্ব ১৫-এর _: for _ in range(3):.

Docstring — ফাংশন কী করে, কাকে কী দিতে হবে

পর্ব ০৪-এ docstring-এর পরিচয় পেয়েছেন। এর নিয়ম আছে আলাদা একটি PEP-এ — PEP 257: তিনটি ডাবল কোট ("""), প্রথম লাইনে এক বাক্যের সারাংশ (আদেশসূচক: “Return…”, “ফেরত দেয়…”), দরকার হলে একটি ফাঁকা লাইন আর তারপর বিস্তারিত। প্রতিটি public module, class, ফাংশন আর method-এ docstring থাকা উচিত। help(func), VS Code-এর hover আর documentation-টুল সবাই এটিই দেখায়।

def monthly_installment(principal: float, annual_rate: float, months: int) -> float:
    """Return the fixed monthly installment (EMI) for a loan.

    annual_rate is a fraction, e.g. 0.09 for 9%. Raises ValueError
    if months is not positive.
    """
    if months <= 0:
        raise ValueError("months must be positive")
    r = annual_rate / 12          # সূত্রে মাসিক হার লাগে
    if r == 0:
        return principal / months
    return principal * r / (1 - (1 + r) ** -months)

Comment — “কী” নয়, “কেন”

ভালো নাম আর পরিষ্কার কোড নিজেই বলে “কী” হচ্ছে। comment-এর কাজ যা কোড বলতে পারে না, তা বলা — কেন. তুলনা করুন:

• i += 1 # i এক বাড়াও — অকেজো; কোডই এটা বলছে।
• retries = 5 # bKash-এর sandbox মাঝে মাঝে প্রথম অনুরোধ ফেলে দেয় — মূল্যবান; এই তথ্য কোড থেকে কোনোদিন জানা যেত না।
• # Bangla Unicode-এ ‘য়’ দুইভাবে লেখা যায়; তুলনার আগে NFC করছি — পরের প্রোগ্রামারকে একটি রাত বাঁচিয়ে দেয়।

আরেকটি নিয়ম: কোড বদলালে comment-ও বদলান। ভুল comment কোনো comment না থাকার চেয়ে খারাপ। আর কোড comment করে রেখে দেবেন না (# old_total = ...) — পুরোনো রূপ git-এর ইতিহাসে আছে।

Public API-তে type hint

পর্ব ৩৭-এ দেখেছেন type hint চলার সময় কিছু করে না, কিন্তু পাঠক আর টুলকে চুক্তিটা জানায়। কোথায় দেবেন? সবচেয়ে বেশি লাভ public API-তে — যে ফাংশন অন্য module বা অন্য মানুষ ডাকবে: তার argument আর return-এর type. উপরের monthly_installment-এর signature পড়েই বোঝা যায় কী দিতে হবে আর কী পাবেন; docstring-এ আর টাইপ লেখার দরকার নেই। ছোট local ভ্যারিয়েবলে hint সাধারণত অপ্রয়োজনীয় — count: int = 0 পাঠককে নতুন কিছু বলে না।

৭ · টুল স্টাইল সামলাক — ruff, black, isort, mypy আর pre-commit

PEP 8-এর প্রতিটি নিয়ম মনে রেখে প্রতিটি লাইনে মানা — আর code review-তে “এখানে কমার পরে space দিন” লিখে সময় নষ্ট করা — দুটোই অপচয়। এই কাজ যন্ত্রের। দুই ধরনের টুল আছে:

ruff — একটি টুলে প্রায় সব

বহু বছর ধরে একটি Python প্রকল্পে আলাদা আলাদা টুল লাগত: flake8 (ভুল আর PEP 8), isort (import), black (ফরম্যাট), সাথে আরও কয়েকটি plugin. প্রতিটির নিজের config, নিজের গতি। ২০২২ সালে Charlie Marsh প্রকাশ করেন ruff — Rust-এ লেখা একটি linter, যা এসব টুলের কয়েকশো নিয়ম একসাথে, আর অনেক গুণ দ্রুত চালায়। পরে এতে formatter যোগ হয়, যার লক্ষ্য black-এর সাথে প্রায় হুবহু মিল। ruff-এর পেছনের কোম্পানি Astral পরে uv-ও বানিয়েছে, যা পর্ব ২৩-এ দেখেছেন। বড় প্রকল্পে যেখানে পুরোনো টুলগুলো কয়েক মিনিট নিত, ruff প্রায়ই এক সেকেন্ডের কম নেয় — তাই প্রতিবার ফাইল সেভ করার সাথে সাথে চালানো যায়।

pip install ruff               # বা: uv add --dev ruff
ruff check .                   # সব ফাইলে lint
ruff check . --fix             # নিরাপদ সমাধানগুলো নিজেই করে দাও
ruff format .                  # ফরম্যাট করো (black-ধাঁচে)
ruff format --check .          # শুধু দেখাও, বদলিও না (CI-তে)

একটি দোকানের হিসাবের অগোছালো ফাইলে ruff কী বলে আর কী করে, ধাপে ধাপে দেখুন:

import os, sys
import json
from math import *

def calc_total(items,discount = None):
    total=0
    for i in range(len(items)):
        total = total+items[i]["price"]*items[i]["qty"]
    if discount != None:
        total = total - discount
    try:
        rate = float(os.environ["VAT"])
    except:
        rate = 0.15
    unused = 42
    return total*(1+rate)

shop.py:1:1: E401 [*] Multiple imports on one line
shop.py:1:1: I001 [*] Import block is un-sorted or un-formatted
shop.py:1:12: F401 [*] `sys` imported but unused
shop.py:2:8: F401 [*] `json` imported but unused
shop.py:3:1: F403 `from math import *` used; unable to detect undefined names
shop.py:9:20: E711 Comparison to `None` should be `cond is not None`
shop.py:13:5: E722 Do not use bare `except`
shop.py:15:5: F841 Local variable `unused` is assigned to but never used
Found 8 errors.
[*] 4 fixable with `--fix` (2 unsafe fixes available ...)

import os
from math import *


def calc_total(items,discount = None):
    total=0
    ...
Found 8 errors (4 fixed, 4 remaining).

def calc_total(items, discount=None):
    total = 0
    for i in range(len(items)):
        total = total + items[i]["price"] * items[i]["qty"]
    if discount != None:
        ...
    return total * (1 + rate)
1 file reformatted

import os

VAT_FALLBACK = 0.15


def calc_total(items, discount=None):
    total = sum(item["price"] * item["qty"] for item in items)
    if discount is not None:
        total -= discount
    try:
        rate = float(os.environ["VAT"])
    except (KeyError, ValueError):
        rate = VAT_FALLBACK
    return total * (1 + rate)
$ ruff check shop.py  →  All checks passed!

pyproject.toml-এ নিয়ম লিখে রাখা

প্রতিটি মানুষ নিজের মেশিনে আলাদা নিয়মে টুল চালালে লাভ নেই। পর্ব ২৩-এর pyproject.toml-এ নিয়ম লিখে রাখুন — তাহলে প্রকল্পের সবার, আর CI-এর, একই নিয়ম:

[tool.ruff]
line-length = 88
target-version = "py312"

[tool.ruff.lint]
# E/W = pycodestyle, F = pyflakes, I = isort, B = bugbear (সম্ভাব্য বাগ),
# UP = pyupgrade (পুরোনো ধাঁচ → আধুনিক), SIM = সরল করার পরামর্শ
select = ["E", "W", "F", "I", "B", "UP", "SIM"]

[tool.ruff.lint.per-file-ignores]
"tests/*" = ["B011"]

ruff-এর নিজের default নিয়মের তালিকা সময়ের সাথে বদলেছে, তাই select স্পষ্ট লিখে রাখাই নিরাপদ। নতুন প্রকল্পে ছোট তালিকা দিয়ে শুরু করুন, পরে ধীরে ধীরে বাড়ান। কোনো একটি লাইনে নিয়ম ভাঙা সত্যিই দরকার হলে সেই লাইনের শেষে noqa comment দিন — # noqa: F401 — আর পাশে কারণ লিখুন, যেমন Zen-এর প্রোগ্রামে করেছি। ঢালাওভাবে # noqa লেখা টুলের মুখ বন্ধ করা মাত্র।

black, isort, flake8, pylint — ইতিহাস আর আজকের জায়গা

• pylint (২০০৩ থেকে): সবচেয়ে পুরোনো আর সবচেয়ে কড়া linter-গুলোর একটি; অনেক গভীর বিশ্লেষণ করে (যেমন অনেক বেশি argument-ওয়ালা ফাংশন), কিন্তু ধীর আর শুরুতে প্রচুর সতর্কবার্তা দেয়। এখনো অনেক প্রকল্পে চলে, বিশেষত ruff যা ধরে না এমন কিছু নিয়মের জন্য।
• flake8 (২০১০ থেকে): তিনটি টুল এক মোড়কে — pyflakes (আসল ভুল), pycodestyle (PEP 8) আর mccabe (জটিলতা)। plugin-এর বিশাল জগৎ। ruff-এর E, F, B ইত্যাদি কোড এসেছে এখান থেকেই।
• isort: import সাজানোর বিশেষ টুল; ruff-এর I নিয়ম একই কাজ করে।
• black (২০১৮ থেকে): “The uncompromising code formatter” — প্রায় কোনো সেটিং নেই, ইচ্ছা করেই। ruff format-এর নকশা black-কে অনুসরণ করে। কেন এই “আপসহীনতা” এত জনপ্রিয় হলো, ভাবনার প্রশ্ন ২-এ।
• mypy: পর্ব ৩৭-এর type checker. ruff type যাচাই করে না, তাই দুটি পাশাপাশি চলে।

pre-commit — ভুল ঢোকার আগেই থামানো

টুল থাকলেই হয় না, চালাতে মনে রাখতে হয়। git hook হলো git-এর একটি ব্যবস্থা, যা নির্দিষ্ট সময়ে (যেমন commit-এর ঠিক আগে) একটি স্ক্রিপ্ট চালায়। pre-commit নামের টুল এই hook সহজে সাজাতে দেয়: প্রকল্পে একটি .pre-commit-config.yaml রাখুন —

repos:
  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.x.y            # ruff-এর যে version ব্যবহার করবেন
    hooks:
      - id: ruff-check
        args: [--fix]
      - id: ruff-format

তারপর একবার pip install pre-commit আর pre-commit install. এখন থেকে প্রতিটি git commit-এর আগে ruff চলবে; সমস্যা থাকলে commit আটকে যাবে আর ruff যা পারে ঠিক করে দেবে। একই যাচাই CI-তেও চালান (পর্ব ৩৯-এর continuous integration) — কেউ hook বাদ দিয়ে commit করলেও pull request-এ ধরা পড়বে।

৮ · Anti-pattern আর code review

Anti-pattern হলো এমন সমাধান, যা শুরুতে স্বাভাবিক মনে হয় কিন্তু বারবার সমস্যা তৈরি করে। এগুলো চেনা থাকলে নিজের কোডে, অন্যের কোডে আর AI-এর কোডে দ্রুত ধরতে পারবেন। পর্ব ৩১-এর code smell-এর মতোই — গন্ধ পেলে কাছে গিয়ে দেখুন।

বাস্তব উদাহরণ: দোকানের স্টক ফাংশন পরিষ্কার করা

পুরান ঢাকার একটি পাইকারি দোকানের স্টক থেকে “যে পণ্য প্রায় শেষ” তার তালিকা বানানোর একটি ফাংশন, আগে আর পরে:

# আগে
def checkStock(d, lst=[]):
    for k in d.keys():
        if d[k]["qty"] < 10:
            if d[k]["active"] == True:
                lst.append(k + " (" + str(d[k]["qty"]) + " left)")
    return lst

# পরে
LOW_STOCK_LIMIT = 10


def low_stock_report(stock: dict[str, dict]) -> list[str]:
    """Return 'name (qty left)' for active products below the limit."""
    return [
        f"{name} ({item['qty']} left)"
        for name, item in stock.items()
        if item["active"] and item["qty"] < LOW_STOCK_LIMIT
    ]

এক নজরে বদলগুলো: camelCase নাম → snake_case আর ক্রিয়াবাচক নাম; d, lst, k → stock, name, item; সবচেয়ে বিপজ্জনক — lst=[] mutable default, যার কারণে দ্বিতীয়বার ডাকলে আগের তালিকাও আবার আসত (দোকানদার ভাবতেন একই পণ্য দুবার কম!); .keys() আর d[k] বারবার → .items(); == True → সরাসরি; দুই স্তর if → and; জাদুর ১০ → ধ্রুবক; যোগ-চিহ্ন → f-string; আর public ফাংশনে type hint ও docstring.

Code review — কী দেখবেন, কীভাবে বলবেন

Code review মানে কোড মূল শাখায় যাওয়ার আগে অন্য একজনের চোখ বুলানো — সাধারণত একটি pull request-এ। Formatter আর linter যখন স্টাইল সামলায়, তখন reviewer-এর সময় যায় আসল প্রশ্নে: যুক্তি ঠিক আছে কি? edge case? নাম কি অর্থ বলে? test আছে কি? ওপরের checkStock একটি pull request-এ এলে একজন ভালো reviewer-এর মন্তব্য দেখতে এরকম:

1. [জরুরি] lst=[] default — ফাংশন দ্বিতীয়বার ডাকলে আগের ফল জমে থাকবে। None দিয়ে শুরু করা, বা list ফেরত দেওয়া comprehension কি চলবে?
2. [জরুরি] কোনো পণ্যে "active" চাবি না থাকলে KeyError. পুরোনো ডেটায় এমন পণ্য আছে কি? থাকলে item.get("active", False).
3. [পরামর্শ] ১০ সংখ্যাটির একটি নাম দিলে পরে সীমা বদলানো সহজ হবে — সম্ভবত পণ্যভেদে আলাদা সীমাও লাগবে?
4. [পরামর্শ] for name, item in stock.items() লিখলে d[k] তিনবার লিখতে হয় না।
5. [প্রশ্ন] ঠিক ১০টি থাকলে কি “প্রায় শেষ”? এখন < 10 — ইচ্ছাকৃত হলে docstring-এ লিখে দিন।
6. [ছোট] একটি test যোগ করবেন? খালি স্টক, inactive পণ্য আর ঠিক সীমায় থাকা পণ্য — তিনটি ঘটনা।

৯ · AI-এর যুগে — সঠিক কিন্তু অ-Pythonic কোড ধরা

AI-কে “ফলাফলের স্ক্রিপ্ট লিখে দাও” বললে যে কোড আসে, তা প্রায়ই চলে — কিন্তু প্রায়ই Python-এর মতো দেখায় না। কারণ বোঝা সহজ: AI শিখেছে কোটি কোটি লাইন কোড থেকে, যার অনেকটা C, Java আর পুরোনো Python 2 যুগের টিউটোরিয়াল। ফলে মিশ্র উচ্চারণ আসে। কয়েকটি বারবার দেখা ধরন:

ভালো খবর: এর অনেকটাই যন্ত্রে ধরা যায়। AI-এর কোড প্রকল্পে আনার আগে একটি অভ্যাস করুন — ruff check --fix আর ruff format চালান, তারপর বাকি সতর্কবার্তা পড়ুন। আর শুরুতেই AI-কে আপনার মান বলে দিন:

AI-এর লেখা Python কোড পেলে — যাচাইয়ের চেকলিস্ট

• ruff check --fix আর ruff format চালিয়েছি; বাকি সতর্কবার্তা পড়ে প্রতিটির সিদ্ধান্ত নিয়েছি
• নামগুলো এক ধাঁচের — snake_case, PascalCase, UPPER_CASE — আর প্রতিটি নাম অর্থ বলে
• range(len()), getter/setter, == None, == True-এর মতো অন্য-ভাষার ধাঁচ নেই
• exception নির্দিষ্টভাবে ধরা; কোথাও ভুল চুপচাপ গিলে ফেলা হচ্ছে না
• কোনো লাইন বোঝাতে আমার নিজের কষ্ট হলে সেটি সরল করতে বলেছি বা নিজে করেছি
• test চালিয়ে দেখেছি — Pythonic করার পরেও ফল আগের মতো