Роман описывает события, происходившие в двух эпохах: во время Второй мировой войны и в середине девяностых, когда интернет, недавно зародившись, очень активно развивался. Автор очень умело сочетает своих вымышленных героев с реальными историческими фигурами. Многие события происходят будто бы независимо друг от друга, но лишь к концу книги открывается взаимосвязь всех событий, описанных на немалых просторах произведения. А они, действительно, немалые – 912 страниц. Описывать сам сюжет, думаю, не имеет смысла, так как о нём немало написано на просторах сети; да и если кто-нибудь заинтересуется книгой, то может приобрести её в любом интернет-магазине или ближайших книжных лавках.

В книге очень много различных технических терминов, что мне, как технарю, было определённо приятно. Само повествование достаточно запутанное, так как изобилует аббревиатурами, значение которых читателю раскрывается лишь много позже.

Вокруг книги уже сложилось несколько мифов. Один из которых – «Криптономикон» киберпанк. Хочется незамедлительно развеять это утверждение, так как сам роман не имеет ничего общего с киберпанком. «Криптономикон» можно больше отнести к историческим произведениям. В романе нет никакой фантастики, которая свойственна киберпанку. Поэтому определённо найдутся люди, которым произведение не понравится.

От себя могу сказать ещё то, что лично мне книга очень понравилась и теперь стоит на почётном месте на книжной полке. В дальнейшем планирую прочитать другие творения Нила Стивенсона, которые, по словам критиков, ничуть не отстают от «Криптономикона» .

Комментарии, которые противоречат коду, хуже, чем отсутствие комментариев. Всегда исправляйте комментарии, если меняете код!

Комментарии должны являться законченными предложениями. Если комментарий — фраза или предложение, первое слово должно быть написано с большой буквы, если только это не имя переменной, которая начинается с маленькой буквы (кстати, никогда не отступайте от этого правила для имен переменных).

Если комментарий короткий, можно опустить точку в конце предложения. Блок комментариев обычно состоит из одного или более абзацев, составленных из полноценных предложений, поэтому каждое предложение должно оканчиваться точкой.

Ставьте два пробела после точки в конце предложения.

Если вы пишете по-английски, не забывайте о Странке и Уайте (имеется в виду книга Strunk & White, “Elements of style”, которая является практически эталонным руководством по правильному написанию текстов на английском языке, — прим. перев.)

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

Блок комментариев

Блок комментариев обычно объясняет код (весь, или только некоторую часть), идущий после блока, и должен иметь тот же отступ, что и сам код. Каждая строчка такого блока должна начинаться с символа # и одного пробела после него (если только сам текст комментария не имеет отступа).

Абзацы внутри блока комментариев лучше отделять строкой, состоящей из одного символа #.

Комментарии в строке с кодом

Старайтесь реже использовать подобные комментарии.

Такой комментарий находится в той же строке, что и инструкция. «Встрочные» комментарии должны отделяться хотя бы двумя пробелами от инструкции. Они должны начинаться с символа # и одного пробела.

Комментарии в строке с кодом не нужны и только отвлекают от чтения, если они объясняют очевидное. Не пишите вот так:

Copy Source | Copy HTML

1. x = x + 1 # Increment x 

Впрочем, иногда такие комметарии полезны:

Copy Source | Copy HTML

1. x = x + 1 # Compensate for border 

Строки документации

Соглашения о написании хорошей документации (docstrings) увековечены (да, забавно, но автор использует именно такое слово, — прим. перев.) в PEP 257¹.

Пишите документацию для всех модулей, функций, классов, методов, которые объявлены как public. Строки документации необязательны для не-public методов, но лучше написать, что делает метод. Комментарий нужно писать после строки с def.

PEP 257 объясняет, как правильно и хорошо документировать. Заметьте, очень важно, чтобы закрывающие “”" стояли на отдельной строчке. А еще лучше, если перед ними будет ещё и пустая строка, например:

Copy Source | Copy HTML

1. """Return a foobang  
   Optional plotz says to frobnicate the bizbaz first. 
   """

Для однострочной документации можно оставить “”" на той же строке.

Учёт версий

Если вам нужно использовать Subversion, CVS или RCS в ваших исходных кодах, делайте вот так:

Copy Source | Copy HTML

1. version__ = "$Revision: 68852 $"
2. # $Source$ 

Вставляйте эти строки после документации модуля перед любым другим кодом и отделяйте их пустыми строками по одной до и после.

Имена

Соглашения об именах переменных в python немного туманны, поэтому их список никогда не будет полным — тем не менее, ниже мы приводим список рекоммендаций, действующих на данный момент. Новые модули и пакеты должны быть написаны согласно этим стандартам, но если в какой- либо уже существующей библиотеке эти правила нарушаются, предпочтительнее писать в едином с ней стиле.

Описание: Стили имен

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

Обычно различают следующие стили:
• b (одиночная маленькая буква)
• B (одиночная заглавная буква)
• lowercase (слово в нижнем регистре)
• lower_case_with_underscores (слова из маленьких букв с подчеркиваниями)
• UPPERCASE (заглавные буквы)
• UPPERCASE_WITH_UNDERSCORES (слова из заглавных букв с подчеркиваниями)
• CapitalizedWords (слова с заглавными буквами, или CapWords, или CamelCase. Иногда называется StudlyCaps). Замечание: когда вы используете аббревиатуры в таком стиле, пишите все буквы аббревиатуры заглавными — HTTPServerError лучше, чем HttpServerError.
• mixedCase (отличается от CapitalizedWords тем, что первое слово начинается с маленькой буквы)
• Capitalized_Words_With_Underscores (слова с заглавными буквами и подчеркиваниями — уродливо!)
• Ещё существует стиль, в котором имена, принадлежащие одной логической группе, имеют один короткий префикс. Этот стиль редко используется в python, но мы упоминаем его для полноты. Например, функция os.stat() возвращает кортеж, имена в котором традиционно имеют вид st_mode, st_size, st_mtime и так далее. (Так сделано, чтобы подчеркнуть соответствие этих полей структуре системных вызовов POSIX, что помогает знакомым с ней программистам).

В библиотеке X11 используется префикс Х для всех public-функций. В python этот стиль считается излишним, потому что перед полями и именами методов стоит имя объекта, а перед именами функций стоит имя модуля.

В дополнение к этому, используются следующие специальные формы записи имен с добавлением символа подчеркивания в начало или конец имени:
• _single_leading_underscore: слабый индикатор того, что имя используется для «внутренних нужд». Например, from M import * не будет импортировать объекты, чьи имена начинаются с символа подчеркивания.
• single_trailing_underscore_: используется по соглашению для избежания конфликтов с ключевыми словами языка python, например:

Copy Source | Copy HTML

1. Tkinter.Toplevel(master, class_='ClassName')

• __double_leading_underscore: изменяет имя атрибута класса, т.е. в class FooBar поле __boo становится _FooBar__boo.
• __double_leading_and_trailing_underscore__ (двойное подчеркивание в начале и в конце имени): «волшебные» объекты или атрибуты, которые «живут» в пространствах имен, управляемых пользователем (user-controlled namespaces). Например, __init__, __import__ или __file__. Не изобретайте такие имена, используйте их только так, как написано в документации.

Стили имен

Имена, которых следует избегать

Никогда не используйте символы l (малелькая латинская буква «эль»), O (заглавная латинская буква «о») или I (заглавная латинская буква «ай») как однобуквенные идентификаторы.

В некоторых шрифтах эти символы неотличимы от цифры один и нуля (и символа
вертикальной палочки, — прим. перев.) Если очень нужно использовать l имена, пишите
вместо неё заглавную L.

Имена модулей и пакетов

Модули должны иметь короткие имена, состоящие из маленьких букв. Можно использовать и символы подчеркивания, если это улучшает читабельность. То же, за исключением символов подчеркивания, относится и к именам пакетов.

Так как имена модулей отображаются в имена файлов, а некоторые файловые системы являются нечувствительными к регистру символов и обрезают длинные имена, очень важно
использовать достаточно короткие имена модулей — это не проблема в Unix, но, возможно, код окажется непереносимым в старые версии Windows или Mac, или DOS.

Когда модуль расширения, написанный на С или C++, имеет сопутствующий python-модуль (содержащий интерфейс высокого уровня), С/С++ модуль начинается с символа подчеркивания, например, _socket.

Имена классов

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

Имена исключений (exceptions)

Так как исключения являются классами, к исключениями применяется стиль именования классов. Однако вы можете добавить Error в конце имени (если конечно исключение действительно является ошибкой).

Имена глобальных переменных

Будем надеяться, что такие имена используются только внутри одного модуля. Руководствуйтесь теми же соглашениями, что и для имен функций.

Добавляйте в модули, которые написаны так, чтобы их использовали с помощью from M import *, механизм __all__ чтобы предотвратить экспортирование глобальных переменных. Или же, используйте старое соглашение, добавляя перед именами таких глобальных переменных один символ подчеркивания (которым вы можете обозначить те глобальные переменные, которые используются только внутри модуля).

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

Имена функций должны состоять из маленьких букв, а слова разделяться символами подчеркивания — это необходимо, чтобы увеличить читабельность. Стиль mixedCase допускается в тех местах, где уже преобладает такой стиль, например во threading.py, для сохранения обратной совместимости.

Аргументы функций и методов

Всегда используйте self в качестве первого аргумента метода экземпляра объекта (instance method).

Всегда используйте cls в качестве первого аргумента метода класса (class method).

Если имя аргумента конфликтует с зарезервированным ключевым словом python, обычно
лучше добавить в конец имени символ подчеркивания, чем исказить написание слова или использовать аббревиатуру. Таким образом, print_ лучше, чем prnt. (Возможно, хорошим вариантом будет подобрать синоним).

Имена методов и переменные экземпляров классов

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

Чтобы избежать конфликта имен с подклассами, добавьте два символа подчеркивания, чтобы включить механизм изменения имен. Если класс Foo имя атрибут с именем __foo, к нему нельзя обратиться, написав Foo.__a. (Настойчивый пользователь всё равно может получить доступ, написав Foo._Foo__a). Вообще, двойное подчеркивание в именах должно использоваться, чтобы избежать конфликта имен с атрибутами классов, спроектированных так, чтобы от них наследовали подклассы.

Константы

Константы обычно объявляются на уровне модуля и записываются только заглавными буквами, а слова разделяются символами подчеркивания. Например: MAX_OVERFLOW, TOTAL.

Проектирование наследования

Обязательно решите, каким должен быть метод класса или переменная экземпляра класса (в общем, атрибут) — public или не-public. Если вы сомневаетесь, выберите закрытый, не-public атрибут. Потом будет проще сделать их public, чем наоборот.

Открытые атрибуты — это те, которые будут использовать потребители ваших классов, и вы должны быть уверены в отсутствии обратной несовместимости. Не-public атрибуты, в свою очередь, не предназначены для использования третьими лицами, поэтому вы можете не гарантировать, что не измените или не удалите эти атрибуты.

Мы не используем термин «закрытый член» (private), потому что на самом деле в python таких членов не бывает.

Другой тип аттрибутов классов принадлежит так называемому API подклассов (в других языках они часто называются protected). Некоторые классы проектируются так, чтобы от них наследовали другие классы, которые расширяют или модифицируют поведение базового класса. Когда вы проектируете такой класс, решите и явно укажите, какие атрибуты являются открытыми (public), какие принадлежат API подклассов (subclass API), а какие используются только базовым классом.

Теперь сформулируем рекомендации:

• Открытые атрибуты не должны иметь в начале имени символа подчеркивания

• Если имя открытого атрибута конфликтует с ключевым словом языка, добавьте в конец имени один символ подчеркивания. Это более предпочтительно, чем аббревиатура или искажение написания (однако, у этого правила есть исключение — аргумента который означает класс, и особенно первый аргумент метода класса (class method) должен иметь имя cls).

• Назовите простые открытые атрибуты понятными именами и не пишите сложные методы доступа и изменения (accessor/mutator, get/set, — прим. перев.) Помните, что в python очень легко добавить их потом, если потребуется. В этом случае используйте свойства (properties), чтобы скрыть функциональную реализацию за синтаксисом доступа к атрибутам.
• Свойства (properties) работают только в классах нового стиля (new-style classes)
• Постарайтесь избавиться от побочных эффектов, связанным с функциональным поведением; впрочем, такие вещи, как кэширование, вполне допустимы.
• Избегайте использования вычислительно затратных операций, потому что из-за записи с помощью атрибутов создается впечатление, что доступ происходит (относительно) быстро.

• Если вы планируете класс таким образом, чтобы от него наследовались другие классы, но не хотите, чтобы подклассы унаследовали некоторые атрибуты, добавьте в имена два символа подчеркивания в начало, и ни одного — в конец. Механизм изменения имен в python (name mangling, — прим. перев.) сработает так, что имя класса добавится к имени такого атрибута, что позволит избежать конфликта имен с атрибутами подклассов.
• Будьте внимательны: если подкласс будет иметь то же имя класса и имя атрибута, то вновь возникнет конфликт имен.
• Механизм изменения имен может затруднить отладку или работу с __getattr__(), однако он хорошо документирован и легко реализуется вручную.
• Не всем нравится этот механизм, поэтому старайтесь достичь компромисса между необходимостью избежать конфликта имен и возможностью доступа к этим атрибутам.

Общие рекомендации

Код должен быть написан так, чтобы не зависеть от разных реализация языка (PyPy, Jython, IronPython, Pyrex, Psyco и пр.). Например, не полагайтесь на эффективную реализацию в CPython конкатенации строк в выражениях типа a+=b или a=a+b. Такие инструкции выполняются значительно медленнее в Jython. В критичных к времени выполнения частях программы используйте ”.join() — таким образом склеивание строк будет выполнено за линейное время независимо от реализации python.

Сравнения с None должны обязательно выполняться с использованием операторов is или is not, а не с помощью операторов равенства или неравенства.

Кроме того, не пишите if x, если имеете в виду if x is not None — если, к примеру, при тестировании такая переменная или аргумент примет значение иного типа, то при приведении к булевскому типу получится false.

Создавайте исключения на основе классов. Впрочем, начиная с версии python 2.6, мы уже не можем использовать строки в качестве исключений. В модулях или пакетах создавайте свои базовые классы исключений, наследуя их от встроенного класса Exception и обязательно их документируйте:

Copy Source | Copy HTML

1. class MessageError(Exception):
2.     """Base class for errors in the email package."""

Здесь применимы те же правила, что и для именования классов. Если исключение по своему смыслу является ошибкой, вы можете добавить в конце имени Error.

Когда вы генерируете исключение, пишите raise ValueError(’message’) вместо старого синтаксиса raise ValueError, message. Такое использование предпочтительнее, потому что из-за скобок не нужно использовать символы для продолжения перенесенных строк, если эти строки длинные или если используется форматирование. Старая форма записи запрещена в python 3000.

Когда код перехватывает исключения, «ловите» конкретные ошибки вместо простого выражнения except:. К примеру, пишите вот так:

Copy Source | Copy HTML

1. try:
2.     import platform_specific_module
3. except ImportError:
4.     platform_specific_module = None

Простое написание ‘except:’ также перехватит и SystemExit, и KeyboardInterrupt, что породит проблемы, например, сложнее будет завершить программу нажатием control+C. Если вы действительно собираетесь перехватить все исключения, пишите ‘except Exception:’.

Ограничьтесь использованием чистого ‘except:’ в двух случаях:

1. Если обработчик исключения выводит пользователю всё о случившейся ошибке (например, traceback)

2. Если нужно выполнить некоторый код после перехвата исключения, а потом вновь «бросить» его для обработки где-то в другом месте. Обычно же лучше пользоваться конструкцией ‘try…finally’.

Постарайтесь заключать в каждую конструкцию try…except минимум кода, чтобы легче отлавливать ошибки.

можно:

Copy Source | Copy HTML

1. try:
2.     value = collection[key]
3. except KeyError:
4.     return key_not_found(key)
5. else:
6.     return handle_value(value)

нельзя:

Copy Source | Copy HTML

1. try:
2.     return handle_value(collection[key])
3. except KeyError:
4.     return key_not_found(key)

Используйте строковые методы вместо модуля string — они всегда быстрее и имеют тот же API для unicode-строк. Можно отказаться от этого правила, если необходима совместимость с версиями python младше 2.0.

Пользуйтесь ”.startswith() и ”.endswith() вместо обработки частей строк (string slicing) для проверки суффиксов или префиксов. startswith() и endswith() выглядят чище и порождают меньше ошибок. Например:

можно:

Copy Source | Copy HTML

1. if foo.startswith('bar'):

нельзя:

Copy Source | Copy HTML

1. if foo[:3] == 'bar':

Исключением является случай, когда вам нужна совместимость с python 1.5.2.

Сравнение типов объектов нужно делать с помощью isinstance(), а не прямым сравнением типов:

можно:

Copy Source | Copy HTML

1. if isinstance(obj, int):

нельзя:

Copy Source | Copy HTML

1. if type(obj) is type(1):

Когда вы проверяете, является ли объект строкой, обратите внимание на то, что строка может быть unicode-строкой. В python 2.3 у str и unicode есть общий базовый класс, поэтому пишите вот так:

Copy Source | Copy HTML

1. if isinstance(obj, basestring):

В python 2.2 в модуле types для этой цели определен тип StringTypes:

Copy Source | Copy HTML

1. from types import StringTypes
2. if isinstance(obj, StringTypes):

В python 2.0 и 2.1 нужно писать:

Copy Source | Copy HTML

1. from types import StringType, UnicodeType
2. if isinstance(obj, StringType) or \
3. isinstance(obj, UnicodeType) :

Для последовательностей (строк, списков, кортежей) можно использовать тот факт, что пустая последовательность есть false:

правильно:

Copy Source | Copy HTML

1. if not seq:
2. if seq:

неправильно:

Copy Source | Copy HTML

1. if len(seq):
2. if not len(seq):

Не пользуйтесь строковыми константами, которые имеют важные пробелы в конце — они невидимы, а многие редакторы (а теперь и reindent.py) обрезают их.

Не сравнивайте логические типы с True и False с помощью ==:

правильно:

Copy Source | Copy HTML

1. if greeting:

неправильно:

Copy Source | Copy HTML

1. if greeting == True:

А вот так писать совсем плохо:

Copy Source | Copy HTML

1. if greeting is True:

Copyright

Авторы: Guido van Rossum , Barry Warsaw .

Текст собран Андреем Черниным из версии 68852 PEP 8 — «Style Guide for Python Code».

Перевод на русский язык выполнен Дмитрием Бударагиным.

¹ PEP 257, Docstring Conventions, Goodger, van Rossum

Материалы опубликованы с согласием переводчика.
Топик на Хабре

Этот документ описывает соглашение о том, как писать код для языка python, включая стандартную библиотеку, входящую в состав python. Пожалуйста, посмотрите также на сопутствующий PEP (python enhanced proposal — заявки на улучшение языка python), описывающий, какого стиля следует придерживаться при написании кода на C в реализации языка python¹.

Этот документ создан на основе рекомендаций Гуидо ван Россума с добавлениями от Барри. Если где-то возникал конфликт, мы выбирали стиль Гуидо. И, конечно, этот PEP может быть неполным (фактически, он, наверное, никогда не будет закончен).

A Foolish Consistency is the Hobgoblin of Little Minds²

Ключевая идея Гуидо такова: код читается намного больше раз, чем пишется. Собственно, рекоммендации о стиле написания кода направлены на то, чтобы улучшить читбельность кода и сделать его согласованным между большим числом проектов. В идеале, весь код будет написан в едином стиле, и любой сможет легко его прочесть. Как говорится в PEP 20³, «Читабельность имеет значение».

Это руководство о согласованности и единстве. Согласованность с этим руководством очень важна. Согласованность внутри одного проекта еще важнее. А согласованность внутри модуля или функции — самое важное. Но важно помнить, что иногда это руководство неприменимо, и понимать, когда можно отойти от рекоммендаций. Когда вы сомневаетесь, просто посмотрите на другие примеры и решите, какой выглядит лучше.

Две причины, чтобы нарушить правила:
• Когда применение правила сделает код менее читабельным даже для того, кто привык читать код, который следует правилам.
• Чтобы писать в едином стиле с кодом, который уже есть в проекте и который нарушает правила (может быть, в силу исторических причин) — впрочем, это возможность подчистить чужой код.

Внешний вид кода

Отступы

Используйте 4 пробела на один уровень отступа. В старом коде, который вы не хотите трогать, можно продолжить пользоваться 8 пробелами для отступа.

Табуляция или пробелы?

Никогда не смешивайте символы табуляции и пробелы.

Самый распространенный способ отступов — пробелы. На втором месте — отступы только с использованием табуляции. Код, в котором используются и те, и другие типы отступов, должен быть исправлен так, чтобы отступы в нем были расставлены только с помощью пробелов. Когда вы вызываете интерпретатор в командной строке с параметром -t, он выдает предупреждения (warnings) при использовании смешанного стиля в отступах, а запустив интерпретатор с параметром -tt, вы получите в этих местах ошибки (errors). Используйте этии опции!

В новых проектах для отступов мы настоятельно рекомендуем использовать пробелы. К тому же, многие редакторы позволяют легко делать.

Максимальная длина строки

Ограничьте максимальную длину строки 79 символами.

Пока еще существует немало устройств, где длина строки равна 80 символам; к тому же, ограничив ширину окна 80 символами, мы сможем расположить несколько окон рядом друг с другом. Автоматический перенос строк на таких устройствах нарушит форматирование, и код будет труднее понять. Так что, пожалуйста, ограничьте длину строки 79 символами, и 72 символами в случае длинных блоков текста (строки документации или комментарии).

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

Вот несколько примеров:

Copy Source | Copy HTML

1. class Rectangle(Blob):
2.       def __init__(self, width, height,
3.                    color='black', emphasis=None, highlight= 0):
4.           if width ==  0 and height ==  0 and \
5.              color == 'red' and emphasis == 'strong' or \
6.              highlight > 100:
7.               raise ValueError("sorry, you lose")
8.           if width ==  0 and height ==  0 and (color == 'red' or
9.                                              emphasis is None):
10.               raise ValueError("I don't think so -- values are %s, %s" %
11.                                (width, height))
12.           Blob.__init__(self, width, height,
13.                         color, emphasis, highlight)

Пустые строки

Отделяйте функции (верхнего уровня, не функции внутри функций) и определения классов двумя пустыми строчками.

Определения методов внутри класса отделяйте одной пустой строкой.

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

Используйте (без энтузиазма) пустые строки в коде функций, чтобы отделить друг от друга логические части.

Python расценивает символ control+L как незначащий (whitespace), и вы можете использовать его, потому что многие редакторы обрабатывают его как разрыв страницы — таким образом логические части в файле будут на разных страницах.

Кодировки (PEP 263)

Код ядра python всегда должен использовать ASCII или Latin-1 кодировку (также известную как ISO-8859-1). Начиная с версии python 3.0, предпочтительной является кодировка UTF-8 (смотрите PEP 3120).

Files using ASCII (or UTF-8, for Python 3.0) should not have a coding cookie. Используйте Latin-1 (или UTF-8), только если это необходимо, чтобы указать в комментарии или строке документации имя автора, содержащее в себе символ из Latin-1. В противном случае предпочтительнее использовать escape-символы \x, \u или \U для не-ASCII символов в строках.

Начиная с версии python 3.0 в стандартной библиотеке действует следующая политика (смотрите PEP 3131): все идентификаторы обязаны содержать только ASCII символы, и означать английские слова везде, где это возможно (во многих случаях используются сокращения или неанглийские технические термины). Кроме того, строки и комментарии тоже должны содержать лишь ASCII символы. Исключения составляют: (а) test case, тестирующий не-ASCII особенности программы, и (б) имена авторов. Авторы, буквы в именах которых не из латинского алфавита, должны транслитерировать свои имена в латиницу.

Проектам с открытым кодом для широкой аудитории также рекомендуется использовать это соглашение.

Import-секции

Импортирование разных модулей должно быть на разных строчках, например:
правильно:

Copy Source | Copy HTML

1. import os
2. import sys

неправильно:

Copy Source | Copy HTML

1. import os, sys

В то же время, можно писать вот так:

Copy Source | Copy HTML

1. from subprocess import Popen, PIPE

Импортирование всегда нужно делать сразу после комментариев к модулю и строк документации, перед объявлением глобальных переменных и констант.

Группируйте импорты в следующем порядке:
• импорты стандартной библиотеки
• импорты сторонних библиотек
• импорты модулей текущего проекта

Вставляйте пустую строку между каждой группой импортов.

Указывайте спецификации __all__ после импортов.

Относительные импорты крайне не рекомендуются — всегда указывайте абсолютный путь к модулю для всех импортирований. Даже сейчас, когда PEP 328⁴ реализован в версии python 2.5, использовать явные относительные импорты нежелательно, потому что абсолютные импорты лучше переносимы и читабельны.

Когда вы импортируете класс из модуля, вполне можно писать вот так:

Copy Source | Copy HTML

1. from myclass import MyClass from foo.bar.yourclass import YourClass

Если такое написание вызывает конфликт имен, тогда пишите:

Copy Source | Copy HTML

1. import myclass import foo.bar.yourclass

И используйте «myclass.MyClass» и «foo.bar.yourclass.Yourclass».

Пробелы в выражениях и инструкциях

Избегайте использования пробелов в следующих ситуациях:

1. Сразу после или перед скобками (обычными, фигурными и квадратными)
можно:

Copy Source | Copy HTML

1. spam(ham[1], {eggs: 2})

нельзя:

Copy Source | Copy HTML

1. spam( ham[ 1 ], { eggs: 2 } )

2. Сразу перед запятой, точкой с запятой, двоеточием:
можно:

Copy Source | Copy HTML

1. if x == 4: print x, y; x, y = y, x

нельзя

Copy Source | Copy HTML

1. if x == 4 : print x , y ; x , y = y , x

3. Сразу перед открывающей скобкой, после которой начинается список аргументов при вызове функции:
можно:

Copy Source | Copy HTML

1. spam(1)

нельзя:

Copy Source | Copy HTML

1. spam (1)

4. Сразу перед открывающей скобкой, после которой следует индекс или срез:
можно:

Copy Source | Copy HTML

1. dict['key'] = list[index]

нельзя:

Copy Source | Copy HTML

1. dict ['key'] = list [index]

5. Использование более одного пробела вокруг оператора присваивания (или любого другого) для того, чтобы выровнять его с другим таким же оператором на соседней строке:
можно:

Copy Source | Copy HTML

1. x = 1
2. y = 2
3. long_variable = 3

нельзя:

Copy Source | Copy HTML

1. x = 1
2. y = 2
3. long_variable = 3

Прочие рекомендации:

1. Вседа окружайте эти бинарные операторы одним пробелом с каждой стороны: присваивание (=, +=, -= и прочие), сравнения (==, <, >, !=, <>, <=, >=, in, not in, is, is not), логические операторы (and, or, not).

2. Ставьте пробелы вокруг арифметических операций.
можно:

Copy Source | Copy HTML

1. i = i + 1
2. submitted += 1
3. x = x * 2 - 1
4. hypot2 = x * x + y * y
5. c = (a + b) * (a - b)

нельзя:

Copy Source | Copy HTML

1. i=i+1
2. submitted +=1
3. x = x*2 - 1
4. hypot2 = x*x + y*y
5. c = (a+b) * (a-b)

3. Не используйте пробелы для отделения знака =, когда он употребляется для обозначения аргумента-ключа (keyword argument) или значения параметра по умолчанию.
можно:

Copy Source | Copy HTML

1. def complex(real, imag= 0. 0):
2.     return magic(r=real, i=imag)

нельзя:

Copy Source | Copy HTML

1. def complex(real, imag =  0. 0):
2.     return magic(r = real, i = imag)

4. Не используйте составные инструкции (несколько команд в одной строке).
можно:

Copy Source | Copy HTML

1. if foo == 'blah':
2.     do_blah_thing()
3. do_one()
4. do_two()
5. do_three()

нельзя:

Copy Source | Copy HTML

1. if foo == 'blah': do_blah_thing()
2. do_one(); do_two(); do_three()

5. Иногда можно писать тело циклов while, for или ветку if в той же строке, если команда короткая, но если команд несколько, никогда так не пишите.
можно:

Copy Source | Copy HTML

1. if foo == 'blah': do_blah_thing()
2. for x in lst: total += x
3. while t < 10: t = delay()

нельзя:

Copy Source | Copy HTML

1. if foo == 'blah': do_blah_thing()
2. else: do_non_blah_thing()
3. try: something()
4. finally: cleanup()
5. do_one(); do_two(); do_three(long, argument,
6.                              list, like, this)
7. if foo == 'blah': one(); two(); three()

¹ PEP 7, Style Guide for C Code, van Rossum
² «A foolish consistency is the hobgoblin of little minds, adored by little statesman and philosophers and divines.  With consistency a great soul has simply nothing to do» — цитата Ральфа Валдо Эмерсона, известного американского писателя.
³ PEP 20, The Zen of Python
⁴ PEP 328, Imports: Multi-Line and Absolute/Relative

Материалы опубликованы с согласием переводчика.
Топик на Хабре

С активным развитием веб-приложений начался буйный рост технологий облачных вычислений. Об этом я уже писал в своём предыдущем посте, где сделал краткий обзор основных видов облаков. Теперь же попробую быстро проскочить по cloud-сервисам, предоставляемым ключевыми вендорами на рынке.

Первым серьёзным и доступным cloud-хостингом явился Amazon Elastic Compute Cloud (Amazon EC2). Сейчас Amazon является одним из наиболее крупных игроков на рынке облачных вычислений. Множество компаний пользуется облачным сервисом именно от Amazon. Насколько мне известно, даже известный сервис для микроблоггинга Twitter решил проблему масштабирования с Amazon EC2. Услуги, связанные с облачными вычислениями, Amazon предоставляет под единым брендом Web Services. Кроме Amazon EC2 туда входят:

Simple DB – сервис, предоставляющий ядро функций базы данных, а именно индексирование данных и выполнение запросов;

Simple Storage Service или Amazon S3 – сервис для хранения и получения больших объёмов данных и REST-API для доступа;

CloudFront – распределённая сеть хранения и доставки контента;

Simple Queue Service – система очередей сообщений, в которой разработчики могут перемещать данные между своими приложениями, выполняющими разные задачи, с высокой надёжностью;

Elastic MapReduce – сервис для обработки и проведения анализа больших объёмов данных на основе Apache Hadoop.

Отмечу, что весь этот слоёный пирог облачных сервисов далеко не бесплатен и пользователю нужно платить за все используемые ресурсы. Если брать в расчет только непосредственно Amazon EC2 с минимальными аппаратными характеристиками, то это выльется около 80$ в месяц, хотя по сравнению с некоторыми VPS это не так уж и дорого

Наиболее известной же системой для облачных вычислений, бесспорно, является Google AppEngine, представляющую собой хостинг для веб-аппликаций, ограниченный конкретным API и системными сервисами. Приложения, разворачиваемые на базе Google AppEngine могут быть написаны на двух языках: Python и Java. На данный момент сервис ещё находится в стадии бета-тестирования, поэтому любой девелопер может бесплатно пользоваться им, но только если посещаемость не превысит 5 миллионов хитов в месяц. В рамках бесплатного аккаунта предоставляется 500 мегабайт дискового пространства. Среда исполнения использует Python 2.5.2, что не может ни огорчать, так как я всеми своими принципами выступаю за Python 3 и его скорейшее становление на ноги.

Очень похожий сервис для облачных вычислений представила Microsoft. Платформа носит название Azure. В её основе лежит специальная версия Windows Server 2008, остальные сервисы, которые доступны девелоперу, базируются на уже известных технологиях, таких как: .NET Runtime, SQL Service, Live, SharePoint, Dynamics CRM. Сама система предназначена для построения корпоративных приложений. Так же как и AppEngine, Microsoft Azure ещё находится в стадии тестирования.

Evans Data Corp не так давно проводила опрос среди разработчиков на тему, продукты каких компаний они используют или планируют использовать для использования cloud computing. На рисунке в системе координат расположены поставщики в соответствии с тем, как их воспринимают разработчики. Ось абсцисс показывает, насколько высоко разработчики оценивают способность вендора реализовать стратегию облачных вычислений. По оси ординат расположены оценки полноты решений. Круговые маркеры демонстрируют степень освоения решений вендора заказчиками, при этом внутренний красный круг показывает текущее количество внедрений, а внешняя черная окружность — количество внедрений, планируемых в ближайшие 12 мес.

Сразу бросается в глаза преимущество, имеющееся у Amazon и Google. По мнению опрошенных, они обладают самым высоким потенциалом для реализации технологии облачных вычислений.

«Облачные вычисления». Первое, что встаёт перед глазами у человека незнакомого с этим термином, так это компьютер, зависший в облаках. На самом деле облачные вычисления не имеют ничего общего с привычными нам с вами, взвешенными в атмосфере продуктами конденсации водяного пара. На самом деле, под облачными вычислениями следует понимать технологию обработки данных, в которой динамически масштабируемые ресурсы предоставляются пользователю в качестве интернет-сервиса. Пользователь не может управлять программным обеспечением в облаке, но имеет доступ к обрабатываемым данным.

Сам термин «облачные вычисления» (англ. Cloud computing) появился ещё в 60-е годы прошлого столетия, но популярность обрёл только в настоящее время в связи с бурным развитием всемирной паутины.

Пользователи могут получать из облака столько системных ресурсов, сколько им необходимо (и конечно столько, сколько могут приобрести). Что для этого используется, и какая внутри инфраструктура, пользователь не может видеть, так как всё это скрывается за стенами виртуальных машин, которые могут работать на огромном количестве серверов и в разных дата-центрах.

Теперь попробуем вкратце разобраться, какие плюсы мы будем иметь, использую облачные вычисления. Во-первых, это очень надёжная инфраструктура с необходимой нам производительностью. Во-вторых, не составит проблемы заниматься масштабированием предоставляемых ресурсов. В-третьих, не нужно оплачивать дикие счета, за использование ресурсов, которыми ты не всегда будешь пользоваться, так как оплата прямо пропорционально зависит от масштабов облака. Особенно это хорошо, когда планируется провести волновую нагрузку на проект.

Так как облачные вычисления являются одной из передовых технологий, на данный момент имеется множество сервисов для работы с ними. Для удобства их обозначения используют специальную аббревиатуру aaS (“as a Service”). Рассмотрим в общих чертах каждый из этих сервисов.

SaaS (Software as a service; программное обеспечение как услуга) – сервис, в котором пользователю предлагают использование определённого программного обеспечения по подписке через интернет. Одним из самых ярких примеров здесь будет Google Docs. К тому же доступ к нему абсолютно бесплатен.

PaaS (Platform as a service; платформа как услуга) – сервис для разработки и поддержки приложений, в котором интегрированы различные необходимые библиотеки и программы. PaaS, в отличие от SaaS ориентирован не на конечного пользователя, а на разработчика. Здесь же самым известным примером является Google AppEngine, предоставляющая хостинг для веб-приложений с возможностью покупать дополнительные вычислительные ресурсы.

IaaS (Infrastructure as a service; инфраструктура как услуга) – предоставление пользователю аппаратных ресурсов, которые обычно объединены в единое целое с помощью различных технологий виртуализации, которые используются вместо обычного хостинга. Поэтому, когда речь идёт о конкретном железе, понимаются некоторые абстрактные сущности, которые аналогичны обычным аппаратным. IaaS являются различные, привычные пользователю VPS-площадки или просто онлайн хранилища с возможностью автомасштабирования.

СaaS (Communication as a service; связь, как услуга) – предоставление различных услуг связи (таких как IP-телефония, электронная почта, IM и др.) в виде облака.

В среду на этой неделе один из руководителей Агентства Национальной Безопасности США заявил, что АНБ участвовало в разработке операционной системы Windows 7. Также вместе в ними принимали участие в разработке специалисты Министерства обороны. Вместе они «использовали свой уникальный опыт и практические знания в области системных угроз и уязвимостей, чтобы улучшить безопасность операционной системы».

Сразу напрашивается мысль, что Microsoft совместно с АНБ встроили какой-нибудь бэкдор в операционную систему. Мне, как человеку, выступающему категорически против вешания штрих-кодов на людях, эта тема добавила ещё каплю в море моей маниакальности по вопросам безопасности. Это уже не первый случай, когда спецслужбы плотно сотрудничают с Microsoft над созданием очередной операционной системы: Windows Vista, Windows XP и Windows 2000 тоже разрабатывались с учётом рекомендаций АНБ. Хотя все эти годы Microsoft и опровергает слухи о бэкдорах, на уровне подсознания сомнения проходить не спешат.

В четверг официальный представить Microsoft заявил, что Microsoft никогда не внедряла и не будет внедрять «бэкдоры» в Windows. Он заверил, что участие АНБ в создании Windows 7 ограничилось исключительно работой над Security Compliance Management Toolkit, который вышел в конце октября, вскоре после официального релиза операционной системы.

Однако проблема с АНБ действительно есть. Дело в том, что это агентство совмещает в себе две функции: сигнальная разведка (то есть слежка) и компьютерная безопасность. Вполне логично, что в каких-то вопросах эти две сферы будут пересекаться.

Сейчас АНБ пытается наладить сотрудничество с Apple, Sun и Red Hat в области безопасности операционных систем (об этом тоже было сказано в выступлении перед комитетом по терроризму). Чем не повод для новых опасений?

Логотип интерпретатора Python

Разработчики Python официально приняли мораторий, запрещающий изменение синтаксиса языка Python версии 3.1 на срок до 26 июня 2011 года. Целью моратория является задержка развития языка, чтобы сторонние проекты для Python догнали в своём развитии Python третьей ветки. Отставание вызвано тем, что вторая и третья ветки являются несовместимыми, и поэтому многие альтернативные проекты Python, такие как Jython,IronPython, Unladen Swallow, продолжают базироваться на Python 2.7. На время заморозки развития усилия разработчиков будут направлены на портирование библиотек для старой ветки языка на Python 3, написании утилит и документации.
Это всё меня лично очень радует, и я с радостью проголосовал бы за продление моратория, если бы такая возможность представилась, чтобы большинство весомых проектов на Python, такие как Django, PyGTK, wxPython и другие, успели перелезть на третью ветку языка, и больше не было бы болезненных проблем совместимости. Остаётся надеяться, что это случится как можно скорее.

Язык программирования Go

Неожиданно так для многих из нас Google анонсировал новый язык программирования, в котором разработчики хотят объединить мощность C++ и лаконичность Python. Поэтому, по словам девелоперов, разработка на Go так же быстра, как и разработка на Python, и так же мощна, как на C++ и Java. Пока язык представляет собой эксперимент, который ставит Google, так как сам Go ещё не достаточно зрелый для серьёзных проектов.

Вот «хелловорд», представленный на главной странице официального сайта Go:

package main

import “fmt”

func main() {
fmt.Printf(”Hello, 世界\n”)
}

Эти начинания, конечно же, хороши. Но вот только возник один небольшой казус. Вот дискуссия , в которой Francis McCabe просит компанию Google переименовать язык, так как сам уже в течение десяти лет работает над языком Go! Дискуссия уже представляет собой длинный манускрипт, на которую Google ещё никак не прореагировал. Название, выдвигаемой людьми для языка Google звучит как Issue 9. Так что остаётся очень актуальным вопрос, уступит ли Google, хотя лично я в этом очень сомневаюсь…

Естественно, читая такой код, радужных чувств не испытываешь. Поэтому хочется отметить, что выбор какого-то определённого стиля кодирования является неотъемлемой частью программирования как такового. Программисты, не делающие этого совершенно недальновидны, так как их код в дальнейшем могут читать другие люди. Или даже сами они через некоторое время пожалеют об этом, когда им придется разбирать собственный код. Именно поэтому выбор стиля довольно важный фактор.
Но если уж вы решили придерживаться какого-то определённого стиля, то так же не стоит писать, используя только его. Например, вам попался в руки проект, где программист, разрабатывавший его, придерживался несколько других стандартов. В этом случае, лучше всего рефакторить проект, используя стиль его первичного автора, дабы не возникло путаницы и противоречий, так как после вас этот проект может достаться третьему человеку, и так далее.
Теперь перейду непосредственно к описанию элементов стилей кодирования.

1. Табуляция

Существует два вида табуляции: мягкая и жёсткая. Жёсткая табуляция – использование символа табуляции для получения отступа. Мягкая табуляция – использования необходимого количества пробелов для получения отступа. Лучше всего придерживаться мягкой табуляции в связи с тем, что у каждого редактора свои настройки табуляции. Обычно используют 4 пробела там, где необходим отступ, так как это делает код наиболее читабельным.

2. Управляющие конструкции

Использование фигурных скобок в управляющих конструкциях обычно подразделяется на 3 стиля:

2.1 BSD-стиль:

Copy Source | Copy HTML

1. if (<условие>)
2. {
3.   <оператор>
4. }

2.2 GNU-стиль:

Copy Source | Copy HTML

1. if (<условие>)
2.   {
3.     <оператор>
4.   }

2.3 K&R-стиль:

Copy Source | Copy HTML

1. if (<условие>) {
2.   <оператор>
3. }

В условных операторах и циклах я использую K&R-стиль, в объявлениях функций и классов BSD. Это наиболее удобно, на мой взгляд.

3. Пробелы

В вызовах функций лучше не ставить пробел после имени функции, но разделять им список переменных. Например:

Copy Source | Copy HTML

1. function connect($arg1, $arg2)
2. {
3.   //тело функции
4. }

4. Именования

4.1 Константы и глобальные переменные

Имена констант и глобальных переменных лучше всего вводить в верхнем регистре, так как это позволит с лёгкостью идентифицировать их как глобальные:

Copy Source | Copy HTML

1. $TEMPLATE_DIR = `/template/default/ `;

4.2 Временные переменные и функции

Имена временным переменным и функциям следует давать короткие и лаконичные с подчёркиванием для разделения слов. Например:

Copy Source | Copy HTML

1. $count
2. num_rows()

4.3 Классы

Первую букву в имени класса следует набирать в верхнем регистре. Символы подчеркивания должны использоваться только для имитации вложенных пространств имен. Имена классов из нескольких слов должны использоваться слитно с первой буквой слова в верхнем регистре.

Copy Source | Copy HTML

1. class XML_RSS {}
2. class Text_PrettyPrinter {}

4.4 Методы и свойства

Если имя метода или свойства состоит из одного слова, то его нужно полностью набирать в нижнем регистре. Если же имя метода или свойства состоит из нескольких слов, то первую букву слов, начиная со второго, следует набирать в верхнем регистре, тогда как остальные – в нижнем.

Copy Source | Copy HTML

1. public $number
2. public $NumberOfStudent

Приватные методы и свойства должны быть префиксированы знаком подчеркивания.

Copy Source | Copy HTML

1. private function _sort()

Это основные элементы стиля кодирования, к которым следует обратить особое внимание для предотвращения запутанности вашего кода.