Как делают Вас PEP, с 8 именами класс, имя которого является акронимом?
Я пытаюсь придерживаться руководства по стилю для кода Python (также известный как PEP 8). Соответственно, предпочтительный способ назвать класс использует CamelCase:
Почти без исключения, имена классов используют конвенцию CapWords. Классы для внутреннего пользования имеют начальный символ подчеркивания, кроме того.
Как я могу согласовываться с PEP 8, если мое имя класса формируется двумя акронимами (который на надлежащем английском языке должен быть использован для своей выгоды). Например, если бы моим именем класса было 'НАСА JPL', что Вы назвали бы им?:
class NASAJPL(): # 1
class NASA_JPL(): # 2
class NasaJpl(): # 3
Я использую № 1, но это выглядит странным; № 3 выглядит странным также, и № 2, кажется, нарушает PEP 8.
8 ответов
PEP-8 действительно покрывает это (по крайней мере, частично):
Примечание: При использовании аббревиатур в CapWords, пишите все буквы аббревиатуры заглавными. Таким образом,
HTTPServerErrorлучше, чемHttpServerError.
Что, по моему мнению, означает, что NASAJPL() является рекомендуемым именем согласно PEP-8.
Лично я нахожу NasaJpl() самым легким для сканирования, поскольку заглавные буквы легко обозначают границы слов и придают имени характерную форму.
Как отмечали другие, NASAJPL, вероятно, является одобренной формой PEP-8.
Однако, чтобы быть наоборот, я бы, вероятно, использовал NasaJPL. Потому что, если вы ее читаете, вы произносите «НАСА» как одно слово, а «Лаборатория реактивного движения» произносите по буквам.
Вы можете привести аргумент, что это согласуется с PEP-8, поскольку «НАСА» является аббревиатурой, а «JPL» - аббревиатурой (или инициализмом, если вы хотите получить педантичный ).
Я обычно использую №3. Сначала это выглядит странно, но ты (вроде) привыкаешь. Я пошел по этому пути после того, как слишком долго мучился с набором аббревиатур, например, NPCAIXMLParser был одним из них. Я решил, что NpcAiXmlParser намного легче читать, и с тех пор делаю это, хотя видеть эти вещи в нижнем регистре иногда все еще выглядит странно.
В терминах «стандартов» я склонен думать об этих объектах как о «словах» и поэтому пишу их с большой буквы, как любое другое слово. Например. если бы у меня была локальная переменная, представляющая некоторого NPC (неигрового персонажа), я бы назвал ее «npc», а не «nPC».
Что касается PEP-8, я не согласен с этим утверждением; Я считаю, что последнее написание слова предпочтительнее.
Примечание: при использовании сокращений в Заглавные слова, все буквы должны быть заглавными аббревиатуры. Таким образом HTTPServerError лучше, чем HttpServerError.
Номер 1 мне слишком сложно читать - нет никакого способа сказать, что это два акронима.
Номер 2 нарушает PEP8, но выглядит нормально. Помните: «Глупая последовательность - хобгоблин маленьких умов» :)
Мне больше всего нравится номер 3, но я много занимаюсь программированием на C # - это то, как вы должны делать это на C #.
#1 в данном конкретном случае выглядит нормально (если это действительно аббревиатура). Из любопытства, что это означает (и что именно является экземпляром класса, может быть модуль будет более подходящим делителем)?
class NASAJPL:
EDIT: когда вы объединяете две аббревиатуры, есть шанс, что вы хотите разделить функциональность на модули (вы никогда не знаете, когда добавите следующую функцию в вашу программу):
from NASA import JPL
from NASA import ARC
Я также работаю в среде, где много аббревиатур. Я предпочитаю форму №3, потому что, несмотря на то, что в ней записываются части акронима в нижнем регистре, она четко очерчивает части имени. Это также позволяет избежать путаницы, когда часть имени является аббревиатурой, а часть - словом.
Вы все делаете правильно.
Если предложение ChristophD разделить его на иерархию модулей не является жизнеспособным вариантом, то я бы предложил вашу форму №2 ( class NASA_JPL () : ) самый разборчивый, блин ПЕП-8.
Нет, правда ...
Тем не менее ... Я не думаю, что PEP-8 должен быть проклят, чтобы вы использовали эту опцию и по-прежнему придерживались его основных принципов. Как вы указываете в своем исходном вопросе, первое предложение директивы «Имена классов CamelCase» начинается так:
Почти все без исключения, [...]
Утверждение «фундаментальных принципов» PEP-8, на которое Дэн намекает со строкой «Глупая последовательность [...]» , провозглашает читаемость и понятность первоочередными целями. рекомендаций PEP-8. PEP-8 - это набор устоявшихся успешных моделей, служащих этим целям.
Эмерсон о применении PEP-8 к реальности ...
По сути, любая система имеет аспекты, которые обязательно несовместимы с характером целого. Когда система хорошо и последовательно использует рекомендации руководства по стилю, любые несоответствия будут сознательными ответами на необходимость . (Я считаю, что поддержание разборчивости угловых дел является необходимостью.)
При таком подходе эти несоответствия, что противоречит интуиции, усиливают единство целого, а не разрушают его.
PEP-8 говорит об этом более кратко (и, следовательно, более полезно :)):
Но самое главное: знайте, когда нужно быть непоследовательным - иногда стиль руководство просто не применимо. В случае сомнений используйте здравый смысл. Смотреть на других примерах и решите, что выглядит лучше всего. И не стесняйтесь спрашивать!
Две веские причины нарушить конкретное правило:
Применение правила сделает код менее читаемым, даже для того, кто привык читать код, который следует правилам.
Чтобы соответствовать окружающему коду, который также его нарушает (возможно, по историческим причинам) - хотя это также возможность навести порядок в чужом беспорядке (в истинном стиле XP).
Это зависит от аббревиатуры. Другой вариант - class NASAJpl (): , из-за чего создается впечатление, что «NASA» является основной частью, а «JPL» - подчиненной частью.