Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > Java: Общие вопросы > Советы по хорошему стилю


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

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

public void setWeight( float weight ) {
    if ( weight >= 0 )
        this.weight = weight;
}

лучше:
Код

public void setWeight( float weight ) {
    if ( weight >= 0 )
        this.weight = weight;
    else
        throw new IllegalArgumentException("Weight must be >= 0");
}


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

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

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

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

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


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

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

Автор: val 14.6.2007, 09:47
Цитата

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


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

Автор: Maksym 14.6.2007, 12:30
Цитата(val @  14.6.2007,  09:47 Найти цитируемый пост)
Кроме того, exception зачастую подразумевает исключительную ситуацию, которая связана с принципиально непреодалимой ошибкой.

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

Автор: w1nd 14.6.2007, 13:01
Цитата(nornad @  14.6.2007,  03:01 Найти цитируемый пост)
2. При переопределении метода equals() надо переопределять ещё и hashCode(). Причём хэшкод должен быть равен для объектов, если они эквивалентны (equals() == true).

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

Автор: nornad 14.6.2007, 19:24
Цитата(Maksym @  14.6.2007,  15:30 Найти цитируемый пост)
Я согласен с тем, как в своем примере этот механизм применил nornad.

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

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

Цитата(RebornCrusader @  14.6.2007,  11:19 Найти цитируемый пост)
Второй пунк описан в каждом учебнике по Java.

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

Цитата(w1nd @  14.6.2007,  16:01 Найти цитируемый пост)
Дополню. Если создаётся наследник класса, в котором переопределёны equals() и hashCode(), в классе наследнике их следует переопределить обязательно.

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

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

Цитата(RebornCrusader @  14.6.2007,  11:19 Найти цитируемый пост)
И пара придирок к вашему коду: на мой взгляд, охватывающие скобки "{}" в if следует ставить всегда, когда условие тривиально и не входит в единственную строчку.

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

if ( 1 )
  if ( 2 )
    if ( 3 )
      // do 1
  else
    // do 2

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

if ( 1 )
  if ( 2 ) {
    if ( 3 )
      // do 1
  } else
    // do 2

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

Цитата(RebornCrusader @  14.6.2007,  11:19 Найти цитируемый пост)
P.S. Хорошая тема, надо развивать. Только нужно структурирование.
Люди пишут программу, отмечают "тру-решение" или наоборот , постят сюда - только кто возьмётся за сортировку?

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

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

плохо:
Код

    private final static String SOME_STRING = "SOME_STRING";
    public boolean myCompare(String s)
    {
        return s.equals(SOME_STRING);
    }


хорошо:
Код

    private final static String SOME_STRING = "SOME_STRING";
    public boolean myCompare(String s)
    {
        return SOME_STRING.equals(s);
    }

Автор: nornad 14.6.2007, 20:58
Цитата(powerOn @  14.6.2007,  23:49 Найти цитируемый пост)
Если у вас в коде есть константа и переменная типа String, которые нужно сравнить, то всегда вызывайте метод equails на константе

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

    public boolean myCompare(String s)
    {
        return "SOME_STRING".equals(s);
    }


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

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

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

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

Автор: y3u 14.6.2007, 21:47
Цитата

 private final static String SOME_STRING = "SOME_STRING";


missorted modifiers, private string constant...

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

Цитата

 public static final String SOME_STRING = "SOME_STRING";

Автор: powerOn 14.6.2007, 22:02
Цитата(nornad @  14.6.2007,  21:58 Найти цитируемый пост)
Иногда нет необходимости выделять константу в собственное поле (по-хорошему, всё же лучше выделить), но совет всё равно стоит использовать:

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

Цитата(nornad @  14.6.2007,  21:58 Найти цитируемый пост)
Все строковые константы желательно выделять в поля. Это относится к дефолтовым значениям строковых полей, названиям кнопок, страниц и панелей.

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

Добавлено через 41 секунду
Цитата(y3u @  14.6.2007,  22:47 Найти цитируемый пост)
я бы сделал так

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

Автор: Maksym 14.6.2007, 22:05
nornad
Цитата(nornad @  14.6.2007,  20:58 Найти цитируемый пост)
Все константы (любого типа) желательно выделять в поля. Исключения - пустая строка, 0 и т.п. 

А чем 0 лучше других чисел?
Цитата(nornad @  14.6.2007,  20:58 Найти цитируемый пост)
Это относится к дефолтовым значениям строковых полей, названиям кнопок, страниц и панелей.

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

Автор: nornad 14.6.2007, 22:25
Цитата(Maksym @  15.6.2007,  01:05 Найти цитируемый пост)
А чем 0 лучше других чисел?

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

Автор: Maksym 14.6.2007, 22:37
Цитата(nornad @  14.6.2007,  22:25 Найти цитируемый пост)
Тем же, чем и пустая строка "лучше" остальных строк.

Пустую строку не использую как константу, просто потому что это не читабельно (непонятно, что она должна означать), а строковая константа своим значением как правило несет какой-то смысл тому, кто читает код.
Цитата(nornad @  14.6.2007,  22:25 Найти цитируемый пост)
То есть, если 0 используется для проверки на пустоту списка (по количеству элементов), то не стоит его выносить в отдельное поле.

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



Автор: RebornCrusader 15.6.2007, 07:44
Цитата(nornad @  15.6.2007,  03:24 Найти цитируемый пост)
Если честно, не понял. Опиши шире, что ты имеешь в виду.

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

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

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

Цитата(Maksym @  15.6.2007,  06:05 Найти цитируемый пост)
Думаю, эти вещи нужно не выделять в поля, а хранить в properties файле и доставать через ResourceBundle.

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

private static final ResourceBundle RESOURCE_BUNDLE = ResourceBundle.getBundle("my.cool.project.MegaClass");
private static final String BUTTON_ADD = RESOURCE_BUNDLE.getString("button.add");

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

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

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

Автор: nornad 15.6.2007, 20:16
Цитата(RebornCrusader @  15.6.2007,  10:44 Найти цитируемый пост)
Для начала можно просто в начале темы.

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

Цитата(RebornCrusader @  15.6.2007,  10:44 Найти цитируемый пост)
И вообще я согласен с тезисом, что даже на глубоко тривиальные иногда нужно указать - не всегда они приходят легко и сразу.

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

Цитата(RebornCrusader @  15.6.2007,  10:44 Найти цитируемый пост)
Только если уверен, что завтра они не понадобятся ;)

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

Цитата(RebornCrusader @  15.6.2007,  10:44 Найти цитируемый пост)
К слову о константах. Читая книжки, натыкаешься чуть ли не на холивары на тему - должны быть они public или private. Хотя на самом деле всё просто - как и остальные члены класса, они должны иметь тот модификатор, который соответствует их необходимости для наследников или внешних классов.

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

Автор: JUncle 15.6.2007, 20:30
Цитата(RebornCrusader @  14.6.2007,  08:19 Найти цитируемый пост)
 охватывающие скобки "{}" в if следует ставить всегда, когда

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

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

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

Автор: nornad 16.6.2007, 00:48
Цитата(JUncle @  15.6.2007,  23:30 Найти цитируемый пост)
1 тоже можно отнести. 

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

Автор: w1nd 16.6.2007, 02:28
Цитата(nornad @  16.6.2007,  00:48 Найти цитируемый пост)
Можно тогда пример, в каких случаях 1 говорит сама за себя?

Код
// вытаскиваем поля из строки ResultSet
for (int i = 1; i <= count; i++) {
}

или
Код
// Рисуем
graphics.drawLine(x, y, x + width - 1, y + height - 1);

или
Код
// Делим jndi-имя
if (name.size() > 0) {
    remainingName = name.getSuffix(1);
    name = name.getPrefix(1);
}
else {
    remainingName = name.getSuffix(0);
    name = name.getPrefix(0);
}


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

Автор: RebornCrusader 16.6.2007, 11:22
Цитата(JUncle @  16.6.2007,  04:30 Найти цитируемый пост)
Нет. Охватывающие скобки нужно ставить всегда!

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

public void setWidth(int width) {
    if (width < 0) throw new IllegalArgumentException();
    this.width = width;
}

ИЛИ
Код

public void setWidth(int width) {
    if (width < 0) {
        throw new IllegalArgumentException();
    }
    this.width = width;
}


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

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

Автор: JUncle 16.6.2007, 16:58
Цитата(RebornCrusader @  16.6.2007,  11:22 Найти цитируемый пост)

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

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


Цитата(RebornCrusader @  16.6.2007,  11:22 Найти цитируемый пост)
 А если ещё подобных методов-сеттеров много?

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

Цитата(RebornCrusader @  16.6.2007,  11:22 Найти цитируемый пост)
Какой код, по-вашему читается легче?

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

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

Автор: w1nd 16.6.2007, 19:16
Цитата(RebornCrusader @  16.6.2007,  11:22 Найти цитируемый пост)
Какой код, по-вашему читается легче? 

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

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

Автор: Stampede 16.6.2007, 22:42
Цитата(JUncle @  15.6.2007,  11:30 Найти цитируемый пост)
Нет. Охватывающие скобки нужно ставить всегда!
Объяснение простое - тому, кто поддерживает код - будет гораздо легче вставить в блок какие-то операторы, чем сначала обрамлять в скобки, а потом... Да и от многих непоняток уберегает.


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

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

Код

if (field.isVisible())
    field.setWidth(DEFAULT_WIDTH);
redraw();


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

Код

if (field.isVisible())
    // field.setWidth(DEFAULT_WIDTH);
redraw();


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

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

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

Автор: v2v 16.6.2007, 22:56
Stampede, привёл очень хороший пример.
Я и сам
Цитата

А уж при написании собственного кода так вообще создаю блок "на автомате".

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

if (width < 0) {
   // do something    
   System.out.println("Data error!");
}

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

if (width < 0) 
{
  // do something   
  printf("Data error!");
}

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

Автор: nornad 16.6.2007, 23:41
Цитата(v2v @  17.6.2007,  01:56 Найти цитируемый пост)
Почему в ява первая скобка не пишется с новой строки?

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

Автор: Samotnik 17.6.2007, 01:59
Цитата(v2v @  16.6.2007,  22:56 Найти цитируемый пост)
Почему в ява первая скобка не пишется с новой строки?

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

Автор: RebornCrusader 17.6.2007, 02:26
Цитата(Stampede @  17.6.2007,  06:42 Найти цитируемый пост)
 При этом нередко одиночный стейтмент превращается во множественный и наоброт, и если полагаться на безблочную запись, то можно по невнимательности запросто сломать логику работы условия. Особенно этому способствуют закомментирывания/раскомментирывания строк. Вот смотрите:

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

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

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


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

void doSomething(int a)
{ // здесь куча места для комментария к функции



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

Добавлено @ 02:29
Цитата(w1nd @  17.6.2007,  03:16 Найти цитируемый пост)
Разумеется тот, который со скобками ;)

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

Добавлено через 10 минут и 25 секунд
Цитата(v2v @  17.6.2007,  06:56 Найти цитируемый пост)
Почему в ява первая скобка не пишется с новой строки? И при просмотре кода проще контролировать где "потерялася" какая то скобка.

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

Автор: FcUK 18.6.2007, 18:07
чесно говоря..все это хорошо....но есть http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html написан в далеком 1999 году + есть Maintainability Index програмы...если он больше 100 - значит код хорошый..если менше - увы...

Автор: niasilil 18.6.2007, 19:40
Цитата(FcUK @ 18.6.2007,  18:07)
чесно говоря..все это хорошо....но есть http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html написан в далеком 1999 году + есть Maintainability Index програмы...если он больше 100 - значит код хорошый..если менше - увы...

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

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

Автор: nornad 18.6.2007, 20:18
Цитата(FcUK @  18.6.2007,  21:07 Найти цитируемый пост)
но есть  Code Conventions for the JavaTM Programming Language

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

Автор: val_vp 20.6.2007, 11:12
Прочитал и офигел как много копий ломается о скобки smile
а рекомендации по хорошему стилю уже давно выработаны как общие:
Цитата

есть  Code Conventions for the JavaTM Programming Language написан в далеком 1999 году

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

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

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

Автор: batigoal 20.6.2007, 11:30
Цитата(val_vp @  20.6.2007,  12:12 Найти цитируемый пост)
Прочитал и офигел как много копий ломается о скобки smile
а рекомендации по хорошему стилю уже давно выработаны как общие:

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

Автор: val_vp 20.6.2007, 11:58
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);

Автор: _Y_ 20.6.2007, 11:59
Цитата(niasilil @ 18.6.2007,  19:40)
Для eclipse есть очень Checkstyle плагин

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

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

Автор: batigoal 20.6.2007, 12:31
Есть еще, кстати, http://jalopy.sourceforge.net/, тоже неплохая вещь.

Автор: nornad 20.6.2007, 14:26
Цитата(val_vp @  20.6.2007,  14:12 Найти цитируемый пост)
можно еще добааить в свете Java5 
не злоупотреблять boxing/unboxing

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

Автор: LSD 20.6.2007, 14:30
Всем любителям выносить все в константы рекомендую почитать http://worsethanfailure.com/Articles/Enterprise_SQL.aspx статейку smile

Автор: fixxer 20.6.2007, 14:31
Цитата(nornad @ 20.6.2007,  14:26)
Цитата(val_vp @  20.6.2007,  14:12 Найти цитируемый пост)
можно еще добааить в свете Java5 
не злоупотреблять boxing/unboxing

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

Код

List<Integer> list = new ArrayList<Integer>();
list.add(3);
list.add(2);
list.add(1);
list.remove(1); //Внимание!


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

Автор: LSD 20.6.2007, 14:34
Цитата(nornad @  20.6.2007,  15:26 Найти цитируемый пост)
Ну, не знаю, насколько это актуально. В 5-ой и 6-ой жабе автобоксинг - вполне нормальная штука и делать явное приведение, имхо, глупо. Посему хотелось бы узнать - зачем?

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

Добавлено через 2 минуты и 18 секунд
Цитата(fixxer @  20.6.2007,  15:31 Найти цитируемый пост)
Вы можете на вскидку сказать, что удалиться из списка, первый элемент или Integer со значанием 1?

Я смог smile

Автор: nornad 20.6.2007, 15:23
Цитата(fixxer @  20.6.2007,  17:31 Найти цитируемый пост)

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

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

Автор: niasilil 22.6.2007, 02:41
Цитата(_Y_ @ 20.6.2007,  11:59)
Цитата(niasilil @ 18.6.2007,  19:40)
Для eclipse есть очень хороший Checkstyle плагин

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

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

Автор: Entry_N3 22.6.2007, 22:21
Предлагаю идти от противного: "http://www.nestor.minsk.by/sr/2006/02/sr60201.html"  smile 

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

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

Автор: Entry_N3 23.6.2007, 00:17
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.

user posted image

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

Автор: Samotnik 23.6.2007, 00:42
Entry_N3     smile    Пасибо!  

Автор: niasilil 3.7.2007, 01:34
Цитата(Entry_N3 @ 22.6.2007,  22:21)
Предлагаю идти от противного: "http://www.nestor.minsk.by/sr/2006/02/sr60201.html"  smile 

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

Автор: Entry_N3 3.7.2007, 22:14
niasilil,  smile 

Автор: nornad 13.7.2007, 22:20
Нашёл тут у Джоэла довольно интересную статью (раньше почему-то её не видел, хотя написана была в мае 2005-го) - http://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, в которой автор последовательно описывает идею применения Венгерской Нотации (всем, кто как я не любит Венгерскую Нотацию, читать в обязательном порядке - есть дельные мысли, "реабилитирующие" её; жалею, что не потрудился найти и прочитать оригинальную статью Симони), а также о вреде исключений.
Не скажу, что на все 100% поддерживаю Джоэла, но разумные мысли явно имеют место быть.

Автор: y3u 14.7.2007, 12:25
Цитата(nornad @  13.7.2007,  23:20 Найти цитируемый пост)
Нашёл тут у Джоэла довольно интересную статью (раньше почему-то её не видел, хотя написана была в мае 2005-го) - Как заставить неправильный код выглядеть неправильно, в которой автор последовательно описывает идею применения Венгерской Нотации (всем, кто как я не любит Венгерскую Нотацию, читать в обязательном порядке - есть дельные мысли, "реабилитирующие" её; жалею, что не потрудился найти и прочитать оригинальную статью Симони), а также о вреде исключений.
Не скажу, что на все 100% поддерживаю Джоэла, но разумные мысли явно имеют место быть. 


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

Автор: w1nd 14.7.2007, 12:58
Цитата
Но если вы так сильно убеждены, что Венгерская Нотация это Плохая Штука и что обработка исключений является лучшим изобретением человечества после шоколадного молочного коктейля, и вы даже не хотите слышать любых других мнений <...>

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

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

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

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

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

Автор: nornad 14.7.2007, 15:58
Цитата(w1nd @  14.7.2007,  15:58 Найти цитируемый пост)
Любым инструментом нужно уметь пользоваться. Высказывания навроде "этот инструмент плох, потому что я не умею им пользоваться" или  "этот инструмент плох, потому что многие не умеют им пользоваться" просто смешны

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

Автор: goodday1941 14.7.2007, 17:03
Цитата(w1nd @  14.7.2007,  12:58 Найти цитируемый пост)
checked exceptions

эм.. что это? smile

Автор: y3u 14.7.2007, 18:13
Цитата(goodday1941 @  14.7.2007,  18:03 Найти цитируемый пост)
эм.. что это? 


http://justfuckinggoogleit.com/search.pl?query=checked+exceptions

Автор: goodday1941 14.7.2007, 21:30
Цитата(y3u @  14.7.2007,  18:13 Найти цитируемый пост)
Цитата(goodday1941 @  14.7.2007,  18:03 )эм.. что это? первая же ссылка...

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

Автор: y3u 14.7.2007, 21:53
Цитата(goodday1941 @  14.7.2007,  22:30 Найти цитируемый пост)
а ссылочка битая однако  а вообще я уже нашел  


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

Автор: w1nd 16.7.2007, 07:07
Цитата(nornad @  14.7.2007,  15:58 Найти цитируемый пост)
Тот же камень можно бросить и в ваш огород, сэр.

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

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)