Подтвердить что ты не робот

Форматирование кода: выравнивание аналогичных строк в порядке?

Недавно я обнаружил, что наша компания имеет набор правил кодирования (скрытых в системе управления документами, где ее никто не может найти). Как правило, это кажется довольно разумным и держится от обычных религиозных войн о том, куда положить "{и использовать ли жесткие вкладки. Однако он предполагает, что" строки НЕ ДОЛЖНЫ содержать встроенные множественные пробелы". К чему это означает, не делайте этого:

foo    = 1;
foobar = 2;
bar    = 3;

Или это:

if      ( test_one    ) return 1;
else if ( longer_test ) return 2;
else if ( shorter     ) return 3;
else                    return 4;

Или это:

thing foo_table[] =
{
  { "aaaaa", 0 },
  { "aa",    1 },
  // ...
}

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

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

Как вы относитесь к этому?

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

Не забывайте, что в слиянии исходного кода нельзя просить инструмент diff игнорировать пробелы:
В противном случае "и" " будут выглядеть одинаково во время diff, а это означает, что никакого слияния не требуется... компилятор (и кодер, который добавил пространство между двойными кавычками String) не согласился бы с этим!

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

Ответ 5

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

Ответ 6

Об этом говорится в полезном Code Complete от Steve McConnell. Если у вас нет копии этой книжки, сделайте себе одолжение и купите ее. Во всяком случае, обсуждение на страницах 426 и 427 в первом издании, которое является изданием, у меня есть рука.

Edit:

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

Employee.Name  = "Andrew Nelson"
Employee.Bdate = "1/1/56"
Employee.Rank  = "Senator"
CurrentEmployeeRecord = 0

For CurrentEmployeeRecord From LBound(EmployeeArray) To UBound(EmployeeArray) 
. . .

Пока это не будет

Employee.Name         = "Andrew Nelson"
Employee.Bdate        = "1/1/56"
Employee.Rank         = "Senator"
CurrentEmployeeRecord = 0

For CurrentEmployeeRecord From LBound(EmployeeArray) To UBound(EmployeeArray) 
. . .

Я считаю, что разница очевидна. Существует также некоторое обсуждение выравнивания линий продолжения.

Ответ 7

С хорошим редактором их точка просто неверна.:)

(см. "визуальный блок" для vim.)

P.S.: Хорошо, вам все равно придется менять каждую строку, но это быстро и просто.

Ответ 8

Если вы планируете использовать автоматическую проверку стандартного кода (т.е. CheckStyle, ReShaper или что-то в этом роде), эти дополнительные пробелы затруднят создание и соблюдение правил

Ответ 9

Я стараюсь следовать двум рекомендациям:

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

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

Общественная порка допустима, если в "косметическом" изменении появляются ошибки.: -)

Ответ 10

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

Пример: Мне нравится 2 пробела для кода, очень компактный слева, но по умолчанию 4, поэтому, хотя он выглядит совсем по-разному, поскольку отступы и т.д. идут на разных экранах, различия одинаковы и не имеют Не вызывают проблем с контролем источника.

Ответ 11

Мне нравится первый и последний, но не средний.

Ответ 12

Вы можете настроить инструмент diff для игнорирования пробелов (GNU diff: -w). Таким образом, ваши отличия пропустят эти строки и покажут реальные изменения. Очень удобно!

Ответ 13

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

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

Одним из решений было бы использовать вкладки, но наши редакторы не могут автоматически выравнивать вкладки в последовательных строках (что сделало бы так много вещей намного проще). И чтобы добавить травму к оскорблению, если вы возитесь с шириной табуляции (в основном ничего!= 8), вы можете прочитать свой исходный код, но ни одного кода от кого-либо еще, скажем, кода примера, который поставляется с используемыми вами библиотеками. И, наконец, наши инструменты diff не имеют опции "игнорировать пробелы, кроме тех случаев, когда они подсчитываются", и компиляторы также не могут создавать различия.

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

Ответ 14

Это ТОЧНО, почему хороший Господь дал в качестве вкладок - добавление символа в середине строки не приводит к выравниванию.