Почему операторы if if else else практически никогда не представлены в табличном формате?

if   i>0 : return sqrt(i)  
elif i==0: return 0  
else     : return 1j * sqrt(-i)

В.С.

if i>0:  
   return sqrt(i)  
elif i==0:  
   return 0  
else:  
   return 1j * sqrt(-i)  

Учитывая приведенные выше примеры, я не понимаю, почему я практически никогда не вижу первый стиль в базах кода. Для меня вы превращаете код в табличный формат, который ясно показывает, что вы хотите. Первый столбец можно практически игнорировать. Во втором столбце указывается условие, а в третьем столбце выводится требуемый результат. Кажется, по крайней мере, мне, прямолинейным и легко читаемым. Тем не менее, я всегда вижу, как эта простая ситуация с переключателем регистров появляется в расширенном формате с отступом табуляции. Почему это? Находят ли люди второй формат более читабельным?

Единственный случай, когда это может быть проблематично, это если код изменяется и становится длиннее. В этом случае я думаю, что вполне разумно реорганизовать код в длинный формат с отступом. Все ли делают это вторым способом просто потому, что так было всегда? Будучи защитником дьявола, я полагаю, что еще одна причина может заключаться в том, что люди находят два разных формата в зависимости от сложности утверждений if / else, чтобы сбивать с толку? Любое понимание будет оценено.

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

Несколько контрпримеров:

Haskell с охранниками и с узорами:

sign x |  x >  0        =   1
       |  x == 0        =   0
       |  x <  0        =  -1

take  0     _           =  []
take  _     []          =  []
take  n     (x:xs)      =  x : take (n-1) xs

Эрланг с узорами:

insert(X,Set) ->
    case lists:member(X,Set) of
        true  -> Set;
        false -> [X|Set]
    end.

Emacs lisp:

(pcase (get-return-code x)
  (`success       (message "Done!"))
  (`would-block   (message "Sorry, can't do it now"))
  (`read-only     (message "The shmliblick is read-only"))
  (`access-denied (message "You do not have the needed rights"))
  (code           (message "Unknown return code %S" code)))

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

Это более читабельно. Несколько причин почему:

• Почти каждый язык использует этот синтаксис (не все, большинство - ваш пример выглядит как Python)
• Исанаэ указал в комментарии, что большинство отладчиков основаны на строках (а не на операторах)
• Это начинает выглядеть еще более уродливым, если вам нужно встроить точки с запятой или фигурные скобки
• Читается сверху вниз более плавно
• Это выглядит ужасно нечитаемым, если у вас есть что-то кроме тривиальных операторов return
  • Любой значащий синтаксис отступа теряется, когда вы просматриваете код, поскольку условный код больше не визуально отделен (от Дэна Нили )
  • Это будет особенно плохо, если вы продолжите исправлять / добавлять элементы в 1-строчные операторы if
• Это только для чтения, если все ваши, если проверки имеют примерно одинаковую длину
• Это означает, что вы не можете форматировать сложные, если операторы в многострочные операторы, они должны быть однострочными
• Я гораздо более склонен замечать ошибки / логический поток при чтении по вертикали, не пытаясь разобрать несколько строк вместе
• Наш мозг читает более узкий и высокий текст НАМНОГО быстрее, чем длинный горизонтальный текст

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

Также люди неизбежно добавляют что-то вроде:

if i>0:  
   print('foobar')
   return sqrt(i)  
elif i==0:  
   return 0  
else:  
   return 1j * sqrt(-i)  

Это не займет много времени, прежде чем вы решите, что этот формат намного лучше, чем ваша альтернатива. Ах, но вы можете вставить все это в одну строку! Эндерланд умирает изнутри .

Или это:

if   i>0 : return sqrt(i)  
elif i==0 and bar==0: return 0  
else     : return 1j * sqrt(-i)

Что действительно очень раздражает. Никто не любит форматировать такие вещи.

И наконец, вы начнете священную войну проблемы «сколько места для вкладок». То, что идеально отображается на вашем экране в виде таблицы, может не отображаться на моем в зависимости от настроек.

В любом случае читаемость не должна зависеть от настроек IDE.

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

Когда я читаю код других людей, мне помогает то, что я придерживаюсь «нормальных» шаблонов, которые мои глаза учат распознавать. Я легко могу прочесть отступ в форме, потому что видел ее столько раз, что она регистрируется почти автоматически (с небольшими когнитивными усилиями с моей стороны). Это не потому, что оно «красивее», а потому, что оно следует соглашениям, к которым я привык. Конвенция бьет "лучше" ...

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

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

diff --git a/foo.rb b/foo.rb
index 40f7833..694d8fe 100644
--- a/foo.rb
+++ b/foo.rb
@@ -1,8 +1,8 @@
 class Foo

   def initialize(options)
-    @cached_metadata = options[:metadata]
-    @logger          = options[:logger]
+    @metadata = options[:metadata]
+    @logger   = options[:logger]
   end

 end

Теперь предположим, что тем временем в другой ветке программист добавил новую строку в блок выровненного кода:

diff --git a/foo.rb b/foo.rb
index 40f7833..86648cb 100644
--- a/foo.rb
+++ b/foo.rb
@@ -3,6 +3,7 @@ class Foo
   def initialize(options)
     @cached_metadata = options[:metadata]
     @logger          = options[:logger]
+    @kittens         = options[:kittens]
   end

 end

Слияние этой ветви не удастся:

wayne@mercury:/tmp/foo$ git merge add_kittens
Auto-merging foo.rb
CONFLICT (content): Merge conflict in foo.rb
Automatic merge failed; fix conflicts and then commit the result.

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

(Этот ответ был "плагиат" из моей собственной статьи, препятствующей выравниванию таблиц в коде).

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

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

Есть выражение «switch», которое предоставляет подобные вещи для особых случаев, но я думаю, это не то, о чем вы спрашиваете.

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

И есть смысл: ясность. Если его легче увидеть (а ваш первый пример не так легко увидеть, где находится разделитель:), отформатируйте его в соответствии с ситуацией. В противном случае придерживайтесь того, чего ожидают люди, поскольку это всегда легче распознать.

Если ваше выражение действительно простое, большинство языков программирования предлагают оператор?: Branching:

return  ( i > 0  ) ? sqrt( i)
      : ( i == 0 ) ? 0
        /* else */ : 1j * sqrt( -i )

Это короткий читаемый табличный формат. Но важная часть: я вижу с первого взгляда, что такое «главное» действие. Это ответное заявление! И стоимость определяется определенными условиями.

С другой стороны, если у вас есть ветки, которые выполняют другой код, я считаю, что для этих блоков гораздо удобнее читать. Потому что теперь есть разные «основные» действия в зависимости от оператора if. В одном случае мы бросаем, в одном случае мы регистрируем и возвращаем или просто возвращаем. В зависимости от логики существует различный программный поток, поэтому кодовые блоки инкапсулируют различные ветви и делают их более заметными для разработчика (например, быстрое чтение функции, позволяющей охватить программный поток)

if ( i > 0 )
{
    throw new InvalidInputException(...);
}
else if ( i == 0 )
{
    return 0;
}
else
{
    log( "Calculating sqrt" );
    return sqrt( -i );
}

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

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

Одна распространенная ошибка, к которой часто обращаются стандарты кодирования, - это маленькая ошибка:

if (x == 10)
    do_something();
    do_something_else();

Это не делает то, что вы думаете, что делает. Что касается C касается, если х 10 , то вы звоните do_something(), но затем do_something_else()вызывается независимо от значения х . Только действие, следующее за оператором if, является условным. Это может быть тем, что задумал кодер, и в этом случае есть потенциальная ловушка для сопровождающих; или это может быть не то, что задумал кодер, и в этом случае возникает ошибка. Это популярный вопрос интервью.

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

if (x == 10)
{
    do_something();
    do_something_else();
}

или же

if (x == 10)
{
    do_something();
}
do_something_else();

и теперь это работает правильно и понятно для сопровождающих.

Вы заметите, что это полностью несовместимо с форматом таблицы.

Некоторые другие языки (например, Python) рассмотрели эту проблему и решили, что, поскольку кодеры используют пробелы для ясности компоновки, было бы неплохо использовать пробелы вместо фигурных скобок. Так в Python,

if x == 10:
    do_something()
    do_something_else()

делает вызовы на оба do_something()и do_something_else()условно на x == 10, тогда как

if x == 10:
    do_something()
do_something_else()

означает, что только do_something()условно на х, и do_something_else()всегда вызывается.

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

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

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

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

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

if i==0: return 0
return i>0?sqrt(i):(1j*sqrt(-i))

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

return i>0  ? sqrt(i)       :
       i==0 ? 0             :
              1j * sqrt(-i)

Не нужно повторять returnкаждый раз :)