если (условие) продолжается; ИЛИ если (! условие) {…}? (разработайте предпочтение),

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

JTextField text = new JTextField();
text.addKeyListener(new KeyListener {
    @Overwrite
    public void keyPressed(event e) {
        if(e.keyCode = SWT.CR) { // SWT.CR is key code of Enter
            // Call your function
        }
    }
}

Программа будет прослушивать событие клавиатуры. Когда вы нажимаете ENTER, функция внутри слушателя запускается.

5
задан 3 revs, 2 users 100% 4 April 2010 в 05:37
поделиться

22 ответа

В принципе я соглашаюсь с большинством, кто предпочитает стиль 1. Это - то, что Steve Mcconnell подтверждает в "Коде, Завершенном" - говорят, что Вы имеете в виду, т.е. если Вы больше интересуетесь условием, являющимся верным, в то время как ложное состояние более редко или не предпочтительно, затем заявите предпочтительную версию.

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

8
ответ дан 18 December 2019 в 05:11
поделиться

Я нахожу стиль 1 более легким для следования. Таким образом, я предпочитаю стиль 1.

0
ответ дан 18 December 2019 в 05:11
поделиться

Пункт охраны работает хорошо на условный функциональный возврат, потому что он создает законченное высказывание. В одном glace Вы знаете то, что продолжается (мы сделаны здесь).

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

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

0
ответ дан 18 December 2019 в 05:11
поделиться

Мое предпочтение было бы Стилем 1, но я буду использовать Стиль 2 в heartbeat если! parseMsg или! processMsg произошел, как правило. Всегда помещайте наиболее вероятный сценарий сначала - право?

0
ответ дан 18 December 2019 в 05:11
поделиться

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

  • специальная успешность или неуспешность каждого шага, или
  • имейте каждый возврат функции перехода следующее состояние

какой бы ни более ясно.

0
ответ дан 18 December 2019 в 05:11
поделиться

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

0
ответ дан 18 December 2019 в 05:11
поделиться

Первый стиль, конечно, более ясен - он говорит, что Вы (по-видимому) средний, т.е., получите сообщение, и если parseMsg флаг установлен, затем попытайтесь проанализировать его; если это успешно, обработайте его. С другой стороны, вторая версия собирается обработать значительно меньше инструкций, особенно если parseMsg установлен. Я испытал бы желание пойти на полпути между двумя:

while (!String.IsNullOrEmpty(msg = reader.readMsg())){
    RaiseMessageReceived();

    if (!parseMsg) continue ;

    ParsedMsg parsedMsg = parser.parseMsg(msg);
    RaiseMessageParsed();
    if (processMsg){
       process(parsedMsg);
       RaiseMessageProcessed();
    }
}

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

0
ответ дан 18 December 2019 в 05:11
поделиться

Я предпочитаю стиль 1 с расположением с отступом, это более чисто, и легче понять только путем рассмотрения его, я вижу расположение кода.

0
ответ дан 18 December 2019 в 05:11
поделиться

Избежать continue операторы, если это возможно.

Мы избегаем goto как можно больше, не делайте мы - не делаем этого, также имеют смысл избегать, чтобы это был кузен continue?

0
ответ дан 18 December 2019 в 05:11
поделиться

Хотя я предпочитаю стиль 1. Я нахожу полезным использовать стиль 2 иногда, поскольку полезно снизить уровень добавления отступа и сделать код немного легче читать.

Любой стиль хорош честно говоря, это действительно до личного выбора.

1
ответ дан 18 December 2019 в 05:11
поделиться

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

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

0
ответ дан 18 December 2019 в 05:11
поделиться

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

1
ответ дан 18 December 2019 в 05:11
поделиться

Я лично предпочитаю стиль 2 по ряду причин;

  • Можно поразить potention ошибку, где Вы делаете отступ после, если, но забывают фигурные скобки.

  • У Вас еще есть меньше риска удара плавания, проблема, т.е. с несколькими вложила IFS, можно запутаться, с, которым если еще принадлежит данный.

  • Вы избегаете чрезмерного расположения с отступом, которое может вести для кодирования ухода страницы

Когда я кодирую это, я склонен помещать продолжение на отдельную строку;

if (!parseMsg) 
    continue;

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

2
ответ дан 18 December 2019 в 05:11
поделиться

Стиль 1 просто БОЛЕЕ ЯСЕН, по моему скромному мнению. Ничто против Не Продолжается по сути, но как люди сказали ранее, добавление отступа делает для более легкого следующего.

2
ответ дан 18 December 2019 в 05:11
поделиться

В показанном примере я пошел бы со стилем 1. Если бы мой метод был достаточно большим, что вложение стало проблемой (и не было лучшего способа осуществить рефакторинг код), то я рассмотрел бы стиль 2. Но для просто двух компактных показанных случаев, определенно разработайте 1.

2
ответ дан 18 December 2019 в 05:11
поделиться

Я хочу Осуществить рефакторинг этот код в другом направлении. Ваш код делает слишком много вещей!

  1. Чтение входа
  2. Итерация
  3. Повышение уведомлений
  4. Парсинг (условно! (с уведомлением!!))
  5. Обработка (условно! (с уведомлением!!))

Я думаю, что нам нужно некоторое разделение здесь. Я хочу исследовать:

3
ответ дан 18 December 2019 в 05:11
поделиться

Я предпочитаю Style2. Кроме того, тот же образец описан в Замене Refactoring.com Вложенные Условия

3
ответ дан 18 December 2019 в 05:11
поделиться

Я определенно предпочитаю первую версию. continue оператор очень хорош при отсутствии злоупотребления.

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

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

4
ответ дан 18 December 2019 в 05:11
поделиться

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

(!String.IsNullOrEmpty(msg = reader.readMsg()))

Вы только делаете это из-за изворотливого поведения читателя - почему читатель дает Вам несообщение, чтобы указать, что чтение сделано? Вот альтернатива с лучшим разработанным средством чтения:

while (reader.HasMessage())
{
  string msg = reader.GetMessage();
  HandleMessage(msg);
}
5
ответ дан 18 December 2019 в 05:11
поделиться

Я предпочитаю Стиль 2 - с продолжать оператором.

13
ответ дан 18 December 2019 в 05:11
поделиться

Я предпочитаю Стиль 1 - с расположением с отступом.

22
ответ дан 18 December 2019 в 05:11
поделиться

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

стиль 2 управляет сложностью и таким образом масштабируется к более сложным методам, разработайте 1, быстро становится неуправляемо сложным.

2
ответ дан 18 December 2019 в 05:11
поделиться
Другие вопросы по тегам:

Похожие вопросы: