@Tibr17 янв 2011 в 21:34

Рекомендации к стилю кода

9 мин

178K

Android *

Перевод

+27

Комментарии 37

@BlackStream 17 янв 2011 в 22:19

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

@dzzh 17 янв 2011 в 22:28

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

Только вот ограничение в 100 символов на длину строки кажется неудобным. В нашей компании стандарт — 120 символов. Если, например, объявляешь коллекцию объектов с длиным названием в переменной с длинным названием и в той же строке эту переменную инициализируешь, вызывая метод с длинным названием у объекта с пусть даже не самым длинным названием, тут-то ста символов и не хватает. А встречается такое часто.

@13th 17 янв 2011 в 22:35

Не очень много отличий от java code conventions, а из андроид-специфичных — так и вовсе только порядок импортов.
Причем те отличия, которые действительно будут видны — несколько спорны. Зачем, например, добавлять m к приватным полям класса? Чтобы автокомплит запутать?

@Tibr 17 янв 2011 в 22:58

>Зачем, например, добавлять m к приватным полям класса

Встречается ситуация, когда setter-метод использует параметры, совпадающие по имени с полями класса, видимо поэтому решили приписать префикс.

@general 17 янв 2011 в 23:05

Для этих редких ситуаций вполне можно использовать this.
void setName(String name)
{
this.name = name;
}

У меня IDE визуально разграничивает их — по-разному отображает локальные переменные и переменные класса. Тут не спутаешь.
ИМХО, префикс m — лишнее.

@Tibr 17 янв 2011 в 23:16

С принципом бритвы Оккама, конечно, не поспоришь. Но я всё-таки склоняюсь к тому, что добавление «m» уменьшает потенциальное количество багов, потому что есть вероятность забыть про this. Короче говоря, лучше использовать правило 13, то есть согласовывать свой код с тем, что уже есть. Ну или с тем, что принят в качестве корпоративного стандарта.

@13th 17 янв 2011 в 23:28

Правило 13 — это веский аргумент, но много ли под Андроид «длинных» проектов с уже устоявшимся стилем? Думаю, не очень — именно поэтому и хотят ввести какие-то соглашения. Пока не поздно)
Про this — не понял. Имя параметра сетера, равное имени локального филда — это скорее правило, чем исключение. Забыть про this я не знаю как можно, в 95% случаев геттеры/сеттеры генерятся IDE. Да и что собственно изменится? Ну назвали филд не field, а mField. Все равно же будет сеттер setMField с таким же параметром mField. Или они предлагают сеттер называть setField, нарушив спецификацию java beans?
Врядли это цель — скорее уж я поверю в повышение наглядности за счет того, что явно видны различия между статик и обычными филдами, как когда-то добавляли к имени идентификаторы типа, вроде bdField для BigDecimal. Но актуально ли это сейчас, с учетом возможностей IDE? Не уверен… И, как специально, к этому пункту они не написали ни «pros», ни «cons», ни «why».

@Tibr 17 янв 2011 в 23:36

Первоисточник был написан для самого Android OSP, возможно, дело в этом?

@m4spam 18 янв 2011 в 13:41

>Или они предлагают сеттер называть setField, нарушив спецификацию java beans?
Опичание JavaBean как раз вроде бы говорит, что название сеттеров/геттеров может быть абстрагировано от названия приватных полей и даже более того: таких приватных полей может и не быть.

НЛО прилетело и опубликовало эту надпись здесь

@Pyjamec 18 янв 2011 в 08:16

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

@Pr0v0dn1k 18 янв 2011 в 13:58

Ещё с префиксами удобнее подсказки использовать. Например, в Eclipse написал 'm', кликнул Ctrl+Space и сразу видишь все переменные класса.

@Scorpil 18 янв 2011 в 00:16

Стандарты это хорошо, но использовать из надо с умом. Ничто не является правдой в последней инстанции.

@Tibr 18 янв 2011 в 00:20

Правила имеют рекомендательный характер. Строгие они для тех, кто участвует в Android Open Source Project.

@nochnoy 18 янв 2011 в 08:06

Отступы в виде четырёх пробелов??? Кому и зачем это пришло в голову?

НЛО прилетело и опубликовало эту надпись здесь

@nochnoy 18 янв 2011 в 10:15

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

@trurl123 18 янв 2011 в 12:56

Потому что стандарт табуляции — 8 символов в юниксе, а 4 — это не табуляция. Тоже предмет холивара.

@nochnoy 18 янв 2011 в 13:07

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

@trurl123 18 янв 2011 в 13:14

А где гарантия, что в IDE всегда будут табы вместо пробелов?

@nochnoy 18 янв 2011 в 13:36

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

@vovkab 18 янв 2011 в 10:18

Ну и чем принципиально отличается 4 пробела от табуляции, при использован ии IDE? Все так же нажимаешь Tab, на клавиатуре.

НЛО прилетело и опубликовало эту надпись здесь

@vovkab 18 янв 2011 в 13:13

Так об этом и речь, вот стандарт, в нем все прописано.
А нет, начинают снова использовать табуляцию и ставить скобки с новой строки.

НЛО прилетело и опубликовало эту надпись здесь

@nochnoy 18 янв 2011 в 13:02

Тем, что если ты написанный таким способом код отдашь другому человеку, у которого IDE настроен на просто табы или на восьмирные а не четверные пробелы, то он тебя проклянёт :) Представь, как будет выглядеть кусок твоего кода, скопипастенный в чужой проект.
Юзать надо ТОЛЬКО табы.

@vovkab 18 янв 2011 в 13:34

1. есть стандарт
2. код все равно будет выглядеть криво при копировании, так что в любом случае нужно будет нажать Ctrl+F?..

Так и в чем тут проблема?

@nochnoy 18 янв 2011 в 13:49

1. При разработке стандартов надо думать головой
2. Код никогда не выглядит криво при копировании, если и там и там юзались табы.
3. Зачем вообще нужны стандарты если есть Ctrl+F? :))

@vovkab 18 янв 2011 в 14:31

Ну так форматер, форматирует код согласно тому что вы указали.

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

НЛО прилетело и опубликовало эту надпись здесь

@srez 18 янв 2011 в 22:01

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

Иногда возникает ощущение, что я живу в каком-то другом мире програмирования, а другие програмируют на notepad, где среда не подсвечивает поля класса, где люди руками смотрят в импорты чаще раза в месяц. Где среда на коммите не автоформатирует класс согласно общекомандному стилю и кого-то действительно волнует, что там в секции импортов сидит. У меня эта секция свернута средой и поддерживается средой. А уж про венгерскую нотацию сколько было статей, что подбирать префиксы по типу переменной (мембер, статик, локальная итп) или по классу это зло.
local.joelonsoftware.com/mediawiki/index.php/%D0%9A%D0%B0%D0%BA_%D0%B7%D0%B0%D1%81%D1%82%D0%B0%D0%B2%D0%B8%D1%82%D1%8C_%D0%BD%D0%B5%D0%BF%D1%80%D0%B0%D0%B2%D0%B8%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9_%D0%BA%D0%BE%D0%B4_%D0%B2%D1%8B%D0%B3%D0%BB%D1%8F%D0%B4%D0%B5%D1%82%D1%8C_%D0%BD%D0%B5%D0%BF%D1%80%D0%B0%D0%B2%D0%B8%D0%BB%D1%8C%D0%BD%D0%BE

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

@srez 18 янв 2011 в 22:04

Финализаторы, кстати, очень удобно использовать для логгинга для детекта ликов. Если финализатор обнаружит, что на объекте не вызван close() он может выводить в лог с-щее предупреждение. Очень удобно.

@skorn 18 янв 2011 в 22:18

>>Перебрасывайте исключения к вызывающему методу.
>>
>>void setServerPort(String value) throws NumberFormatException {
>> serverPort = Integer.parseInt(value);
>>}

Наверное рантаймы писать в throws — перебор:)

@monkegoist 19 янв 2011 в 05:53

Steve McConnell «Code complete»

@nightstalker 20 янв 2011 в 12:11

Опять египетские скобки, опять m в переменных. Не нужно.

@SystemSoft 8 мая в 10:22

строка class Html напрашивается чтобы её написали как class HTML.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий