Можно ли использовать несколько соглашений об именах?

Question

Мне учили, что, хотя и camelCase и under_scores являются допустимыми именами переменных. Мне нужно быть последовательным в моем подходе.

Насколько последовательна последовательность? Допустимо ли это и Pythonic использовать оба при определенных обстоятельствах?

E.g. могу ли я использовать camelCase для переменных в моем основном коде и under_scores для тех, кто в моих функциях? или, возможно, один для переменных, которые имеют ответы, полученные из моих собственных функций, а другие - для других функций?

Оба эти могут быть выполнены таким образом, чтобы пользователям было легко понять их и следовать основным системным правилам, только ли это позволяет использовать оба варианта, или я ожидаю, что вы последуете только одному соглашению об именах?

Пример использования under_scores для переменных, ответ, полученный из определенной функции пользователя и CamelCase для других variales.

# My function. 
def reverse(variableCalledA): 
    variableNamedB = reverseVariableA(variableCalledA) # {= 235}. 
    return variableNamedB 

# Main code. 
variableCalledA = 532 
**reversed_variable_called_b** = reverse(variableCalledA) 
answer = variableCalledA - **reversed_variable_called_b** 
print(answer) 

P.S. Если это уместно, это что-то, о чем я должен упомянуть в комментарии, чтобы другие пользователи знали, что нужно его искать?

P.S.S. Пожалуйста, предупредите меня о любых способах обновления/улучшения моего вопроса и будущих вопросов.

Answer 1

Соглашения об именах предназначены для повышения четкости кода и облегчения работы многих разработчиков на одной и той же базе кода.

Как таковой, ответ на ваш вопрос действительно зависит от ситуации. Если вы работаете в профессиональной среде, вы должны придерживаться любого соглашения об именах, которое использует компания. Если нет существующего соглашения об именах, вы должны нажать на него. Как правило, любой новый проект Python должен придерживаться PEP8 style guide, если нет веских оснований для этого (например: годы устаревшего кода, в котором используется другой стиль).

Независимо от того, работаете ли вы над новым проектом или устаревшим кодом, мое личное мнение заключается в том, что смешивание camelCase и under_scores - это не очень хорошая идея. Пример, который вы предоставили, звучит разумно, но это не соглашение, о котором другие разработчики знали бы, если только это не было объяснено в комментариях.

Answer 2

Для быть последовательным вы можете использовать under_scores вместо верблюжьего как первое является более удобным для чтения, чем последний. Вы можете увидеть одно из сообщений об именовании - соглашение here.

Допустимо ли это и Pythonic использовать при определенных обстоятельствах?

Да, это приемлемо и питонично использовать как при определенных обстоятельствах. Вы можете проверить PEP-8 guid для разработчиков.

Для имен функций

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

Некоторые обстоятельства включают в себя обратную совместимость

СловаРазделенныеРегистром допускается только в условиях, когда вот уже преобладающий стиль (например, threading.py), чтобы сохранить обратную совместимость.

Для имен класса

Имена классов должны обычно использовать конвенцию CapWords.

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

В заключение, если вы строите поверх некоторой библиотеки, лучше пойти с библиотечным стилем. Для питоновых соглашений PEP-8 есть руководство для разработчиков.

Answer 3

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

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

PEP8 имеет смысл. CapWords для классов, UPPER_CASE для констант и names_with_undescores для всего остального.

Я добавил чрезмерные комментарии в свой код. Даже с переменными, полностью прописанными, комментарии все же помогают.

Для таких людей, как я, с помощью CRS (Can not Remember Shit) длинные имена переменных помогают мне помнить, что переменная держится, когда я возвращаюсь и смотрю на код.