Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Проводник по Python. Пишем изумительный код

Anna | 16.06.2014 | нет комментариев
Добродушного времени суток, Програпрогр. Сегодня на крыле принес еще один перевод я (pdf-ки гугловского стайл гайда выложены). Правда, кто знает, если кто-то оценит сию работу — быть может появится и продолжение. Как-то днём одним, предложил мне мой обширно знаменитый в тесных кругах сотрудник scraplesh почитать источник — The Hitchhiker’s Guide to Python! называемый. Источник данный понравился мне. Понравились советы выдаваемые там. Понравилась канва повествования и вообще понравилось направление мысли автора. А если что-то отлично на Ваш вкус, то необходимо передавать это из уст в уста:) Выходит, решил я сделать перевод данного источника. Но не всё так сразу — вначале будет пробная статья «на отклик» програсообщества. Если уважаемым гикам понравится сия тематика и изложение — будем усердствовать выпускать новые части. На 1-й «отклик» я предпочел раздел — “Writing Great Code” и в нем два подпункта «Structure is Key» и «Modules». Откликнемся под катом.

Но перед тем, как окунуться с головой в чужие мысли касательно любимого Python, необходимо представить собственно автора источника. Зовут его Kenneth Reitz. Как я осознал по собранной информации — он высокопрофессиональный фотограф (об этом мы можем узнать на его личном сайте), евангелист языка Python и легко гуру различного рода разработки. Работает он на данный момент (по неподтвержденным данным) в Heroku. Так же перепризываю всех форкать его план на гитхаб.

Фотография Кеннета

Kenneth Reitz на PyCon в Австралии (2012)

Дальше — собственно сама статья. (При выявлении ошибок, как водится — сразу кричите о них! Ошибки требуют исправления.)

Структурируйте свой план

Под конструкцией мы подразумеваем решения, которые Вы приняли в отношении того, как Ваш план сумеет достичь поставленных целей. Мы обязаны разглядеть как отменнее применять функциональные особенности языка Python, Дабы писать чистый и результативный код. С утилитарной точки зрения, представление «конструкция» обозначает создание (написание) чистого когда в котором, логика и зависимости так же ясны как организация файлов и папок в файловой системе.

Какие функции обязаны быть перемещены в какие модули? Как пойдет поток данных через план? Какие особенности и функции могут быть сгруппированы совместно и изолированы? Отвечая на сходственные вопросы, Вы можете начать планировать как будет выглядеть готовый продукт.

В данном разделе мы внимательнее посмотрим на систему модулей и импортов в Python, т.к. они являются центральным элементом в обеспечении структурирования Вашего плана. После этого, мы обсудим разные точки зрения о том, как возвести код, тот, что может быть расширен и верно протестирован.

Конструкция решает

Вследствие тому, что импорты и модули обрабатываются в Python, относительно легко структурировать план написанный на этом языке. Слово «легко», в данном контексте обозначает, что Вы не будете создавать лишних ограничений, и то, что модель импортируемого модуля легко осознать. Таким образом, Вам остается сконцентрироваться на чисто архитектурной задаче, а именно работать над созданием разных частей Вашего плана и их взаимодействии.

Легко структурированный план — обозначает, что также легко дозволено сделать и нехорошо структурированный план. Некоторые знаки нехорошо структурированного плана:

  • Множественные и чумазые циклические зависимости. Если Ваши классы Table и Chair нуждаются в импорте класса Carpenter из модуля workers.py, для того, Дабы ответить на вопросtable.isdoneby(), и наоборот, если класс Carpenter нуждается в импорте класса Table и классаChair, Дабы ответить на вопрос carpenter.whatdo() — Вы получаете циклическую связанность. В этом случае Вам придется прибегнуть к хитроумным уловкам, таким как применение оператора импорта внутри способов либо функций.
  • Спрятанные связи. Все и всякое метаморфоза в классе Table проваливает 20 тестов в несвязанных тестах, т.к. оно извращает выполнение кода класса Carpenter, тот, что требует хирургически тонкого адаптивного метаморфозы кода. Это обозначает, что у Вас слишком много «договоренностей» касательно класса Table в коде класса Carpenter либо напротив.
  • Насыщенное применение глобального пространства имен либо контекста. Взамен очевидной передачи (высота, ширина, тип, дерево) друг другу переменных классами Table и Carpenter, Вы полагаетесь на всеобщии переменные, которые могут быть изменены и модифицированы на лету различными «товарищами». Вы обязаны наблюдательно исследовать все места, откуда дозволено получить доступ к этим глобальным переменным, Дабы осознать, отчего прямоугольный стол стал квадратным и найти, что удаленный код так же подвергся изменению в данном контексте, подменив размеры стола.
  • Спагетти-код. Несколько страниц вложенных друг в друга конструкций if и циклов for с огромным числом повторяющегося кода и вообще не сегментированного, знаменитого как спагетти, кода. Вследствие значащим отступам в Python (одной из самых обговариваемых особенностей), дюже трудно писать такой код на данном языке. Так что есть отличные новости — Вы не будете следить такой код Зачастую.
  • Равиоли-код. Такой код больше нормален для Python. Он состоит из сотен идентичных (либо сходственных друг другу) ломтиков логики, классов либо объектов без надлежащей классификации. Если Вы никак не можете запомнить не применять FurnitureTableAssetTable либо Table, либо дажеTableNew для решения Вашей задачи — Вы будете купаться в равиоли-коде.
Модули

Модули в Python являются одним из основных слоев абстракции которые доступны, и, возможно, являются особенно нативными для языка. ?русы абстракции разрешают поделить код на части обрабатывающие соответствующие данные и содержащие какой-либо функционал.

Скажем, один слой плана может обрабатывать взаимодействие с пользователем, в то время как иной будет обрабатывать манипулирование данными на низком ярусе. Особенно обычный метод поделить эти два яруса — это разместить всю функциональность в один файл, а все низкоуровневые операции в иной. В таком случае интерфейсный файл будет нуждаться в импорте файла с низкоуровневым функционалом. Это делается с поддержкой выражений import и from ... import.

Как только Вы начинаете применять выражение import — Вы начинаете применять модули. Это могут быть встроенные модули, такие как os и sys, сторонние модули, которые Вы установили в свою среду, либо внутренние модули Вашего плана.

Дабы придерживаться жанра начальства, усердствуйте давать модулям короткие имена, содержащие только буквы нижнего регистра и уверяться, что Вы не используете особые символы, такие как точка (.) либо знак вопроса (?). Так как имя файла сходственное my.spam.py, Вы обязаны чураться. Именование таким образом будет мешать Python искать модули.

В данном примере Python ждет обнаружить “spam.py” в папке по имени “my“, которой не существует. Существует пример того, как точечная нотация должна быть использована в документах Python.

Если Вы хотите, Вы можете назвать файл my_spam.py, но даже нашего друга — Подчеркивание — не стоит Зачастую применять в именах модулей.

Помимо некоторых ограничений именования, ничего огромнее не требуется файлу Дабы стать Python-модулем, но механизм импорта нужно понимать для того, Дабы применять эту доктрину надлежащим образом и избежать некоторых задач.

Искренне говоря, оператор импорта будет искать соответствующий файл module.py в той же директории, где находится импортирующий файл. Если он не будет обнаружен, интерпретатор Python будет искать module.pyв переменной “path” рекурсивно и возбудит исключение ImportError, если конечный не будет обнаружен.

Позже того, как module.py будет обнаружен, интерпретатор Python исполнит модуль в изолированной области видимости. Всякое объявление верхнего яруса в файле module.py будет исполнено, включая вложенные импорты, если таковые имеются. Объявления функций и классов сохранятся в словарь модуля.

После этого переменные модуля, функции и классы будут доступны для вызова через пространство имен модуля — центральное представление в программировании, которое исключительно сильно и пригодно в языке Python.

Во многих языках, файл включается напрямую применяя препроцессор Дабы обнаружить каждый код в файле и «скопировать» его в код вызывающего модуля. Это отличается от поведения языка Python, в котором подключаемый код изолирован в области видимости своего модуля, что обозначает, что Вы можете не волноваться о том, что включение кода может иметь неугодные итоги, скажем, переопределение существующих функций с тем же именем.

Это разрешает моделировать больше стандартное поведение с поддержкой особого синтаксиса выражения import: from module import *. Обыкновенно это считается дрянный практикой. Применение “import *” делает код сложным для чтения и делает зависимости менее разобщенными.

Применение from module import func это метод верно указать функцию, которую вы хотите импортировать и разместить в глобальную область видимости. А так же это менее пагубно для кода нежели “import *“, т.к. здесь ясно видно что импортируется в глобальную область видимости, преобладание больше легкой записи import module заключается в экономии нажатий клавиш.

# Very bad

[...]
from modu import *
[...]
x = sqrt(4)  # Is sqrt part of modu? A builtin? Defined above?
# Better

from modu import sqrt
[...]
x = sqrt(4)  # sqrt may be part of modu, if not redefined in between
# Best

import modu
[...]
x = modu.sqrt(4)  # sqrt is visibly part of modu's namespace

Как указано в разделе о жанре, читаемость является одной из основных особенностей Python. Читаемость обозначает уход от применения непотребного текстового наполнения и бардака в коде, следственно обыкновенно некоторые усилия расходуются на попытки достичь определенного яруса краткости кода. Но лаконичность и простота имеют определенные пределы, где сокращение кода должно прекратиться. Будучи в состоянии сразу сказать где начинается тот либо другой класс либо функция, как и идеология module.func, которая гораздо улучшает читаемость кода и его прозрачность во всех, помимо самых примитивных, отдельных стоящий планов «в одном файле».

Переводить ли дальше данный источник?

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Проголосовало 730 человек. Воздержался 161 человек.

Следует ли при оформлении статьи выделять зарезервированные языком слова полужирным?

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Проголосовало 642 человека. Воздержалось 211 человек.

 

 Источник: programmingmaster.ru
Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB