Комментарии 36
В первом классе вырабативаем калиграфический почерк, а повзрослев выабатываем стиль програминга.
А вобще очень полезная статья, лучше привыкать сразу писать читабильный и корректный код.
Сейчас работодатели очень на это обращают внимание, да и для себя приятней разбираться в хорошо оформленном коде, а не разбирать бардак, что налепил вчера.
А вобще очень полезная статья, лучше привыкать сразу писать читабильный и корректный код.
Сейчас работодатели очень на это обращают внимание, да и для себя приятней разбираться в хорошо оформленном коде, а не разбирать бардак, что налепил вчера.
Вроде бы все понятно, воде бы ничего нового, но тем не менее полезно иногда перечитывать такие посты.
Только вот ограничение в 100 символов на длину строки кажется неудобным. В нашей компании стандарт — 120 символов. Если, например, объявляешь коллекцию объектов с длиным названием в переменной с длинным названием и в той же строке эту переменную инициализируешь, вызывая метод с длинным названием у объекта с пусть даже не самым длинным названием, тут-то ста символов и не хватает. А встречается такое часто.
Только вот ограничение в 100 символов на длину строки кажется неудобным. В нашей компании стандарт — 120 символов. Если, например, объявляешь коллекцию объектов с длиным названием в переменной с длинным названием и в той же строке эту переменную инициализируешь, вызывая метод с длинным названием у объекта с пусть даже не самым длинным названием, тут-то ста символов и не хватает. А встречается такое часто.
Не очень много отличий от java code conventions, а из андроид-специфичных — так и вовсе только порядок импортов.
Причем те отличия, которые действительно будут видны — несколько спорны. Зачем, например, добавлять m к приватным полям класса? Чтобы автокомплит запутать?
Причем те отличия, которые действительно будут видны — несколько спорны. Зачем, например, добавлять m к приватным полям класса? Чтобы автокомплит запутать?
>Зачем, например, добавлять m к приватным полям класса
Встречается ситуация, когда setter-метод использует параметры, совпадающие по имени с полями класса, видимо поэтому решили приписать префикс.
Встречается ситуация, когда setter-метод использует параметры, совпадающие по имени с полями класса, видимо поэтому решили приписать префикс.
Для этих редких ситуаций вполне можно использовать this.
void setName(String name)
{
this.name = name;
}
У меня IDE визуально разграничивает их — по-разному отображает локальные переменные и переменные класса. Тут не спутаешь.
ИМХО, префикс m — лишнее.
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».
Про this — не понял. Имя параметра сетера, равное имени локального филда — это скорее правило, чем исключение. Забыть про this я не знаю как можно, в 95% случаев геттеры/сеттеры генерятся IDE. Да и что собственно изменится? Ну назвали филд не field, а mField. Все равно же будет сеттер setMField с таким же параметром mField. Или они предлагают сеттер называть setField, нарушив спецификацию java beans?
Врядли это цель — скорее уж я поверю в повышение наглядности за счет того, что явно видны различия между статик и обычными филдами, как когда-то добавляли к имени идентификаторы типа, вроде bdField для BigDecimal. Но актуально ли это сейчас, с учетом возможностей IDE? Не уверен… И, как специально, к этому пункту они не написали ни «pros», ни «cons», ни «why».
Первоисточник был написан для самого Android OSP, возможно, дело в этом?
>Или они предлагают сеттер называть setField, нарушив спецификацию java beans?
Опичание JavaBean как раз вроде бы говорит, что название сеттеров/геттеров может быть абстрагировано от названия приватных полей и даже более того: таких приватных полей может и не быть.
Опичание JavaBean как раз вроде бы говорит, что название сеттеров/геттеров может быть абстрагировано от названия приватных полей и даже более того: таких приватных полей может и не быть.
НЛО прилетело и опубликовало эту надпись здесь
Префикс m удобно использовать. Но для всех переменных экземпляра, а не только приватных. Например, так можно отделить визуально переменные экземпляра от локальных переменных методов или параметров методов!
Хотя, все это дело каждой организации/команды разработчиков и т.д.
Но признаться честно, раньше никогда сам не использовал данный префикс и все же сейчас понимаю, что удобная штука, ИМХО.
Хотя, все это дело каждой организации/команды разработчиков и т.д.
Но признаться честно, раньше никогда сам не использовал данный префикс и все же сейчас понимаю, что удобная штука, ИМХО.
Ещё с префиксами удобнее подсказки использовать. Например, в Eclipse написал 'm', кликнул Ctrl+Space и сразу видишь все переменные класса.
Стандарты это хорошо, но использовать из надо с умом. Ничто не является правдой в последней инстанции.
Отступы в виде четырёх пробелов??? Кому и зачем это пришло в голову?
НЛО прилетело и опубликовало эту надпись здесь
Так табуляция для того и придумана, чтобы не было этих проблем. Если юзать табы то каждый будет видеть такие отступы, какие ему по вкусу. Не понимаю как можно было четыре пробела сделать стандартом =\
Потому что стандарт табуляции — 8 символов в юниксе, а 4 — это не табуляция. Тоже предмет холивара.
Таб — это один символ, и каждая IDE может отображать его как хочет — хоть в виде тридцати пробелов. Когда все ставят в коде табы, а не пробелы, проблем никаких не возникает и все довольны — у всех отображается то количество пробелов, какое они настроили в IDE. Но когда кто-то умный начинает ставить реальные проблемы — настаёт писец при смешивании кода, приходится с матом всё переформатировать.
Ну и чем принципиально отличается 4 пробела от табуляции, при использован ии IDE? Все так же нажимаешь Tab, на клавиатуре.
НЛО прилетело и опубликовало эту надпись здесь
Тем, что если ты написанный таким способом код отдашь другому человеку, у которого IDE настроен на просто табы или на восьмирные а не четверные пробелы, то он тебя проклянёт :) Представь, как будет выглядеть кусок твоего кода, скопипастенный в чужой проект.
Юзать надо ТОЛЬКО табы.
Юзать надо ТОЛЬКО табы.
1. есть стандарт
2. код все равно будет выглядеть криво при копировании, так что в любом случае нужно будет нажать Ctrl+F?..
Так и в чем тут проблема?
2. код все равно будет выглядеть криво при копировании, так что в любом случае нужно будет нажать Ctrl+F?..
Так и в чем тут проблема?
НЛО прилетело и опубликовало эту надпись здесь
Документ в целом хороший, хоть и тоже не очень понял, причем тут андроид. Стандартный кодегайд по Яве. Но стоит отметить отдельные странные места.
Иногда возникает ощущение, что я живу в каком-то другом мире програмирования, а другие програмируют на 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
Еще бросилась в глаза подробнейшая инструкция по эксепшенам, которая приводит к одной из самых распространенной болезни в кодировании, чрезмерному увлечению троваблами, когда кидание эксепшена является рядовым возвратом из функции. И это на андроиде, где перфоманс ключевой фактор. То, что эксепшены надо корректно отрабатывать, мысль вполне понятная, и все ветки исполнения должны адекватно читаться, это тоже понятно.
Иногда возникает ощущение, что я живу в каком-то другом мире програмирования, а другие програмируют на 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
Еще бросилась в глаза подробнейшая инструкция по эксепшенам, которая приводит к одной из самых распространенной болезни в кодировании, чрезмерному увлечению троваблами, когда кидание эксепшена является рядовым возвратом из функции. И это на андроиде, где перфоманс ключевой фактор. То, что эксепшены надо корректно отрабатывать, мысль вполне понятная, и все ветки исполнения должны адекватно читаться, это тоже понятно.
>>Перебрасывайте исключения к вызывающему методу.
>>
>>void setServerPort(String value) throws NumberFormatException {
>> serverPort = Integer.parseInt(value);
>>}
Наверное рантаймы писать в throws — перебор:)
>>
>>void setServerPort(String value) throws NumberFormatException {
>> serverPort = Integer.parseInt(value);
>>}
Наверное рантаймы писать в throws — перебор:)
Steve McConnell «Code complete»
Опять египетские скобки, опять m в переменных. Не нужно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Рекомендации к стилю кода