Чому висловлювання "if elif else" практично ніколи не бувають у форматі таблиці?

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

VS

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)
• isanae зазначив у коментарі, що більшість налагоджувачів на основі рядків (не на основі заяви)
• Це починає виглядати ще більш потворно, якщо вам доведеться вставляти крапки з комою або дужки
• Він читається зверху вниз більш плавно
• Це виглядає жахливо нечитабельним , якщо у вас є що - небудь, крім тривіальних тверджень повернення
  • Будь-який значущий синтаксис відступу втрачається, коли ви знімаєте код, оскільки умовний код більше не візуально відокремлений (від Dan Neely )
  • Це буде особливо погано, якщо ви продовжуєте виправляти / додавати елементи в 1-й рядок, якщо заяви
• Це читається лише у тому випадку, якщо всі ваші, якщо чеки, приблизно однакової довжини
• Це означає, що ви не можете форматувати складні, якщо висловлювання у багаторядкові оператори, вони повинні бути однолінійними
• Я набагато частіше помічаю помилки / логічний потік, читаючи вертикально по черзі, не намагаючись проаналізувати кілька рядків разом
• Наші мізки читають вузький і високий текст НАШЕ швидше, ніж довгий горизонтальний текст

Щоразу, коли ви спробуєте зробити що-небудь із цього, ви в кінцевому підсумку переписуєте його у багаторядкові висловлювання. Що означає, що ви просто витратили час!

Також люди неминуче додають щось на кшталт:

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.

Якби модифікований код не використовував табличне вирівнювання, злиття було б успішним автоматично.

(Ця відповідь була "плагіатом" з моєї власної статті, що відлякує табличне вирівнювання в коді).

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

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

Є твердження "перемикач", яке забезпечує подібні речі для особливих випадків, але я думаю, що це не те, про що ви питаєте.

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

І є сенс: ясність. Якщо це полегшує перегляд (і ваш перший приклад непростий, щоб побачити, де знаходиться роздільник), відформатуйте його відповідно до ситуації. Інакше дотримуйтесь того, чого очікують люди, оскільки це завжди легше розпізнати.

Якщо ваше вираження справді таке просто, більшість мов програмування пропонують оператор розгалуження ?:

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 );
}

Як уже говорив Ендерленд, ви припускаєте, що у вас є лише одне "повернення" як дії, і ви можете позначити це "повернення" в кінці умови. Я хотів би розповісти додаткову деталь, чому це не буде успішним.

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

Однією популярною помилкою, до якої часто звертаються стандарти кодування, є ця маленька дітка: -

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

Це не робить те, що ви думаєте, що це робить. Що стосується C, якщо x дорівнює 10, то ви дзвоните do_something(), але потім do_something_else()отримуєте виклик незалежно від значення x . Умови лише дії, що безпосередньо йде за твердженням "якщо". Це може бути те, що кодер задумав, і в цьому випадку існує потенційна пастка для обслуговуючого персоналу; або це може бути не те, що кодер задумав, і в цьому випадку помилка. Це популярне запитання про інтерв'ю.

Рішення в стандартах кодування полягає в призначенні дужок навколо всіх умовних дій, навіть якщо вони однолінійні. Зараз ми отримуємо

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 i==0: return 0
return i>0?sqrt(i):(1j*sqrt(-i))

Я не бачу нічого поганого у форматі таблиці. Особисті переваги, але я б користувався таким потрійником:

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

Не потрібно повторювати returnкожен раз :)