04. Добри практики

Писането на код като работа

Когато пишете код, рядко го правите самоцелно. Вместо това, вие опитвате се да решите някакъв реален проблем със собствена логика, терминология и особености. Винаги когато пишете код трябва да се стараете той да отразява много добре този проблем - това го прави много по-четим, по-лесен за поддръжка и по-разбираем от външни хора. Още повече, така вие ясно показвате намерението което вашия код има, вместо да карате читателя да задълбава в особенностите на вашата реализация.

Първо правило: Добри имена на променливи

Променливите обикновенно отговарят за съществуващи обекти/концепции в реалния проблем, който решавате. Това ги прави идеални за комуникиране на идеята на кода. За целта, обаче, се налага да избирате смислени имена.

Типична грешка

        # Грешно
        temp = sqrt(b ** 2 - 4 * a * c)
        x1 = (-b + temp) / (2 * a)
        x2 = (-b - temp) / (2 * a)

        # По-правилно
        discriminant = sqrt(b ** 2 - 4 * a * c)
        x1 = (-b + discriminant) / (2 * a)
        x2 = (-b - discriminant) / (2 * a)
    

Лоши имена

        old = read_old()
        tpl = get_values("c:/")
        tup = {}
        for t in tpl
            if old[t] != tpl[t]: continue
            tup.update({t:tpl[t]})

        show(tup)
        save(tpl)
    

Добри имена

        old_hashsums = read_cached_hashsums()
        new_hashsums = find_hashsums('c:/')

        changed_files = {}
        for filename in old_hashsums
            if old_hashsums[filename] != new_hashsums[filename]:
                changed_files[filename] = new_hashsums[filename]

        report_changes(changed_files)
        save_hashsums(new_hashsums)
    

Функция/Метод > Блок с коментар

Функциите са едно от най-често използваните средства в програмирането. И все пак, причините за които има смисъл да създавате функция са.

Именуване на функции

При именуване на рутини се съобразявайте внимателно със следните неща.

Кохезия

„Кохезията“ на една рутина смътно описва действието й. Като говорим за „добра кохезия“ имаме предвид, че една рутина прави едно единствено нещо и го прави добре. Най-силния вид „кохезия“ е функционалната.

Приемливи видове кохезия

Неприемливи видове кохезия

Аргументи на функциите

Не ползвайте глобални променливи

Когато пишете функции, не ползвайте глобални променливи. Ама въобще. Най-честия случай на неправилно ползване на глобавни променливи е когато се употребяват за комуникация между функции. Никога не правете това. В рядките случаи, в които имате нужда от „глобални“ обекти правете Singleton-и или thread.local-и.

Не ползвайте goto

В Python няма goto. Ако случайно пишете на друг език, в който има goto, това правило остава - не ползвайте goto.

Не използвайте глупави низове в съобщенията за грешка

Състоянието е зло

Като Дарт Вейдър, само дето накрая убива Люк, а не императора.

Еквивалентност

Имате два обекта. Те са равни ако…

Observational equivalence

…с произволна поредица от observer методи не може да разберете дали те са различни или не.

Behavioral equivalence

…с произволна поредица от observer-и и мутатори не може да разберете дали те са различни или не.

Design by Contract

За всеки метод се дефинира следното

Наследяването е зло

Кой кого?

        class Rectangle
                def a(self): ...
                def b(self): ...
                def setA(self, a): ...
                def setB(self, b): ...

        class Square
                def a(self): ...
                def setSide(self, side): ...
    

Liskov's Substitution Principle

Клас Б може да наследи от клас А, само ако на всички места на които може да използвате инстанция на А може да използвате инстанция на Б.

Liskov's Substitution Principle (2)

В термините на Design by Contract Б може да наследи А ако

Design Patterns

The second coming of Jesus.

Version Control System

Системите за контрол на версиите не са добра практика. Те са задължителна практика!

Колко от вас са чували за тези?

За чий ни е контрол на версиите?

История - Пълна видимост над промените

Бранчове

Пазарът и катедралата

Git and GitHub

Линукс е второто най-добро нещо, създадено от Линус Торвалдс

Още въпроси?