Pull to refresh

Comments 36

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

Только вот ограничение в 100 символов на длину строки кажется неудобным. В нашей компании стандарт — 120 символов. Если, например, объявляешь коллекцию объектов с длиным названием в переменной с длинным названием и в той же строке эту переменную инициализируешь, вызывая метод с длинным названием у объекта с пусть даже не самым длинным названием, тут-то ста символов и не хватает. А встречается такое часто.
Не очень много отличий от java code conventions, а из андроид-специфичных — так и вовсе только порядок импортов.
Причем те отличия, которые действительно будут видны — несколько спорны. Зачем, например, добавлять m к приватным полям класса? Чтобы автокомплит запутать?
>Зачем, например, добавлять m к приватным полям класса

Встречается ситуация, когда setter-метод использует параметры, совпадающие по имени с полями класса, видимо поэтому решили приписать префикс.
Для этих редких ситуаций вполне можно использовать this.
void setName(String name)
{
this.name = name;
}

У меня IDE визуально разграничивает их — по-разному отображает локальные переменные и переменные класса. Тут не спутаешь.
ИМХО, префикс m — лишнее.
С принципом бритвы Оккама, конечно, не поспоришь. Но я всё-таки склоняюсь к тому, что добавление «m» уменьшает потенциальное количество багов, потому что есть вероятность забыть про this. Короче говоря, лучше использовать правило 13, то есть согласовывать свой код с тем, что уже есть. Ну или с тем, что принят в качестве корпоративного стандарта.
Правило 13 — это веский аргумент, но много ли под Андроид «длинных» проектов с уже устоявшимся стилем? Думаю, не очень — именно поэтому и хотят ввести какие-то соглашения. Пока не поздно)
Про this — не понял. Имя параметра сетера, равное имени локального филда — это скорее правило, чем исключение. Забыть про this я не знаю как можно, в 95% случаев геттеры/сеттеры генерятся IDE. Да и что собственно изменится? Ну назвали филд не field, а mField. Все равно же будет сеттер setMField с таким же параметром mField. Или они предлагают сеттер называть setField, нарушив спецификацию java beans?
Врядли это цель — скорее уж я поверю в повышение наглядности за счет того, что явно видны различия между статик и обычными филдами, как когда-то добавляли к имени идентификаторы типа, вроде bdField для BigDecimal. Но актуально ли это сейчас, с учетом возможностей IDE? Не уверен… И, как специально, к этому пункту они не написали ни «pros», ни «cons», ни «why».
Первоисточник был написан для самого Android OSP, возможно, дело в этом?
>Или они предлагают сеттер называть setField, нарушив спецификацию java beans?
Опичание JavaBean как раз вроде бы говорит, что название сеттеров/геттеров может быть абстрагировано от названия приватных полей и даже более того: таких приватных полей может и не быть.
UFO just landed and posted this here
Префикс m удобно использовать. Но для всех переменных экземпляра, а не только приватных. Например, так можно отделить визуально переменные экземпляра от локальных переменных методов или параметров методов!
Хотя, все это дело каждой организации/команды разработчиков и т.д.
Но признаться честно, раньше никогда сам не использовал данный префикс и все же сейчас понимаю, что удобная штука, ИМХО.
Ещё с префиксами удобнее подсказки использовать. Например, в Eclipse написал 'm', кликнул Ctrl+Space и сразу видишь все переменные класса.
Стандарты это хорошо, но использовать из надо с умом. Ничто не является правдой в последней инстанции.
Правила имеют рекомендательный характер. Строгие они для тех, кто участвует в Android Open Source Project.
Отступы в виде четырёх пробелов??? Кому и зачем это пришло в голову?
UFO just landed and posted this here
Так табуляция для того и придумана, чтобы не было этих проблем. Если юзать табы то каждый будет видеть такие отступы, какие ему по вкусу. Не понимаю как можно было четыре пробела сделать стандартом =\
Потому что стандарт табуляции — 8 символов в юниксе, а 4 — это не табуляция. Тоже предмет холивара.
Таб — это один символ, и каждая IDE может отображать его как хочет — хоть в виде тридцати пробелов. Когда все ставят в коде табы, а не пробелы, проблем никаких не возникает и все довольны — у всех отображается то количество пробелов, какое они настроили в IDE. Но когда кто-то умный начинает ставить реальные проблемы — настаёт писец при смешивании кода, приходится с матом всё переформатировать.
А где гарантия, что в IDE всегда будут табы вместо пробелов?
Ну, я не уверен, но мне кажется что во всех нормальных IDE можно указать, чем индентить — каким-то числом пробелов или табами.
Ну и чем принципиально отличается 4 пробела от табуляции, при использован ии IDE? Все так же нажимаешь Tab, на клавиатуре.
UFO just landed and posted this here
Так об этом и речь, вот стандарт, в нем все прописано.
А нет, начинают снова использовать табуляцию и ставить скобки с новой строки.
UFO just landed and posted this here
UFO just landed and posted this here
Тем, что если ты написанный таким способом код отдашь другому человеку, у которого IDE настроен на просто табы или на восьмирные а не четверные пробелы, то он тебя проклянёт :) Представь, как будет выглядеть кусок твоего кода, скопипастенный в чужой проект.
Юзать надо ТОЛЬКО табы.
1. есть стандарт
2. код все равно будет выглядеть криво при копировании, так что в любом случае нужно будет нажать Ctrl+F?..

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

В данном случае, рассматривается андроид, и логично было бы форматировать согласно принятым правилам, дабы ваш код не выглядел потом чужеродным.
UFO just landed and posted this here
Документ в целом хороший, хоть и тоже не очень понял, причем тут андроид. Стандартный кодегайд по Яве. Но стоит отметить отдельные странные места.

Иногда возникает ощущение, что я живу в каком-то другом мире програмирования, а другие програмируют на 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

Еще бросилась в глаза подробнейшая инструкция по эксепшенам, которая приводит к одной из самых распространенной болезни в кодировании, чрезмерному увлечению троваблами, когда кидание эксепшена является рядовым возвратом из функции. И это на андроиде, где перфоманс ключевой фактор. То, что эксепшены надо корректно отрабатывать, мысль вполне понятная, и все ветки исполнения должны адекватно читаться, это тоже понятно.
Финализаторы, кстати, очень удобно использовать для логгинга для детекта ликов. Если финализатор обнаружит, что на объекте не вызван close() он может выводить в лог с-щее предупреждение. Очень удобно.
>>Перебрасывайте исключения к вызывающему методу.
>>
>>void setServerPort(String value) throws NumberFormatException {
>> serverPort = Integer.parseInt(value);
>>}

Наверное рантаймы писать в throws — перебор:)
Опять египетские скобки, опять m в переменных. Не нужно.
Only those users with full accounts are able to leave comments. Log in, please.