Как выполнить сразу два события jquery [duplicate]

Если это что-то маленькое, напишите его следующим образом:

if(foo()) bar();

Если достаточно длинного разбить на две строки, используйте фигурные скобки.

Я согласен с тем, что «если вы достаточно умны, чтобы заставить кого-то платить вам за код, вы должны быть достаточно умны, чтобы не полагаться исключительно на отступ, чтобы увидеть поток кода».

Однако ... ошибки могут быть сделаны, и эта боль - это отладка ... особенно если вы смотрите на чужой код.

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

Некоторые могут сказать, что это случай предпочтения, но я считаю логический поток программы намного легче следовать, если он внутренне согласован , и я не считаю, что он согласен написать один оператор IF, как это:

if(x < y)
    x = y;
else
    y = x;

И еще один такой:

if(x < y)
{
    x = y;
    x++;
}
else
{
    y = x;
    y++;
}

Я предпочитаю просто выбрать один общий стиль и придерживаться его:)

Допустим, у вас есть код:

if (foo)
    bar();

, а затем кто-то еще приходит и добавляет:

if (foo)
    snafu();
    bar();

Согласно тому, как это написано, bar (); теперь выполняется безоговорочно. Включая фигурные скобки, вы предотвращаете такую ​​случайную ошибку. Код должен быть написан таким образом, чтобы сделать такие ошибки сложными или невозможными. Если бы я делал обзор кода и видел отсутствующие фигурные скобки, особенно разбросанные по нескольким строкам, я бы создал дефект. В тех случаях, когда это оправдано, держите его на одной линии, чтобы вероятность сделать такую ​​ошибку снова сведена к минимуму.

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

Еще одна веская причина всегда используя фигурные скобки, помимо того, что кто-то добавляет второй оператор в if, может произойти что-то подобное:

if(a)
   if(b)
     c();
else
   d();

Вы заметили, что предложение else на самом деле относится к «if (b)»? Вы, вероятно, сделали это, но можете ли вы кому-либо быть знакомы с этой информацией?

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

Чтобы быть тупым, я вижу это как:

Хорошие программисты програмируют оборону, Bad программисты этого не делают.

Так как есть несколько примеров выше, и мой собственный подобный опыт с связанными ошибками чтобы забыть скобки, я узнал, как трудно ВСЕГДА ОТКРЫТЬ БРАКЫ.

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

Джоэл даже упоминает об этом в Нарушение неправильного кода

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

Линии дешевы. Мощность процессора дешева.

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

( a) Легко для любого другого разработчика следить за тем, что я делаю

(b) Комментировать определенные части кода, которые могут ему понадобиться

(c) Легко отлаживать, если что-то пойдет не так

(d) Легко модифицировать, если это необходимо в будущем (например, добавление / удаление кода)

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

Отключив фигурные скобки в большинстве случаев, для меня это делает (b), (c) и (d) более сложно (отметим, что это не невозможно). Я бы сказал, что использование фигурных скобок или нет не влияет на (a).

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

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

Если у меня есть однострочный , Я обычно форматирую его следующим образом:

if( some_condition ) { do_some_operation; }

Если строка слишком громоздка, то используйте следующее:

if( some_condition )
{
    do_some_operation;
}

В большинстве случаев он укореняется в качестве стандарта кодирования, будь то для компании или проекта FOSS.

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

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

Используйте какое-то личное мнение.

if (foo)
  bar();

отлично работает. Если вы действительно не беспокоитесь о том, что идиоты вносят что-то подобное позже:

if (foo)
  bar();
  baz();

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

Взамен это намного более читаемо.

Остальное время:

if (foo) {
  bar();
  baz();
}

Который был моим фаворитом, насколько я помню. Дополнительно:

if (foo) {
  bar();
  baz();
} else {
  qux();
}

Работает для меня.

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

Я был большим сторонником «фигурных скобок - это НЕОБХОДИМО!», но, начиная с принятия модульного тестирования, я обнаружил, что мои модульные тесты защищают бесцельные заявления из сценариев, таких как:

if (foo)
    snafu();
    bar();

С хорошими модульными тестами я могу уверенно пропускать фигурные скобки для простых операторов, чтобы улучшить читаемость (да, это может быть субъективным).

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

if (foo) snafu();

Таким образом, разработчик, которому нужно добавить bar () в условие, будет более склонным распознавать отсутствие фигурных скобок и добавить их.

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

Я обычно опускаю их, когда они не нужны, за исключением некоторых случаев, подобных следующим:

if (something)
    just one statement; // i find this ugly
else
{
    // many
    // lines
    // of code
}

Я предпочитаю

if (something)
{
    just one statement; // looks better:)
}
else
{
    // many
    // lines
    // of code
}

Это не всегда считается плохой практикой. Mono Project Coding Guidelines предлагает не использовать фигурные скобки, если это необязательно. То же самое для стандартов кодирования GNU . Я думаю, что это вопрос личного вкуса, как всегда, со стандартами кодирования.

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

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

Я вижу это как аргумент для if ( foo == 0 ) vs if ( 0 == foo ). Последнее может предотвратить ошибки для новых программистов (и, возможно, даже изредка для ветеранов), в то время как первое проще быстро читать и понимать, когда вы поддерживаете код.

Я очень доволен:

foreach (Foo f in foos)
  foreach (Bar b in bars)
    if (f.Equals(b))
      return true;

return false;

Лично я не понимаю, почему

foreach (Foo f in foos)
{
  foreach (Bar b in bars)
  {
    if (f.Equals(b))
    {
      return true;
    }
  }
}

return false;

читаем больше.

Да, строки бесплатны, но почему мне приходится прокручивать страницы и страницы кода, когда это может быть вдвое меньше?

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

Кроме того, я всегда помещает скобки для вложенных if, где у меня есть вложенный

if (condition1)
  if (condition2)
    doSomething();
  else (condition2)
    doSomethingElse();

vs

if (condition1)
  if (condition2)
    doSomething();
else (condition2)
  doSomethingElse();

ужасно запутанно, поэтому я всегда пишу его как:

if (condition1)
{
  if (condition2)
    doSomething();
  else (condition2)
    doSomethingElse();
}

По возможности я использую тернарные операторы, но I never гнездятся в них .

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

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

Например:

for (...)
{
  for (...)
    for (...) 
    {
      // a couple pages of code
    }
  // which for block is ending here?  A good text editor will tell you, 
  // but it's not obvious when you're reading the code
}

Один из примеров, когда это может вас укусить, - это в старые времена макросов C / C ++. Я знаю, что это вопрос C #, но часто стандарты кодирования переносятся без оснований, по которым стандарт был создан в первую очередь.

Если вы не очень осторожны при создании своих макросов, вы можете закончить что вызывает проблемы с операторами if, которые не используют {}.

#define BADLY_MADE_MACRO(x) function1(x); function2(x);

if (myCondition) BADLY_MADE_MACRO(myValue)

Теперь, не поймите меня неправильно, я не говорю, что вы всегда должны {} просто избегать этого проблема в C / C ++, но из-за этого мне пришлось иметь дело с некоторыми очень странными ошибками.