Каковы преимущества префикса имен параметров функции с p *?


22

Я часто вижу проекты (в Java-проектах и ​​командах, использующих Eclipse), с которыми префиксные параметры функции p.

Например

public void filter (Result pResult) ...

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

Ответы:


34

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


10
Система венгерской нотации - ужасная практика, которую следует избегать. С другой стороны, некоторые приложения венгерской нотации могут быть полезны (например, для предотвращения неправильного использования небезопасного ввода пользователя).
Кейси Кубалл

7
@Darthfett: Даже такого рода венгерские обозначения, кажется, пытаются реализовать специальную, ручную систему типов непосредственно в именах переменных. Просто используйте хороший статически типизированный язык и имейте реальную систему типов, отслеживайте подобные вещи автоматически!
Тихон Джелвис

1
@WyattBarnett Systems Hungarian не предоставляет программисту никакой полезной информации о современных средах разработки. Венгерские приложения могут уменьшить головные боли при проверке кода, если они правильно применяются.
Кейси Кубалл

2
@TikhonJelvis Не все языки поддерживают строгое применение typedef (например, C ++ typdefs ). Для языков, которые его поддерживают, вы совершенно правы.
Кейси Кубалл

4
@Darthfett: В C / C ++ вы можете просто обернуть его в struct/ unionс одним элементом.
Мацей Печотка

9

Как вы подозреваете, это делается для того, чтобы избежать конфликтов имен между именем параметра и именами членов или локальных переменных. Переменные-члены иногда получают префикс по той же причине (например, m_result). Лично я предпочитаю просто использовать thisпрефикс для переменных-членов, если есть конфликт имен. Он встроен в язык, и все уже знают, что это значит.


Это то, что я делаю. Неиспользование префикса также помогает в Eclipse при вызове метода. Если вы построили свое дерево объектов и называете переменные, как имена параметров метода, который вы хотите вызвать, это работает как шарм, но если имена параметров имеют префикс, это не работает.
Ощренк

5

Я использую префикс параметра только тогда, когда параметр предназначен для назначения переменной-члену, такой как конструктор или установщик.

Paint (newColor) {
  color = newColor;
}

Я считаю, что использование другого имени переменной более ослепительно очевидно, чем использование префикса «this».

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

Если метод или класс настолько велики, что трудно сказать, что означают переменные, реальное решение состоит в том, чтобы разбить их на более мелкие методы / классы. Использование префиксов - это решение, которое помогает решить основную проблему.


Лично я предпочитаю сокращать имя параметра в этом случае (например, Paint (clr) { color = clr; }). ... обычно не так много двусмысленности, хотя, color -> clrв частности, это может быть исключением.
Джастин Тайм - Восстановить Монику

1

Если вы создадите стандарт для использования «p» в качестве префикса для каждого имени параметра метода, вы можете легко распознать параметры метода в остальной части тела метода.

Это экономит ваше время, чтобы найти параметры метода. Вы можете легко отладить свой код.


1
Если вы не можете сказать, что является параметром, а что нет - ваш метод написан плохо. Может быть, он слишком длинный или использует слишком много неструктурированных переменных? В любом случае кажется, что проблема решается путем добавления ненужных префиксов.
Якубисон

1

Коротко. Эта практика затрудняет чтение кода.

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

  • Как избежать коллизий в именах переменных

    • Ваши имена параметров выражают точно, что параметры? Если у вас есть поле параметра и класса, которые «абсолютно одинаковы», вам не нужен параметр.
    • В этом случае имеет смысл использовать префиксы для конструкторов классов, например, новый префикс *, описанный в ответе Аарона. Это также может быть полезно для методов установки, например

    public void setHeight(int newHeight) { this.height = newHeight; }

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

    • Как описано выше - проблема заключается в количестве переменных.
    • Программа, вероятно, не очень хорошо структурирована. Проверьте, все ли переменные являются «независимыми» - возможно, они должны быть организованы в структуры или классы. Возможно, весь расчет или процесс должен быть заключен в отдельный класс, чтобы оперировать таким количеством переменных.
    • Даже если вам нужно такое количество переменных - они должны использовать значимые имена, а префикс стоит между вами и значимой частью.
  • Методы очень длинные, и вам нужно использовать префиксы для отслеживания того, что является параметром.
    • Проблема заключается в длине методов - если программа написана хорошо, вы всегда должны видеть заголовок метода и все его тело на одном экране.
    • Попробуйте разделить метод на более мелкие блоки.

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


0

Я фанат iParam для входных и oParam для выходных параметров. Я бы сказал cParam за изменения, но это не приемлемо


2
Не могли бы вы объяснить, почему вы являетесь поклонником этого префикса, что вы получаете, используя его?
Питер
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.