Куда поместить комментарии в конструкцию if-then-else?

Чтобы ответить на ваш обновленный вопрос:

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

Есть несколько причин, по которым это может произойти:

  • doSomething был вызван из файла JavaScript (без checkJs или @ts-check)
  • Поставляется объект, аналогичный Bar. Это то же самое структурно, но это не случай Bar.
  • Аргумент неверного типа был приведен к Bar другим разработчиком
  • Аргумент неверного типа был автоматически приведен к any (отсутствующие определения типа, потерянный вывод типа)
  • [1115 ] Аргумент неверного типа был утвержден как Bar плохо написанным защитником типа
  • Аргумент неверного типа был обработан как Bar, потому что его определение было дополнено где-то еще в вашем проекте
  • [ 1117] Ваш код был отправлен и использован в среде, где нет конвейера сборки, и поэтому не может существовать ошибок во время компиляции (например, распространяться в виде пакета UMD)
  • Объект или массив были индексированы с использованием не -существующий ключ (TypeScript предполагает, что он никогда не может быть undefined)
  • В миксе используется сомнительно типизированная часть стандартной библиотеки (например, Promise.resolve.call(1) будет выдавать во время выполнения, даже если TypeScript примет это)
33
задан Flip 31 October 2018 в 13:30
поделиться

5 ответов

Для меня комментарий выше эти IF объясняет IF сам оператор. Например, если протестированное условие особенно сложно.

комментарий А в блоке ниже IF или ELSE описывает то, что идет, как только условие было оценено, и выбор сделан.

Так как это:

//Is this a favoured customer and do we have a promotion?
if customer.special() and monthly.hasOffer() {
  //Add discount
  invoice.addDiscount();
} 
else {
  //Add note about favoured customer scheme
  invoice.addNotes(JOIN_OUR_DISCOUNT_SCHEME);
}
31
ответ дан 27 November 2019 в 18:32
поделиться

Я никогда не давал его, очень думал; лично и при необходимости я поместил комментарии выше ЕСЛИ и операторы ELSE. Это дает мне хорошее разделение между комментариями об операторах ветвления и комментариями о коде.

// comment about the if statement
if (expression)
{
    // comment about the code
    doSomething();
}
// comment about the else statement
else
{
    // comment about the code
    doSomethingElse();
}

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

6
ответ дан 27 November 2019 в 18:32
поделиться

Я сделал бы случай a), но с дополнительным битом пробела:

if (blabla) {
   // This explains the whole if case

   // Can comment here for specific block comments
   doThis();
} else {
   // This explains the else case

   // Same again
   doSomethingElse();
}
3
ответ дан 27 November 2019 в 18:32
поделиться

Используйте то, что имеет смысл Вам, я предполагаю (если Вы не работаете в соответствии со стандартом кодирования, который определяет стиль комментария). Лично я не использую (c), потому что это непоследовательно между первым и после случаев. Я действительно иногда использую (b), когда короткий комментарий сделает, но обычно я предпочитаю (a). Если я комментирую несколько подблоков в, если блок, я мог бы оставить пустую строку после комментария случая:

if (blabla) {
    // here's a comment about this case

    // comment about this bit of code
    bit_of_code();
    // comment about this other bit of code
    other_bit_of_code();
}

и так далее.

1
ответ дан 27 November 2019 в 18:32
поделиться

Лично, я findi это лучше для написания кода, который не требует небольших комментариев, в которых говорится "о, действительно делает x", сопровождаемый "DoX ()". При необходимости, вместо того, чтобы записать высказывание комментария "делают x из-за y", я предпочел бы писать метод под названием "DoXBecauseOfY". Если более поздний рефакторинг удаляет часть "BecauseOfY", то все еще имеет лучший смысл помещать комментарий перед если оператор, документируя полную логику.

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

2
ответ дан 27 November 2019 в 18:32
поделиться
Другие вопросы по тегам:

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