Какие существуют соглашения по именованию переменных функций

Обновлено: 17.05.2024

Существует ли соглашение об именовании или, может быть, какое-то руководство о том, как называть параметры функции?

С незапамятных времен я делаю это так:

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

(Это PHP, но он должен быть применим к большинству языков программирования)

Есть ли одна главная причина против этого?

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

9 answers

ваши функции/методы хорошо написаны и коротки (как и должно быть)
имена переменных достаточно описательны

Эта практика не нужна.

Если вам это нужно, это означает, что написанный код недостаточно читаем (функции/методы слишком длинные), загадочные имена переменных/функций, плохие методы OO, ярлыки, долги кода и т.д.:)

Таким образом, это будет сигналом о том, что код необходимо переработать/улучшить.

Я думаю, что было бы оправдано следовать совету полного кода относительно именования - чего угодно - вся глава 11 посвящена правильному именованию переменных):

Не называйте это j, k, i, m, n (если только это не просто итерация) или "заполнитель" или "тест". Когда "тест" работает, я часто не трачу время на переименование переменной, где бы она ни была указана.

Назовите это описательным именем, которое отделено от функции кода, т.Е. "Employeecomments", а не "xmlemp_comment_file", потому что большая часть этой информации (XML, внешний файл) может измениться, но программа, работающая с "Комментариями сотрудников", не будет

Держите его как широким и удобочитаемым для человека, насколько это возможно, чтобы вы кодировали на английском (или своем языке), а не на $j=$k/sqrt($pi); или что-то столь же непонятное.

Что касается конкретных параметров, я никогда не использовал обозначение P. Мне нравится эта идея, но если бы вы назвали их правильно, разве не было бы ясно, что они были ли параметры для функции?

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

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

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

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

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

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

Я не согласен с предыдущим предложением о том, что вы должны просто сделать свой код более понятным. Наличие четкого кода не устраняет необходимость в четких соглашениях об именовании.

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

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

Итак, это больше о стиле. Хорошее именование важнее хороших префиксов. Для схем: выберите одну, придерживайтесь ее. Это поможет плохому разработчику технического обслуживания. Да, это те люди, которые обычно также предпочитают <> вокруг отдельных блоков операторов и так далее, но это помогает.

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

локальные переменные: index
переменные-члены класса: m_index
статические переменные класса: ClassIndex
глобальные переменные: INDEX

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

Вы можете следовать Стандартам кодирования PHP или Стандарту кодирования php, который предлагается внести в основной php.

Итак, посмотрев на все это, я решил пойти с:

ClassName methodName propertyName function_name (meant for global functions) $variable_name

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

И КАКИЕ БЫ СОГЛАШЕНИЯ ОБ ИМЕНОВАНИИ ВЫ НИ ВЫБРАЛИ, ОНИ ДОЛЖНЫ БЫТЬ СОГЛАСОВАНЫ ВО ВСЕМ ВАШЕМ КОДЕ - это не может быть достаточно повторено:)

Лично я использую следующее:
первая часть переменной предназначена для того, что она есть
вторая часть предназначена для того, что она делает/используется для
и для переменных, необходимых вне функции, класса и т.д. третья часть предназначена для функции, класса и т.д. это происходит от

Пример:
Я хочу назвать переменную для миниатюры видео на главной странице:
поэтому я начнем с того, что это (lower_case) - эскиз
затем я добавляю на то, что она используется для (первая буква upper_case) - видео -
и так как мне нужно это на главной странице вне функции я закончить с функцией взялось (разделяется under_score) - getVideoAll

Даешь мне $thumbnailvideo_getvideoall

Таким образом, независимо от того, где я смотрю на переменную в любой части кода (HTML, PHP и т.д.) Я знаю.
ах, это миниатюра для видео, которое я пытаюсь показать, и если это по какой-то причине не работает, во-первых, мне не нужно никуда идти для проверки орфографии, а во-вторых, я точно знаю, для какой функции, класса она была вызвана (getvideoall), и могу просто пойти туда для устранения неполадок

Если вместо этого я просто назвал его $tnVid я бы лично имеют смутное представление о том, что это, но кто-то другой, глядя На будет иметь ни малейшего представления, что ТН-это (Т)Хумб(Н)аил и т. д.
поэтому для устранения им придется сначала посмотреть на окружающий код, чтобы, возможно, сделать вывод, что это вероятно, переменная для миниатюры, а затем просмотрите тысячи строк кода, чтобы найти, какую функцию, класс и т. Д. это произошло из - и это часы работы, чтобы просто найти то, что вам нужно, чтобы даже начать устранение неполадок - вместо 5 секунд, которые требуются, чтобы увидеть $thumbnailvideo_getvideoall и перейти - ах, это миниатюра для видео, и мне нужно перейти к функции getvideoall для устранения неполадок

C++ резервирует набор из 92 слов (по состоянию на C++20) для собственного использования. Эти слова называются ключевыми словами (keywords, или зарезервированными словами), и каждое из этих ключевых слов имеет в языке C++ особое значение.

Ниже приведен список всех ключевых слов C++ (до C++20):

alignas
alignof
and
and_eq
asm
auto
bitand
bitor
bool
break
case
catch
char
char8_t (начиная с C++20)
char16_t
char32_t
class
compl
concept (начиная с C++20)
const
consteval (начиная с C++20)
constexpr
constinit (начиная с C++20)
const_cast
continue
co_await (начиная с C++20)
co_return (начиная с C++20)
co_yield (начиная с C++20)
decltype
default
delete
do
double
dynamic_cast
else
enum
explicit
export
extern
false
float
for
friend
goto
if
inline

int
long
mutable
namespace
new
noexcept
not
not_eq
nullptr
operator
or
or_eq
private
protected
public
register
reinterpret_cast
requires (начиная с C++20)
return
short
signed
sizeof
static
static_assert
static_cast
struct
switch
template
this
thread_local
throw
true
try
typedef
typeid
typename
union
unsigned
using
virtual
void
volatile
wchar_t
while
xor
xor_eq

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

C++ также определяет специальные идентификаторы: override , final , import и module . Они имеют особое значение при использовании в определенных контекстах, но не зарезервированы.

Вы уже встречали некоторые из этих ключевых слов, включая int и return . Эти ключевые слова и специальные идентификаторы вместе с набором операторов определяют весь язык C++ (за исключением команд препроцессора). Поскольку ключевые слова и специальные идентификаторы имеют особое значение, ваши IDE, скорее всего, изменят цвет текста этих слов (часто на синий), чтобы выделить их среди других идентификаторов.

К тому времени, когда вы пройдете эту серию обучающих статей, вы поймете, что делают почти все эти слова!

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

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

идентификатор не может быть ключевым словом (ключевые слова зарезервированы);
идентификатор может состоять только из букв (нижнего или верхнего регистра), цифр и символов подчеркивания. Это означает, что имя не может содержать другие символы (кроме подчеркивания) или пробельные символы (пробелы или табуляции);
идентификатор должен начинаться с буквы (нижний или верхний регистр) или символа подчеркивания, он не может начинаться с цифры;
C++ чувствителен к регистру и, таким образом, различает строчные и прописные буквы ( nvalue отличается от nValue и от NVALUE ).

Лучшие практики именования идентификаторов

Теперь, когда вы знаете, как можно называть переменные, давайте поговорим о том, как желательно называть переменные (или функции).

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

Чаще всего имена функций также начинаются со строчной буквы (хотя по этому поводу есть некоторые разногласия). Мы будем следовать этому соглашению, поскольку функция main (которая должна быть во всех программах) начинается со строчной буквы, как и все функции в стандартной библиотеке C++.

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

В этом руководстве мы обычно будем использовать верблюжью нотацию потому, что ее легче читать (подчеркивание проще ошибочно принять за пробел в плотных блоках кода). Но часто можно увидеть и то, и другое – стандартная библиотека C++ использует подход с подчеркиваниями как для переменных, так и для функций. Иногда вы можете увидеть сочетание двух подходов: подчеркивания, используемые для переменных, и заглавные буквы, используемые для функций.

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

Лучшая практика

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

Во-вторых, вам следует избегать именования идентификаторов, начинающихся с подчеркивания, поскольку эти имена обычно зарезервированы для использования ОС, библиотек и/или компилятора.

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

Однако присвоение тривиальной переменной слишком сложного имени затрудняет общее понимание того, что делает программа, почти так же, как присвоение неадекватного имени широко используемому идентификатору. Поэтому хорошее практическое правило – делать длину идентификатора пропорциональной тому, насколько широко он используется. Идентификатор с тривиальным использованием может иметь короткое имя (например, такое как i ). Идентификатор, который используется более широко (например, функция, которая вызывается из разных мест в программе), должен иметь более длинное и описательное имя (например, вместо open попробуйте openFileOnDisk ).

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

Небольшой тест

Вопрос 1

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

Существует ли соглашение об именовании или, может быть, какое-то руководство о том, как называть параметры функций?

С незапамятных времен я делаю это вот так:

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

(Это PHP, но он должен быть применим к большинству языков программирования)

Есть ли одна серьезная причина против этого?

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

Я обсуждал со своими коллегами правильные соглашения об именовании классов, переменных, объектов и т. д. В ExtJS 4, но у всех нас были разные взгляды. Есть ли на этот счет позиция official?

Что такое хорошее соглашение об именовании массивов? Я работаю над кодовой базой с несколькими тысячами строк кодов, и нет никакого согласованного соглашения об именовании массивов. Немногие ppl называют их, добавляя список в конце имени, как *message_list* , что мне действительно не нравится, так.

ваши функции/методы хорошо написаны и коротки (как и должно быть)
имена переменных достаточно описательны

Эта практика не нужна.

Если вам это нужно, это означает, что написанный код недостаточно читаем (functions/methods слишком долго), загадочные имена переменных/функций, плохие методы OO, ярлыки, долги кода и т. Д. :)

Таким образом, это будет сигналом о том, что код должен быть refactored/improved.

Я думаю, что было бы оправданно воспользоваться советом Полного кода относительно именования-чего угодно - вся глава 11 посвящена правильному именованию переменных):

Не называйте его j, k, i, m, n (если только это не просто для итерации) или "placeholder" или "test". Когда "test" работает, я часто не трачу время на переименование переменной, где бы она ни была указана.

Назовите его описательным именем, которое отделено от функции кода, т. Е. "EmployeeComments", а не "XMLEmp_Comment_File", потому что большая часть этой информации (XML, внешний файл) может измениться, но то, что программа работает с "Employee Comments", не изменится

Держите его как можно более широким и читаемым человеком, чтобы вы кодировали на английском (или на вашем языке), а не на $j=$k/sqrt($pi); или на чем-то столь же непонятном.

Что касается конкретно параметров, я никогда не использовал обозначение P. Мне нравится эта идея, но если бы вы назвали их правильно, разве не было бы ясно, что они являются параметрами для функции?

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

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

Лично я, как правило, сохраняю свои переменные такими же, как rest моих переменных, просто потому, что в первых двух строках функции я удостоверяюсь, что они соответствуют моим ожиданиям, или создаю исключение. После этого на самом деле не должно быть разницы между локальными переменными и переданными переменными. Но, если это делает ваш код более понятным, чтобы напечатать его одним способом, во что бы то ни стало.

Что касается префикса, я бы рекомендовал обратное: оставьте параметр немаркированным и отметьте все, что вы делаете с параметром в функции, как отдельную переменную. Например:

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

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

Я не согласен с предыдущим предложением о том, что вы должны просто сделать свой код более понятным. Наличие четкого кода не устраняет необходимости в четких соглашениях об именах.

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

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

локальные переменные: index
переменные - члены класса: m_index
статические переменные класса: ClassIndex
глобальные переменные: INDEX

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

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

Особенно в лагере all IDE людям, похоже, все больше и больше не нравится любой префикс или суффикс, как "the IDE provides highlighting". Ну, мне это не помогает, и мне не нравится, когда семантическая информация доступна только в виде цвета. Тем не менее, я вижу в этом смысл, поскольку имя переменной должно прояснять самую важную информацию, и если это не так, ничто не помогает.

Итак, это больше о стиле. Хорошее именование важнее хороших префиксов. Для схем: выберите одну, придерживайтесь ее. Это поможет плохому разработчику технического обслуживания. Да, это те люди, которые обычно также предпочитают < >Вокруг отдельных блоков операторов и так далее, но это помогает.

Вы можете следовать стандартам кодирования PHP или стандарту кодирования для php, который предлагается внести в ядро php.

Поэтому, посмотрев на все это, я решил пойти с:

ClassName methodName propertyName function_name (meant for global functions) $variable_name

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

И КАКИЕ БЫ СОГЛАШЕНИЯ ОБ ИМЕНАХ ВЫ НИ ВЫБРАЛИ, БУДЬТЕ ПОСЛЕДОВАТЕЛЬНЫ ВО ВСЕМ ВАШЕМ КОДЕ - это не может быть достаточно повторено :)

Лично я использую следующее:
первая часть переменной предназначена для того, что она есть
, вторая часть предназначена для того, что она делает/используется
для переменных, необходимых вне функции, класса и т. Д. третья часть предназначена для функции, класса и т. Д. это происходит от

Экс:
Я хочу назвать переменную для миниатюры видео на первой странице:
поэтому я начинаю с того, что это такое (lower_case) - миниатюра
затем я добавляю то, для чего он используется (первая буква upper_case) - Видео
, и поскольку он мне нужен на первой странице вне функции, я заканчиваю с функцией, из которой он пришел (отделен от under_score) - getVideoAll

Даешь мне $thumbnailVideo_getVideoAll

Таким образом, независимо от того, где я смотрю на переменную в любой части кода (HTML, PHP и т. Д.) Я знаю.
ах, это миниатюра для видео, которое я пытаюсь показать, и если оно по какой-то причине не работает, мне, во-первых, не нужно никуда идти, чтобы проверить орфографию, а во-вторых, я точно знаю, для какой функции, класса оно было вызвано (getVideoAll), и могу просто пойти туда, чтобы устранить неполадки

Если бы я вместо этого просто назвал его $tnVid, у меня лично могло бы быть смутное представление о том, что это такое, но кто-то другой, глядя на него, понятия не будет иметь, что tn означает (t)humb(n)ail и т. Д.
поэтому для устранения неполадок им придется сначала посмотреть на окружающий код, чтобы, возможно, сделать вывод, что, вероятно, это переменная для миниатюры, а затем пройти через тысячи строк кода, чтобы найти, какая функция, класс и т. Д. он пришел из - и это часы работы, просто найти то, что вам нужно, чтобы даже начать устранение неполадок - вместо 5 секунд, которые требуются, чтобы увидеть $thumbnailVideo_getVideoAll и пойти - ах, это миниатюра для видео, и мне нужно перейти к функции getVideoAll для устранения неполадок

Похожие вопросы:

Существуют ли какие-либо соглашения об именовании общих имен параметров в REST url? В моем примере я хочу получить адрес отдела, основанного на отделе ID или организации ID, под которой находится.

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

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

Каковы соглашения об именовании при работе с файлами .plist в приложениях iOS. Конкретно: Соглашения об именовании имен файлов Соглашения об именовании используемых ключей Спасибо.

Часто ли используется общепринятое соглашение об именовании параметров для функции JavaScript? Например: function MyFunction(nParam1, tParam2, oParam3) где nParam1 -число, tParam2 -текст, а.

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

в Python, я видел выше, но я также видел подчеркивания используются:

есть ли более предпочтительный, окончательный стиль кодирования для Python?

Смотрите Python PEP 8.

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

mixedCase допускается только в контекстах где это уже превалирует стиль

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

лично я отклоняюсь от этого, потому что я также предпочитаю mixedCase over lower_case для моих собственных проектов.

Google Python Style Guide имеет следующее соглашение:

module_name, package_name, ClassName, method_name, ExceptionName, function_name, GLOBAL_CONSTANT_NAME, global_var_name, instance_var_name, function_parameter_name, local_var_name

аналогичная схема именования должна применяться к CLASS_CONSTANT_NAME

joined_lower для функции, методы, атрибуты, переменные
joined_lower или ALL_CAPS для константы
StudlyCaps для занятия
camelCase только для того чтобы соответствовать ранее существовавшие соглашения

Как руководство по стилю для кода Python признает,

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

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

не стесняйтесь отмахиваться от меня как от еретика. :- ) Как и ОП, я не "питонист", во всяком случае, пока.

как уже упоминалось, PEP 8 говорит использовать lower_case_with_underscores для переменных, методов и функций.

Я предпочитаю использовать lower_case_with_underscores для переменных и mixedCase для методов и функций делает код более ясным и читаемым. Таким образом, следуя Дзен питона "явное лучше, чем неявное" и "читабельность имеет значение"

лично я стараюсь использовать CamelCase для классов, методов и функций mixedCase. Переменные обычно разделяются подчеркиванием (когда я могу вспомнить). Таким образом я могу сразу сказать, что именно я звоню, а не все одинаковые.

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

мне просто нравится CamelCase лучше, так как он лучше подходит к тому, как называются классы, он чувствует себя более логичным, чтобы иметь SomeClass.doSomething() чем SomeClass.do_something() . Если вы посмотрите вокруг в Глобальном индексе модуля в python, вы найдете оба, что связано с тем, что это коллекция библиотеки из разных источников, которые росли сверхурочно, а не то, что было разработано одной компанией, такой как Sun со строгими правилами кодирования. Я бы сказал, что суть в следующем: используйте все, что вам больше нравится, это просто вопрос личного вкуса.

имена отдельных символов, за исключением счетчиков или итераторов
тире ( - ) в любом имени пакета/модуля
\__double_leading_and_trailing_underscore__ names (зарезервировано Python)

"внутренний" означает внутренний для a модуль или защищенный или закрытый внутри класса.
добавление одного подчеркивания ( _ ) имеет некоторую поддержку для защиты переменных и функций модуля (не входит в импорт * from). Добавление двойного подчеркивания ( _ _ ) к переменной или методу экземпляра эффективно служит для того, чтобы сделать переменную или метод закрытыми для своего класса (используя искажение имени).
поместите связанные классы и функции верхнего уровня вместе в модуле. В отличие от Java, нет необходимости ограничивать себя один класс на модуль.
использовать CapWords для имен классов, но lower_with_under.py для имен модулей. Хотя есть много существующих модулей с именем CapWords.py , это теперь не рекомендуется, потому что это сбивает с толку, когда модуль оказывается назван в честь класса. ("подожди-ка, я же писал import StringIO или from StringIO import StringIO ?")

стиль кодирования обычно является частью внутренней политики/стандартов Конвенции Организации, но я думаю, что в целом стиль all_lower_case_underscore_separator (также называемый snake_case) наиболее распространен в python.

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

В Python я видел вышеупомянутое, но я также видел подчеркивание:

Есть ли более предпочтительный, определенный стиль кодирования для Python?

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

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

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

@RickyRobinson Какой редактор кода вы используете, который не знает, что подчеркивание продолжает слово? Много бесплатных, которые делают. Я использую Notepad ++, если IDE недоступна. Для этого можете скачать шаблон для редактирования на питоне. (Другие могут порекомендовать еще больше полезных бесплатных загрузок.)

Одним из примеров подчеркнутого стиля является то, что вы можете лучше использовать однобуквенные слова. Для (довольно глупый) пример, findMeAClass возможно, более уродлив, чем find_me_a_class .

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

Руководство по стилю Google Python имеет следующее соглашение:

module_name , package_name , ClassName , method_name , ExceptionName , function_name , GLOBAL_CONSTANT_NAME , global_var_name , instance_var_name , function_parameter_name , local_var_name .

Аналогичная схема именования должна применяться к CLASS_CONSTANT_NAME

а) я люблю примеры - спасибо. б) Непривлекательная смесь CamelCase и подчеркивания? Но: будучи новичком в Python и его более гибкой модели данных, я уверен, что за руководством Google стоит серьезная мысль .

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

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

Считаете ли вы постоянный статический атрибут GLOBAL_CONSTANT_NAME? Это не совсем глобально, так как это входит в сферу деятельности класса.

затем входит property . возможно, дело в том, какой предмет притворяется, а не в том, чем он является на самом деле

joined_lower для функций, методов, атрибутов, переменных

joined_lower или ALL_CAPS для констант

StudlyCaps для занятий

camelCase только в соответствии с ранее существовавшими соглашениями

StudlyCaps for classes отличное универсальное правило для занятий практически на всех языках. Тогда почему некоторые встроенные в Python классы (например datetime.datetime , не соблюдающие это соглашение?

@PrahladYeri: К сожалению, unittest.TestCase.assertEqual и друзья тоже не соблюдают соглашение snake_case. Правда состоит в том, что части стандартной библиотеки Python были разработаны до того, как соглашения укрепились, и теперь мы застряли с ними.

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

Обратите внимание, что это относится только к стандартной библиотеке Python . Если они не могут добиться такой последовательности, то вряд ли можно надеяться на общепринятую конвенцию для всех. кода Python, есть?

Не стесняйтесь уволить меня как еретика. :-) Как и OP, я не "Pythonista", во всяком случае, пока.

Существует PEP 8 , как показывают другие ответы, но PEP 8 - это только руководство по стилю для стандартной библиотеки, и в нем оно воспринимается только как Евангелие. Одним из наиболее частых отклонений PEP 8 для других частей кода является именование переменных, особенно для методов. Единого преобладающего стиля не существует, хотя, учитывая объем кода, который использует mixedCase, если провести строгую перепись, возможно, получится версия PEP 8 с mixedCase. Есть небольшое другое отклонение от PEP 8, которое является столь же распространенным.

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

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

+1 Я переключаю эти два (я использую mixedCase для переменных), но наличие всего более отчетливого помогает сразу понять, с чем вы имеете дело, тем более что вы можете передавать функции.

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

далее на что @JohnTESlade ответил. Руководство по стилю Google Python содержит несколько довольно аккуратных рекомендаций,

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

имена отдельных символов, за исключением счетчиков или итераторов
тире (-) в любом имени пакета / модуля
\__double_leading_and_trailing_underscore__ names (зарезервировано Python)

Соглашение об именовании

Руководства, основанные на рекомендациях Гвидо

Большинство людей, предпочитающих python, предпочитают подчеркивание, но даже я использую python уже более 5 лет, но я до сих пор не люблю их. Они просто выглядят мне некрасиво, но, возможно, это все, что связано с Java в моей голове.

Мне просто нравится CamelCase лучше, так как он лучше подходит для именования классов. Это логичнее, SomeClass.doSomething() чем иметь SomeClass.do_something() . Если вы посмотрите в глобальном модульном индексе в python, вы найдете и то, и другое, что связано с тем, что это коллекция библиотек из разных источников, которые со временем выросли, а не что-то, разработанное одной компанией, такой как Sun, со строгими правилами кодирования. , Я бы сказал, что суть в том, чтобы использовать то, что вам больше нравится, это просто вопрос личного вкуса.

Для меня подчеркивания привлекательны в функциях / методах, так как я вижу каждое подчеркивание как разделитель для виртуального (в моей голове) пространства имен. Таким образом , я могу легко узнать , как назвать мои новые функции / методы: make_xpath_predicate , make_xpath_expr , make_html_header , make_html_footer

Вы (обычно) не вызываете SomeClass.doSomething() (статические методы обычно редки), вы обычно вызываете an_instance.do_something()

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

Читайте также: