Как вы PEP 8-имя класса, имя которого является аббревиатурой?

Question

Я стараюсь придерживаться руководства по стилю для кода Python (также известного как PEP 8 ). Соответственно, предпочтительным способом присвоения имени классу является использование CamelCase:

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

Как я могу соответствовать PEP 8, если имя моего класса образовано двумя аббревиатурами (которые на надлежащем английском языке должны быть написаны заглавными буквами) Например, если бы мое имя класса было «НАСА JPL», как бы вы назвали его?:

class NASAJPL():  # 1
class NASA_JPL(): # 2
class NasaJpl():  # 3

Я использую # 1, но это выглядит странно; # 3 тоже выглядит странно, а # 2, кажется, нарушает PEP 8.

Answer 1

PEP-8 покрывает это (хотя бы частично):

Примечание. При использовании сокращений в CapWords используйте заглавные буквы заглавных букв. Таким образом, HTTPServerError лучше, чем HttpServerError.

То, что я хотел бы прочитать, означает, что NASAJPL() является рекомендуемым именем согласно PEP-8.

Лично я бы нашел NasaJpl() наиболее простым для сканирования , поскольку буквы в верхнем регистре легко обозначают границы слов и придают имени отличительную форму.

Answer 2

Как уже отмечалось, NASAJPL - это, вероятно, одобренная PEP-8 форма.

Просто чтобы быть противоположным, я бы, вероятно, использовал NasaJPL. Потому что, если вы читаете это, вы произносите «НАСА» как одно слово, тогда как «JPL» вы произносите.

Вы можете привести аргумент, что это согласуется с PEP-8, поскольку «НАСА» является аббревиатурой, а «JPL» является аббревиатурой (или инициализмом, если вы хотите получить педантичный ).

Answer 3

#1 в данном конкретном случае выглядит хорошо для меня (если это действительно аббревиатура). Из любопытства, что это означает (и что именно является экземпляром класса, может быть, module будет более подходящим делителем)?

class NASAJPL:

РЕДАКТИРОВАТЬ : когда вы комбинируете две аббревиатуры, есть вероятность, что вы захотите разделить функциональность на модули (вы никогда не узнаете, когда добавляете эту следующую функцию в вашу программу):

from NASA import JPL
from NASA import ARC

Answer 4

Я также работаю в акроним-тяжелой среде. Я предпочитаю форму № 3, потому что, хотя она и является частью аббревиатуры в нижнем регистре, она четко очерчивает части имени. Это также позволяет избежать путаницы, когда часть имени является аббревиатурой, а часть - словом.

Answer 5

Вы делаете это правильно.

Если ChristophD разделить его на иерархию модулей предложение не является приемлемым вариантом, то я бы предложил, чтобы ваша форма № 2 (class NASA_JPL ():) была наиболее разборчиво, PEP-8 будь проклят.

Нет, правда ...

Тем не менее ... Я не думаю, что PEP-8 должен быть проклят, чтобы вы могли использовать эту опцию и по-прежнему придерживаться ее основных принципов. Как вы сами указали в своем первоначальном вопросе, первое предложение руководства «Названия классов CamelCase» начинается:

Почти без исключения, [...]

Заявление PEP-8 об «фундаментальных принципах», как Дан ссылается на строку «Глупая последовательность [...]» , объявляет ясность и понятность основными целями Рекомендации ПКП-8. ПКП-8 представляет собой набор устоявшихся, успешных моделей в служении этим целям.

Эмерсон о применении ПКП-8 к реальности ...

По сути, любая система имеет аспекты, которые обязательно несовместимы с характером целого. Когда система хорошо и последовательно использует рекомендации руководства по стилю, любые несоответствия будут сознательными реакциями на необходимостью . (Я считаю, что необходимо поддерживать разборчивость угловых дел.)

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

PEP-8 утверждает это более кратко (и, следовательно, более полезно :)):

Но самое главное: знать, когда нужно быть непоследовательным - иногда стиль Гид просто не применяется. В случае сомнений используйте свое лучшее суждение. Посмотрите на других примерах и решить, что выглядит лучше. И не стесняйтесь спрашивать!

Две веские причины нарушить определенное правило:

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

2. Быть совместимым с окружающим кодом, который также нарушает его (возможно, по историческим причинам) - хотя это также возможность убрать чужой беспорядок (в истинном стиле XP).

Answer 6

Я склонен использовать # 3. Поначалу это выглядит странно, но вы (вроде) привыкли к этому. Я пошел по этому пути после того, как слишком долго страдал под акронимами, соединенными вместе, например. NPCAIXMLParser был один. Я решил, что NpcAiXmlParser было намного легче читать, и делал это до сих пор, хотя вид этих вещей в нижнем регистре все еще иногда выглядит странно.

В терминах «стандартов» я склонен думать об этих сущностях как о «словах» и, таким образом, использовать их как заглавные, как и любое другое слово. Например. если бы у меня была локальная переменная, представляющая какого-то NPC (неигрового персонажа), я бы назвал ее npc, а не nPC.

Что касается ПКП-8, я не согласен с этим утверждением; Я считаю, что последнее написание слова предпочтительнее.

Примечание: при использовании сокращений в CapWords, заглавные буквы аббревиатуры. таким образом HTTPServerError лучше чем HttpServerError.

Answer 7

Номер 1 слишком сложен для чтения - невозможно сказать, что это две аббревиатуры.

Номер 2 нарушает PEP8, но выглядит хорошо. Помните: «Глупая последовательность - это хобгоблин маленьких умов»:)

Мне нравится номер 3 лучше всего, но я много программирую на C # - именно так вы должны делать это на C #.

Answer 8

Это зависит от аббревиатуры. Другой вариант будет class NASAJpl():, из-за чего создается впечатление, что «НАСА» является основной частью, а «JPL» является подчиненной частью.