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

Question

Мои коллеги говорят мне, что табличное форматирование кода плохое и не читаемое, и я должен следовать соглашениям. Что такого плохого в табличном форматировании? Почему это запрещено?

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

Примеры (не реальный код):

if (res == ResultType.Failure)               
  something = ProcessFailure(..);
if (res == ResultType.ScheduledAndMonitored) 
  something = DoSomething(...) && DoSomething3(..);
if (res == ResultType.MoreInfoAvailable)     
  info = GetInfo(..);
if (res == ResultType.OK && someCondition)   
  something = DoSomething2(..);
.... continued

против

if (res == ResultType.Failure)               something = ProcessFailure(..);
if (res == ResultType.ScheduledAndMonitored) something = DoSomething(...) && DoSomething3(..);
if (res == ResultType.MoreInfoAvailable)     info      = GetInfo(..);
if (res == ResultType.OK && someCondition)   something = DoSomething2(..);
.... continued

Почему я думаю, что второй лучше:

• Мне не нужно разбирать текст глазами - я вижу структуру команд одним взглядом.
• Я вижу, немедленно
  • что есть некоторые задания и задания
  • что в условиях используется перечисление ResultType и ничего более
  • что только последнее условие состоит из двух выражений

Обновление : это не настоящий код. Я просто хотел показать пример. Считайте, что это старый код, который кто-то написал некоторое время назад, и вам нужно его прочитать. Почему первое форматирование предпочтительнее второго?

Answer 1

Когда ваши коллеги говорят, что вы должны следовать соглашениям, означает ли это, что у вашей команды есть соглашение о форматировании?Если это так, то для этого достаточно причины.Когда каждый форматирует свой код одинаково, легче читать код вашего партнера по команде.

Answer 2

Описанный вами «табличный» макет может быть очень полезен в некоторых случаях:

public string GetMessageFromErrorCode(int code)
{
    switch (code)
    {
        case 1: return "OK";
        case 2: return "Syntax Error";
        case 3: return "Other error";
    }
}

Обратите внимание, что этот пример является допустимым исключением из правила c #, что «Все case операторы должны такжеinclude break. "

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

См. также:
Анонимные методы / Лямбда (стандарты кодирования)

Answer 3

Причина проста.

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

Если вы используете вкладки, чтобы сделать отступ для всего и сделать его очередным, он не будет выглядеть одинаково на всех компьютерах, поскольку не у всех вкладок установлена ​​одинаковая ширина.У некоторых людей они установлены на 3 символа, у других - на 5, другие - на что-то другое.А то, что на вашем компьютере выглядит красиво, аккуратно и «как таблица», выглядит как беспорядок на них.

Бросьте скобки вокруг операторов, которые выполняются оператором if, и отформатируйте его как обычно.*

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

Answer 4

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

something
something
info
something

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

Answer 5

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

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

Answer 6

Ключом к удобочитаемости является последовательность.Если одна и та же конструкция появляется по-разному в разное время, ее будет сложнее обрабатывать мысленно.Поэтому я не хотел бы поддерживать код C #, который был отформатирован в табличном стиле.

Кроме того, вкладки лежат.

if (!HydrogenTankFull())                          FillHydrogenTank();
if (!OxygenTankFull())                            FillOxygenTank();
if (HydrogenTankFull() && OxygenTankFull())       TestGimbals();
if (GimbalsTested() && LaunchButtonPressed())     IgniteEngine(); BlowRestrainingBolts();
if (LaunchPadCleared())                           TransferControlToHouston();

Почему ракета просто упала?!

Answer 7

Если вы чувствуете необходимость табличного кодирования, самое время подумать. Пахнет как время рефакторинга. Код должен быть читаемым как предложение.

Вторая причина - стоимость обслуживания кода. Табличный код сложнее поддерживать.

Answer 8

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

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

Одним из таких примеров, который я считаю очень полезным, является [StyleCop] [1].

Лично я считаю Stylecop очень полезным иметь консистентныйРуководство по кодированию.

С уважением, Nilesh

Answer 9

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

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

Answer 10

Я думаю, что ваш "табличный" пример гораздо проще читать , сам по себе.Проблема в том, что у нас есть 50 лет текстовых инструментов для работы с исходным кодом в виде строк текста.Вот две наиболее очевидные проблемы, с которыми вы столкнетесь:

1. Все мои любимые инструменты обработки текста, такие как diff и grep, работают в строках.Чем больше вы ставите на одну строку, тем меньше значение имеют мои инструменты.Например, если я хочу что-то найти в условии if, я должен отфильтровать ложные срабатывания из предложения ifTrue.

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

2. Ваша самая длинная строка составляет около 95 символов - и это вместо .. вместо реальных аргументов, так что это будетеще дольше.Действительно длинные строки могут быть болью для работы.Линии различной ширины (так как большинство моих линий не будут такими длинными) означают потраченное впустую пространство экрана, поскольку все мои окна имеют прямоугольную форму.Или я должен продолжать изменять размеры окон при прокрутке.Как бы то ни было, редакторы и инструменты отлично справляются с обработкой файлов с множеством строк, но довольно отвратительны при обработке строк большой и разной длины.

Я бы хотел написать этот код,Я хотел бы прочитать этот код.Я бы очень не хотел, чтобы в этом коде было выполнено трехстороннее слияние.: -)

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

• различные вещи о символе0x09: тогда используйте пробелы, а не символы табуляции;в наши дни это просто здравый смысл
• моноширинные шрифты: все виды стандартов кода, которые я видел, падают, если вы используете шрифт переменной ширины, а не только этот
• «это соглашение»: хорошо, но это не говорит о том, почему это соглашение или почему этот случай не должен быть исключением из соглашения (потому что каждый набор кодовых соглашений, которые я когда-либо видел, допускает исключения)
• StyleCop говорит, что это плохо: ты работаешь на свои инструменты или они работают на тебя?см. также: «это соглашение»
• трудно поддерживать: не в моем редакторе, и если это сложно в вашем редакторе, вам нужно научиться его использовать или получить лучший
• у некоторых людей не будет вашего редактора: зависят ли все ваши стандарты кодирования от того, что его легко написать произвольно пустым редактором?Если мы нанимаем кого-то, кто настаивает на использовании Блокнота, это их проблема, и мы не собираемся менять наш исходный код для них.Смотрите также: «трудно поддерживать»
• это противоречиво: конечно, но (поскольку я не робот), это не обязательно усложняет чтение;каждый комикс в моей газете отформатирован по-разному (в некоторых случаях на самом деле по-разному!), но я не нахожу ни одного из них вообще трудным для чтения

(Flame off!)

В конце концов, я думаю, что оба эти стиля являются паршивыми для такого рода кода по разным причинам.Если вам нужна таблица, то используйте switch, или IDictionary<ResultType,Action>, или список-списки или -tuples (если порядок важен), или выгрузите правила в файл конфигурации, или что-то еще.Вы правы, считая, что стол должен выглядеть как стол.Единственное, чего вам не хватает, так это того, что у нас есть конструкции, которые бы выглядели как таблицы, которые бы работали очень хорошо, и if не является одним из них.: -)