Подтвердить что ты не робот

Как вы PEP 8 называете класс, чье имя является аббревиатурой?

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

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

Как я могу быть совместим с PEP 8, если мое имя класса образовано двумя аббревиатурами (которые на надлежащем английском должны быть заглавные). Например, если мое имя класса было "NASA JPL", что бы вы назвали его?

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

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

Ответ 2

Как отмечали другие, NASAJPL, вероятно, одобренная PEP-8 форма.

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

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

Ответ 3

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

class NASAJPL:

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

from NASA import JPL
from NASA import ARC

Ответ 4

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

Ответ 5

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

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

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

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

Ответ 6

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

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

Нет, действительно...

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

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

"Основополагающие принципы" PEP-8, поскольку Dan ссылается на "Неверное согласование [...]" , декларирует четкость и понятность основных целей рекомендаций PEP-8. PEP-8 - это совокупность установленных, успешных моделей в обслуживании этих целей.

Emerson о применении PEP-8 к реальности...

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

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

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

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

Две хорошие причины для нарушения определенного правила:

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

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

Ответ 7

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

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

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

Ответ 8

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