Правила именования частных полей Android в порядке? - PullRequest
10 голосов
/ 25 января 2010

Здесь http://source.android.com/source/code-style.html#follow-field-naming-conventions указано, что:

Имена полей

  • Непубличные, нестатические имена полей начинаются с m.
  • Имена статических полей начинаются с s.
  • Другие поля начинаются со строчной буквы.
  • Открытые статические конечные поля (константы) имеют значение ALL_CAPS_WITH_UNDERSCORES.

В нем также говорится, что:

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

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

Итак, почему я должен быть вынужден иметь почти все мои поля в программе с "m" перед ними? не было бы проще иметь несколько открытых полей, если они есть, с какой-то буквой "g" или что-то еще? или просто использовать сеттеры и геттеры, как предлагают бины? это действительно делает мой код труднее читать ....

Кроме того, следуя этим рекомендациям, локальные временные переменные, используемые в методах, не имеют ограничений, поэтому их можно легко принять за публичные глобальные поля (также без ограничений) ... это также я считаю неправильным, поскольку это вероятно источник ошибок ... Я понимаю, что есть способ отличить от полей, но частные / защищенные поля-члены наиболее часто используются в приложении, они не должны быть менее «читабельными».

Что ты думаешь? Должен ли я следовать рекомендациям?

Ответы [ 2 ]

10 голосов
/ 25 января 2010

Эти рекомендации по кодированию относятся к Android Open Source Project, который является основной платформой Android. Вы должны следовать этим рекомендациям, если хотите, чтобы какой-либо код был принят в базовую платформу. Вы можете делать все что угодно в своих приложениях.
Что касается самих руководств, я думаю, что они очень разумны и похожи на многие стандарты, используемые в коммерческих приложениях. Обычно вы хотите использовать методы получения и установки для доступа к общедоступным полям и не хотите иметь глобальные открытые переменные. Только глобальные публичные константы в порядке.
Таким образом, краткий ответ: следуйте за ними для проекта с открытым исходным кодом, решите следовать за ними в вашем приложении.

1 голос
/ 23 июня 2011

Что касается getters \ setters, на самом деле, рекомендуется не использовать их в Android.

Я нашел это на странице " Проектирование для производительности " (раздел: Избегайте внутренних методов получения / установки ): http://developer.android.com/guide/practices/design/performance.html

Суть в том, что они делают вывод, что поиск полей экземпляра более эффективен, чем вызовы виртуальных методов (из-за оптимизации в JIT).

Я думаю, что я буду продолжать использовать getters \ setters в своем коде, но это может быть простым способом повышения производительности (особенно для приложений, которые выполняют много манипуляций с данными).

...