Соглашения об именах для переменных параметров функции?

Question

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

С тех пор я делаю это всегда так:

function divide( $pDividend, $pDivisor )
{ ... }

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

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

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

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

Answer 1

Если:

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

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

function upperCase($title) {
    $upTitle = ucfirst($title);
    return $upTitle;
}

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

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

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

Answer 4

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

$arrFormData

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

$form_data

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

Answer 5

Существует множество способов именования переменных (как видно из ответов)

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

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

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

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

Дайте мне $ thumbnailVideo_getVideoAll

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

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

Answer 6

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

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

Answer 7

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

Answer 8

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

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

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

Answer 9

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

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

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