Не нашёл здесь такой темы, но считаю, что она будет полезна многим. Возможно, даже многим из тех, кто уже давно считает себя не новичком в Java.
В общем, идея проста - все, кому есть, что сказать, предлагают свои советы по тому, как писать код в хорошем стиле.
Чтобы было понятно, приведу пару советов из тех, что в последние дни вычитал на форуме:

1. Если в метод были переданы некорректные данные, выкидываем исключение вместо тихого-мирного притягивания данных за уши к корректному виду.
Пример.
плохо:

лучше:


2. При переопределении метода equals() надо переопределять ещё и hashCode(). Причём хэшкод должен быть равен для объектов, если они эквивалентны (equals() == true).

P.S. Понятно, что многим подобные вещи известны и они пользуются ими не задумываясь. С другой стороны, всё знать нельзя и скорее всего каждый найдёт для себя что-то интересное в этой теме. Ну, или вспомнит хорошо забытое старое.  

Сюда же: имя параметра в setter-методе желательно иметь соответствующим имени метода, также как имя поля.

И пара придирок к вашему коду: на мой взгляд, охватывающие скобки "{}" в if следует ставить всегда, когда условие тривиально и не входит в единственную строчку. При глубине вложенности больше 2-х это сильно упрощает чтение.
Также я бы печатал значение параметра weight, чтобы сразу было понятно что с ним не так. Программу это не усложнит, а при отсутствиии доступа к исходников упростит локализацию ошибки (в том числе в этой проверке). 

И кстати: такое "исправление внутри" может быть удобным и вполне имеет право быть применимым если :
1) Это private метод (наши грабли)
2) Факт описан в javadoc (документированные грабли)
Иначе придётся писать как "культурный" метод, так и враппер к нему. Я не сильно разделяю такую точку зрения, просто привожу её как контрпример.
Прошу не принимать близко к сердцу ;)


Второй пунк описан в каждом учебнике по Java. А IDEA так парой и предлагает их генерить...

P.S. Хорошая тема, надо развивать. Только нужно структурирование.
Люди пишут программу, отмечают "тру-решение" или наоборот , постят сюда - только кто возьмётся за сортировку?

Не думаю, что это всегда так... Такой подход, конечно, весьма практичен, но засоряет код лишними try/catch блоками... Кроме того, exception зачастую подразумевает исключительную ситуацию, которая связана с принципиально непреодалимой ошибкой, ну а в примере ошибка более чем преодолима и может встречаться довольно-таки часто.

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

Дополню. Если создаётся наследник класса, в котором переопределёны equals() и hashCode(), в классе наследнике их следует переопределить обязательно.

На всякий случай поясню: я согласен с приведённым мною примером, но авторство не моё - в одной из тем именно этот пример дал LSD.
Мне, конечно, приятно собирать лавры, но в данном случае они не мои.
Первый пример тоже не мой, но автора я уже не помню (пример взят из темы "Маленький тест").

По поводу засорения кода блоками try-catch.
Имхо, лучше засорить код такими блоками и получить взамен более простой и удобный способ обнаружения и устранения ошибок.


К своему стыду должен признать, что не читал таких учебников. Даже TIJ до сих пор только издалека видел.


Если я правильно понял, то это звучит так:
Если мы в классе А переопределили equals+hashCode, то и в классе Б (наследнике от А) их тоже надо переопределить.

Думмаю, так чуток яснее.


Предпочитаю не захламлять код лишними блоками и пользуюсь следующим правилом:
1. если условие динное (из нескольких частей, либо просто больше 20-30 символов), переносим оператор (то, что надо выполнить) на следующую строку. Замечу, что это верно только для if с одним оператором - блоки всегда структурирую в отдельных строках, не считая самих скобок.
2. если в коде идёт сложная структура из операторов if, то в каждом обязательно обрамляем оператор скобками блока (даже если оператор один). Это позволяет избежать неверной работы, когда мы используем if-else. Пример:

Это плохо, т.к. выглядит и работает по-разному. Чтобы работа соответствовала виду, надо сделать хотя бы так:

Но я в таких случаях предпочитаю везде поставить блоки (иногда через пару дней лезешь в код и видишь, что надо добавить ещё один if - тогда-то блоки и спасают от вероятности приделать новый if не к месту).


Если честно, не понял. Опиши шире, что ты имеешь в виду.

Если у вас в коде есть константа и переменная типа String, которые нужно сравнить, то всегда вызывайте метод equails на константе:

плохо:


хорошо:

Небольшое дополнение.
Иногда нет необходимости выделять константу в собственное поле (по-хорошему, всё же лучше выделить), но совет всё равно стоит использовать:


Добавлено через 4 минуты и 35 секунд
Кстати, а вот и ещё один совет. Просто, обозначу его явно:

Все строковые константы желательно выделять в поля. Это относится к дефолтовым значениям строковых полей, названиям кнопок, страниц и панелей. Единственное исключение - пустая строка.

И немного расширим:

Все константы (любого типа) желательно выделять в поля. Исключения - пустая строка, 0 и т.п.

missorted modifiers, private string constant...

я бы сделал так

Я думаю что подобные константы всегда нужно выносить в поля, хотя с по поводу пустой строки согласен.  Это так называемые "magic numbers" (это обычно к числам относится, поэтому и "numbers"). Их тяжело искать в коде, да и если константа используется в нескольких местах, что чаще всего и бывает, то корректировать их во всех участках кода не есть благородное занятие.


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

Добавлено через 41 секунду

очень может быть 

nornad

А чем 0 лучше других чисел?

Думаю, эти вещи нужно не выделять в поля, а хранить в properties файле и доставать через ResourceBundle.

Тем же, чем и пустая строка "лучше" остальных строк.
Кстати, к "исключительным" магическим числам, имхо, стоит отнести и -1 - очень часто это означает "неверный индекс/вариант".
То есть, если 0 используется для проверки на пустоту списка (по количеству элементов), то не стоит его выносить в отдельное поле.
Также и -1, если она используется, скажем, для определения, есть ли выделение в таблице (JTable.getSelectedRow(), например).

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

Это я и имел в виду. Ноль в группе других числовых констант ничем не выделяется. В то же время, он как количество элементов списка -- очевиден. А как результат выполнения операции -- почти очевиден..

Создать что-то типа справочника "как надо" и "как не надо" - набор практических советов. Люди постят идеи в форуме, определённый человек их отфильтровывает и подкладывает в какой-нибудь FAQ. Строго по пунктам, со всеми "за" и "против", но лаконично. Для начала можно просто в начале темы. Можно выделить такие тематики как "косметическое оформление", "часто используемые конструкции" и т. д. в ширь и вглубь - по мере накопления материала.
И вообще я согласен с тезисом, что даже на глубоко тривиальные иногда нужно указать - не всегда они приходят легко и сразу.


Я как-то для себя решил не усложнять такие вещи. Либо if в одну строчку (обычно с break, return или throw), либо if полноценный - потенциально многострочный. Вколотить туда отладку какую-нибудь или логи опять же удобней...


Не совсем согласен. Если данная строка текста используется в нескольких местах (в классе), в поле её загнать прямой резон. Но и из бандла читать:

На первый взгляд громоздко, зато ошибиться потом просто невозможно. 
Строки, используемые в GUI однократно, имеет смысл загружать на ходу (всё равно они там где-то кэшируются). Незачем засорять класс лишними константами, если они нужны только в одном методе и один раз. Только если уверен, что завтра они не понадобятся ;)

И на счёт ResourceBundle. Даже если не думать об интернализации, редактировать строки в ресурсном файле всё равно в разы удобнее, чем в исходнике, где они раскиданы по всем тексту.

К слову о константах. Читая книжки, натыкаешься чуть ли не на холивары на тему - должны быть они public или private. Хотя на самом деле всё просто - как и остальные члены класса, они должны иметь тот модификатор, который соответствует их необходимости для наследников или внешних классов.

Это сообщение отредактировал(а) RebornCrusader - 15.6.2007, 08:03

Это только совсем "для начала" - после пяти-шести советов начало темы так разбухнет, то тема будет грузиться слишком долго.


Согласен. Я понимаю, что equals+hashCode - тривиально, но лично я этого не читал раньше (ну, не люблю ходить к сану на сайт, а в книжках нормального описания не было).


Даже при такой уверенности они могут понядобиться завтра или послезавтра. Но тут уже можно либо сразу всё подозрительное выделять в поля, либо выделять в поле как только потребуется во втором месте.


Предпочитаю делать либо public (если может пригодиться снаружи), либо protected (уже пару раз столкнулся с тем, что бывает необходимость в потомке изменить константу, а если она приватная, то приходится либо менять доступ, либо привешивать сеттер - в любом случае маразм).

Нет. Охватывающие скобки нужно ставить всегда!
Объяснение простое - тому, кто поддерживает код - будет гораздо легче вставить в блок какие-то операторы, чем сначала обрамлять в скобки, а потом... Да и от многих непоняток уберегает.


1 тоже можно отнести.

Можно тогда пример, в каких случаях 1 говорит сама за себя?

или

или


И вообще, если о числах, то есть -N, -1, 0, 1, N. Всё, что N - выносится в константы, остальное - необязательно.

Не согласен. Пожертвовав не значащими здесь деталями, приведу пример:

ИЛИ


Какой код, по-вашему читается легче? А если ещё подобных методов-сеттеров много?
И всегда ли могут быть другие операторы внутри if-а? Здесь вероятность крайне мала, да и исправить быстро, т. к. строчка короткая и простая. 

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

А вот таких допущений приводить не нужно.
Нельзя с определенность сказать, как будут изменять код.
И сопротивляться изменению он не должен.



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


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

А вообще - спорить мне не хочется. Эти вопросы регламентирует документ компании об оформлении искходного кода.

Это сообщение отредактировал(а) JUncle - 16.6.2007, 16:59

Разумеется тот, который со скобками ;)

К примеру я придерживаюсь (стараюсь) "Хорошего стиля программирования" , а он гласит , что после оператора if должны быть скобки {...}.    ИМХО и читать понятно, и глазу привычней 
Вод!

Полностью согласен с JUncle. Но рационализация (не знаю, блин, как это по-русски - rationalisation... обоснование, что ли) этой привычки у меня другая. Тут дело не в том, что кому-то когда-то может быть придется добавить операторов, и мы мол хотим облегчить им труд, с каковой целью заранее заключаем все в блок. Если бы дело было только в этом, то это как раз не было бы хорошей практикой, ибо относилось бы к категории "ранней (преждевременной) оптимизации", что не есть гуд.

Основная причина, по которой я тоже всегда заключаю условную часть в блок - это стремление к минимизации граблей. Дело в том, что не практике, и особенно в стиле "шустрого программирования" (agile programing), достаточно часто приходится заниматься рефакторингом, перекидывая и перекраивая куски кода. При этом нередко одиночный стейтмент превращается во множественный и наоброт, и если полагаться на безблочную запись, то можно по невнимательности запросто сломать логику работы условия. Особенно этому способствуют закомментирывания/раскомментирывания строк. Вот смотрите:



Но тут мы в какой-то момент решаем, что может быть ширину лучше оставить без изменений, и закомментирываем соответствующую строку:



Хопа! Вот мы и наступили на грабли. Кто хочет сказать, что уж он-то точно никогда так не лажанется, пусть первый бросит в себя камень 

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

А про читабельность я уж и не говорю 

Это сообщение отредактировал(а) Stampede - 16.6.2007, 22:44

Stampede, привёл очень хороший пример.
Я и сам

Что и другим рекомендую.
...
Но я начинаю изучать Java переходя с С++(#) и мне не понятна следующее размещение этих самых скобок: 

Помоему вот так удобней:

Почему в ява первая скобка не пишется с новой строки? И при просмотре кода проще контролировать где "потерялася" какая то скобка.

а) Java - язык этих самых скобок.  Постоянные методы, именованные и безымянные классы, блоки в if/for/while/и т.п. - всё это так нагружает код "лишними" скобками, что зачастую люди ставят открывающую на той же строке, что и оператор-владелец. Так немного больше кода на экран помещается.
б) привычка. Я поначалу тоже не мог привыкнуть к такому виду, а сейчас привык. Чаще пишу в "жабовском" стиле, но если условие многострочное - открывающая скобка у меня обязательно есть и стоит на новой строке.

Ну почему же, я всегда пишу с новой строки(скорее всего тоже с С/С++ осталось) !

Именно эту мысль я никак не мог выразить! Когда условие и выполняющийся оператор стоят в одной строке, я считаю превращение оператора в блок из одного излишним - комментировать также просто и надёжно. Но, согласен, это дело вкуса и политики организации.

Однако если код организован так, что внутренний оператор не входит в одну строчку с самим условием, скобки обязательны - легко видеть границу вложенного кода. И это касается и других конструкций. 

Одну строчку отследить легко, перенос - уже труднее, поэтому и требуется соответствующее оформление. Имено поэтому я не могу полюбить Питон, из-за его "бесскобочной " вложенности. Главное в программе - читаемость кода. А уж скобочки добавить всегда просто. Может я зажрался, но IDEA делает это почти сама ;)


На счёт скобки в отдельной строки - вредная привычка C, с которой переучиваешься за месяц, тем паче при наличии автостилизации в IDE. Корни привычки, на мой взгляд, лежат ещё в Pascal - уж там эти страшные beginы в переносить на нову строчку куда приятнее. И наконец, скобка на новой строке использовалась для комментария к функции:

В Java нужда в этом отпадает, так как есть javadoc

Добавлено @ 02:29

Вот и причина разногласий ;) У каждого в глубине души свои представления о прекрасном ;)

Добавлено через 10 минут и 25 секунд

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

Это сообщение отредактировал(а) RebornCrusader - 17.6.2007, 02:33

чесно говоря..все это хорошо....но есть  Code Conventions for the JavaTM Programming Language написан в далеком 1999 году + есть Maintainability Index програмы...если он больше 100 - значит код хорошый..если менше - увы...

гы, "Сказано пацакам в клетке выступать, значит надо в клетке. Чё выпендриваетесь? " 

Добавлю. 
Для eclipse есть очень Checkstyle плагин, который подсказывает что не так. Рекомендую. 

Документ неплохой, но там тоже далеко не все моменты проясняются. А посему, в этой теме давайте не будем спорить по поводу того, как кому удобнее и красивше код писать (это я про те же скобочки), а либо давать рекомендации по объективно хорошему стилю, либо снабжать различные "имхо" соответствующими пометками (дабы меньше запутывать начинающих).

Прочитал и офигел как много копий ломается о скобки 
а рекомендации по хорошему стилю уже давно выработаны как общие:

и
Дж.Блох Effective Java
так и корпоративные в виде разных Code convension (кстати построенные на sun Code Conventions) и полиси

но и те и другие сходятся в том, что стиль должен обеспечивать код сопровождаемый и читаемый (indents, {}, tabs vs. spaces), и сам стиль предотвращает различные ошибки и неудачности типа: для блока try {…} catch (…) ставь finally; не throws Exception, а кидай че-нибудь вразумительное (Illegalstatement...) и то только когда это ОЧЕНЬ НУЖНО (пример из жизни слышал на програмерской фирме фразу, а мы return-ами уже не пользуемся ма кидаем эксепшны)

Поэтому, ИМХО, советы лучше давать в виде ссылок на эти источники.
можно еще добааить в свете Java5 
не злоупотреблять boxing/unboxing
и использовать generics

Эти стандарты очень часто переопределяются на уровне организации. И, в частности, пункт о скобках у нас тоже оговорен вразрез с Java Conventions.

Это сообщение отредактировал(а) batigoal - 20.6.2007, 11:30

batigoal, дык проблема хорошего стиля это не столько indents и скобки (это просто плагином устанавливается раз написанным -- я тоже "дома" всю интенданцию табуляцией делаю на фирме 4 пробела) сколько делать его читаемым, сопровождаемым и "с защитой от глупых ошибок".
Да вот пример прям рядом как сделать код несопровождаемым:
http://forum.vingrad.ru/forum/topic-159672.html
dB = (float) (Math.log(value==0.0?0.0001:value)/Math.log(10.0)*20.0);

Не могли бы Вы чуть больше о нем рассказать?

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

Есть еще, кстати, Jalopy, тоже неплохая вещь.

Ну, не знаю, насколько это актуально. В 5-ой и 6-ой жабе автобоксинг - вполне нормальная штука и делать явное приведение, имхо, глупо. Посему хотелось бы узнать - зачем?

Всем любителям выносить все в константы рекомендую почитать эту статейку 

Вы можете на вскидку сказать, что удалиться из списка, второй элемент или Integer со значанием 1?

Это сообщение отредактировал(а) fixxer - 20.6.2007, 15:04

Вопрос не в явном приведении, а в том что вообще boxing/unboxing снижает производительность. А автобоксинг к тому же, еще маскирует от программиста опастность возникновения NullPointerException.

Добавлено через 2 минуты и 18 секунд

Я смог 

Насколько я понимаю, тут удаление должно идти по индексу.   

Много не расскажешь. Он предлагает вставлять комментарии где надо, подмечает где скобка не на том месте, предлагает переделать входные параметры в final. Достаточно много настроек, можно под себя построить то что не надо высвечивать. Вобщем, после него код очень красиво смотрится. 
Вот скачай и попробуй. Ах да, бесплатный. 
http://eclipse-cs.sourceforge.net/

Предлагаю идти от противного: "как писать нечитаемый код (гарантированная работа на всю жизнь ;-)"   

P.S. Только не надо писать что-то вроде "Из того, что на улице нет дождя, вовсе не следует, что на улице светит солнце". Это и так ясно.   

2 LSD  Извиняюсь за offtop, просто новую тему глупо создавать!! 
 Хотел узнать, а что означает эксепшн NullPointerException ?  У меня он выскакивает, но все работает!!

Samotnik, 
Thrown when an application attempts to use null in a case where an object is required. These include:
*Calling the instance method of a null object.
*Accessing or modifying the field of a null object.
*Taking the length of null as if it were an array.
*Accessing or modifying the slots of null as if it were an array.
*Throwing null as if it were a Throwable value.
Applications should throw instances of this class to indicate other illegal uses of the null object.



Шучу, по себе знаю, что иногда лучше спросить, чем самому искать ответ   

Entry_N3         Пасибо!  

ой, какая прелесть.  Смеялсо. 

niasilil,   

Нашёл тут у Джоэла довольно интересную статью (раньше почему-то её не видел, хотя написана была в мае 2005-го) - Как заставить неправильный код выглядеть неправильно, в которой автор последовательно описывает идею применения Венгерской Нотации (всем, кто как я не любит Венгерскую Нотацию, читать в обязательном порядке - есть дельные мысли, "реабилитирующие" её; жалею, что не потрудился найти и прочитать оригинальную статью Симони), а также о вреде исключений.
Не скажу, что на все 100% поддерживаю Джоэла, но разумные мысли явно имеют место быть.

да, почему-то я тоже на на 100% поддерживаю автора статьи... В частности, я думаю, что есть небольшое противоречие, между несоздаванием собстенного языка программирования и использованием венгерской нотации, т.к. некоторые могут фанатично подойти к этой концепции и превратить ее в жесткий стандарт, что и случилось с MS с системной венгерской... Но, такое соглашение должно быть в команде разработчиков, т.к., ИМХО, если делать всякие суффиксы понятные только кому-то одному из группы, то толку от этого ноль, т.к. делает код менее читабельным и понятным, придется тратить время на разборки что эти суффиксы означают, адаптироваться к стилю конкретного программиста, а это лишнее время и деньги... я думаю, что  самое простое, что, кстати, в JAVA всячески пропогандируется, это по-человечески называть переменные и константы, не нужно писать sVar или usVar, почему бы не написать просто safeVariable и unsafeVariable... Можно, конечно, такие вещи еще и строго типизировать, чтобы просто было нелья использовать код неправильно, но, я считаю, что в примере, о котором идет речь в статье, оборачивать строки свомими врапперами - совсем уж лишнее...

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

Особо про венгерскую нотацию: никогда не понимал, зачем делать свой код понятным для тех, кто не знает языка.


И ещё, похоже, человек не знает о существовании checked exceptions  Или относится к тем неумным людям, которые стремятся их не использовать.

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

Это сообщение отредактировал(а) w1nd - 14.7.2007, 13:40

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

эм.. что это? 

первая же ссылка...

а ссылочка битая однако  а вообще я уже нашел 

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

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