Які переваги префіксації імен параметрів функції за допомогою p *?

Я часто бачу проекти (в проектах Java та команди, що використовують Eclipse), з якими встановлюються параметри функцій префікса p.

Наприклад

public void filter (Result pResult) ...

Я особисто не бачу в цьому ніякої користі, але хотів би знати, що таке міркування. Найкраще пояснення, про яке я чув, - це розрізнити назву однакових названих полів. У мене є проблеми з цим поясненням, але я можу зрозуміти суть.

Практика додавання значущих префіксів до символів, таких як широко оприлюднена угорська нотація , сягає часів, коли ІДЕ не існували або були надто примітивними. Сьогодні, коли пошук точки декларації знаходиться в натисканні миші, немає сенсу псувати найдорожчу частину імені, перші кілька його літер, присвоюючи загальний префікс.

Як ви підозрюєте, це уникати зіткнень імен між назвою параметра та іменами члена або локальної змінної. Змінні учасники іноді отримують префікс з тієї ж причини (наприклад, m_result). Особисто я вважаю за краще використовувати thisпрефікс для змінних членів, якщо є зіткнення імені. Він вбудований у мову, і всі вже знають, що це означає.

Я використовую префікс параметра лише тоді, коли параметр призначений для присвоєння змінної члена, наприклад конструктору або сеттеру.

Paint (newColor) {
  color = newColor;
}

Для мене я вважаю, що використання іншого імені змінної є сліпуче очевидним, ніж використання префікса "цей".

В інших ситуаціях я уникаю використання параметра, який можна легко сплутати зі змінною члена.

Якщо метод або клас настільки великі, що важко сказати, що означають змінні, реальним рішенням є розбити його на більш дрібні методи / класи. Використання префіксів - це смугова розв'язка, яка вирішує основну проблему.

Якщо ви робите стандарт, щоб використовувати "p" як префікс з кожним іменем параметра параметра, ви можете легко розпізнати параметри методу в решті тіла методу.

Це економить ваш час на пошук параметрів методу. Ви можете легко налагодити свій код.

Короткий - ця практика ускладнює читання коду.

Довго - я стверджую, що це погана практика, яка використовується лише для підтримки інших поганих практик. Розглянемо кілька причин, чому використання таких префіксів може вважатися корисним:

• Уникнення зіткнень у змінних імен

  • Чи імена ваших параметрів виражають саме такі параметри? Якщо у вас є параметр і поле класу, які "абсолютно однакові", вам параметр не потрібен.
  • У цьому випадку має сенс використовувати лише префікси для конструкторів класів, як новий префікс *, описаний у відповіді Аарона. Це також може бути корисним для методів встановлення, наприклад

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

• Методи беруть багато параметрів, оголошують багато змінних, і ми можемо легко забути, який з них є параметром.

  • Як описано вище - проблема полягає в кількості змінних.
  • Програма, мабуть, недостатньо структурована. Перевірте, чи всі змінні є "незалежними" - можливо, вони повинні бути організовані в структурах або класах. Можливо, весь обчислення чи процес слід загорнути в окремий клас, щоб оперувати такою кількістю змінних.
  • Навіть якщо вам потрібна була така кількість змінних - вони повинні використовувати значущі імена, а префікс стоїть між вами та змістовною частиною.
• Методи дуже довгі, і вам потрібно використовувати префікси, щоб відслідковувати, що таке параметр.
  • Проблема полягає в тривалості методів. Якщо програма написана добре, ви завжди повинні бачити заголовок методу та його тіло на одному екрані.
  • Спробуйте розділити метод на менші блоки.

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

Я фанат iParam для in, а oParam для параметрів. Я б сказав, cParam для змін, але це не прийнятно