Серия Dev

Бърз Python: 5 най-добри практики за Pythonic код

Често студентите по компютърни науки завършват, без да познават най-добрите практики и стандарти за програмиране, използвани в софтуерната индустрия. Това води до шибан код и истории на ужасите, което води до смущение и често шеги.

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

Едно от ключовите прозрения на Гуидо е, че кодът се чете много по-често, отколкото се пише. Предоставените тук насоки имат за цел да подобрят четливостта на кода и да го направят последователен в широкия спектър от код на Python. Както се казва в PEP 20, „Четливостта има значение“.

Ще споделя 5 прости правила за писане на Python код на производствено ниво.

Правилно използване на празни редове

Оградете функцията от най-високо ниво и дефинициите на класа с два празни реда.

Дефинициите на метода вътре в клас са заобиколени от един празен ред.

Допълнителни празни редове могат да се използват (пестеливо) за разделяне на групи от свързани функции. Празните редове могат да бъдат пропуснати между куп свързани едноредови редове (напр. набор от фиктивни реализации).

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

# Add two blank lines before each function or class definition
def myfunc(a,b):
 
 # Add a blank line before every if statement
 if a > b:
 print(“Hello World”)
 
 # Add a blank line before every return statement
 return a,b

Описателни стилове на именуване

Има много различни стилове на именуване. Помага да можете да разпознаете какъв стил на именуване се използва, независимо от това за какво се използват.

Обикновено се разграничават следните стилове на именуване:

  • b (единична малка буква)
  • B (единична главна буква)
  • малка буква
  • малки_регистри_с_долна черта
  • ГЛАВНА БУКВА
  • UPPER_CASE_WITH_UNDERSCORES
  • CapitalizedWords (или CapWords, или CamelCase — наречен така заради неравния вид на буквите). Това също понякога е известно като StudlyCaps. Забележка: Когато използвате акроними в CapWords, пишете всички букви на акронима с главни букви. Следователно HTTPServerError е по-добър от HttpServerError.
  • mixedCase (различава се от CapitalizedWords по първоначалния малък знак!)
    Capitalized_Words_With_Underscores (грозно!)

Внос

Импортирането обикновено трябва да е на отделни редове:

Правилно:

import os
import sys

грешно:

import sys, os

Все пак е добре да кажете това:

Правилно:

from subprocess import Popen, PIPE

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

Вносът трябва да се групира в следния ред:

  • Стандартен импорт на библиотека.
  • Свързан импорт от трети страни.
  • Локално приложение/специфично за библиотека импортиране.

Предписващи конвенции за именуване

Глобални имена на променливи

(Да се ​​надяваме, че тези променливи са предназначени за използване само в един модул.) Конвенциите са приблизително същите като тези за функциите.

Модулите, които са предназначени за използване чрез **от M импортиране * **, трябва да използват механизма all, за да предотвратят експортирането на глобали, или да използват по-старата конвенция за префикс на такива глобали с долна черта (което може да искате да направите, за да посочите, че тези глобали са „ модул непубличен”).

Имена на функции и променливи

Имената на функциите трябва да са с малки букви, с думи, разделени с долна черта, ако е необходимо, за да се подобри четливостта.

Имената на променливите следват същата конвенция като имената на функциите.

mixedCase е разрешен само в контексти, където това вече е преобладаващият стил (напр. threading.py), за да се запази обратната съвместимост.

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

Винаги използвайте self за първия аргумент за методите за инстанциране.

Винаги използвайте cls за първия аргумент на методите на класа.

Ако името на аргумент на функция се сблъсква със запазена ключова дума, обикновено е по-добре да добавите едно долно черта в края, вместо да използвате съкращение или правописна грешка. Следователно classе по-добро от clss. (Може би е по-добре да избягвате подобни сблъсъци, като използвате синоним.)

DRY Принцип

Принципът DRY или „Не се повтаряй“ е практика за разработка на софтуер, насочена към намаляване на повторението на информация.

Популяризиран от книгата „Прагматичният програмист“, принципът DRY гласи, че „всяко знание трябва да има едно, недвусмислено, авторитетно представяне в рамките на една система“. Използването на принципа, логиката или алгоритмите, които имат определена функционалност, трябва да се появяват само веднъж в приложение.