UPS>Вторая вроде бы лучше читается, но я так на всякий случай никогда не делаю, потому что ни в каких "coding convention" таких советов не читал.
Выравнивал до распространения автоформатилок, которые плевать хотели на моё выравнивание
В итоге удобство автоформата в целом перевесило читабельность "табулированного" кода.
Плюс, не все коллеги разделяли мою страстью к выравниванию.
UPS>-- НЕ ВЫРОВНЕННАЯ ВЕРСИЯ.
UPS>CREATE TABLE DocStream (
UPS> Id BIGINT NOT NULL,
UPS> MD5 CHAR(32) NULL,
UPS> SHA1 CHAR(40) NULL,
UPS> Status INT NOT NULL
UPS>);
UPS>
UPS>
UPS>-- ВЫРОВНЕННАЯ ВЕРСИЯ.
UPS>CREATE TABLE DocStream (
UPS> Id BIGINT NOT NULL,
UPS> MD5 CHAR(32) NULL,
UPS> SHA1 CHAR(40) NULL,
UPS> Status INT NOT NULL
UPS>);
UPS>
UPS>Вторая вроде бы лучше читается, но я так на всякий случай никогда не делаю, потому что ни в каких "coding convention" таких советов не читал.
Вобще то это код на SQL, а вы находитесь в форуме по .Net . Что касается выравнивания — есть в R# такая опция как Code Clean. Один раз настраиваете и при нажатии одной кнопки весь файл у вас сам выравнивается
Здравствуйте, UberPsychoSvin, Вы писали:
UPS>А вы выравниваете код?
В середине строки — никогда.
UPS>Вторая вроде бы лучше читается, но я так на всякий случай никогда не делаю, потому что ни в каких "coding convention" таких советов не читал.
Такое искусственное выравнивание требует сопровождения: изменения одной строки нуждается в ручном перевёрстывании всех остальных. Как следствие, это не diff friendly.
Здравствуйте, Gattaka, Вы писали: G>Вобще то это код на SQL, а вы находитесь в форуме по .Net .
А и правда, не обратил внимания. У меня постоянно так, начинаю писать на .NET а заканчиваю на SQL.
Здравствуйте, Qbit86, Вы писали: Q>Такое искусственное выравнивание требует сопровождения: изменения одной строки нуждается в ручном перевёрстывании всех остальных. Как следствие, это не diff friendly.
Вот! Теперь я понял, что меня в этом выравнивании смущало.
Здравствуйте, Qbit86, Вы писали:
Q>Такое искусственное выравнивание требует сопровождения: изменения одной строки нуждается в ручном перевёрстывании всех остальных. Как следствие, это не diff friendly.
Здравствуйте, UberPsychoSvin, Вы писали:
UPS>Вторая вроде бы лучше читается, но я так на всякий случай никогда не делаю, потому что ни в каких "coding convention" таких советов не читал.
В C# приходится иногда выравнивать ручками то, что автоформат (ctr+k/ctr+d) не распознал. К примеру инициализаторы вложенных структур.
Вы правы, второй вариант читается лучше. Если таких обьявлений будет несколько страниц, то читать будет проще за счет дополнительных телодвижений при написании (добавили новое поле с длинным именем — нужно переформатировать). Вместо пробелов используют символы табуляции. На первых порах программирования в C# у меня была манера форматировать после-строчные комментарии (//..дофига пробелов..комментарий), вылечился, теперь по большому счету пофиг, комментарии читаются легко из-за характерного стиля в VS.
Необходимость проделывать такое вручную существует в средах где отсутствует автоформатирование. И там оно определенно имеет право на жизнь.
P.S.: на StackOverflow такие вопросы оффтоп, т.к. ну реально — opinion based ведь.
Здравствуйте, Don Reba, Вы писали:
Q>>Такое искусственное выравнивание требует сопровождения: изменения одной строки нуждается в ручном перевёрстывании всех остальных. Как следствие, это не diff friendly. DR>Решается опцией ignore whitespace в диффе.
А зачем их ignore? Их не надо ignore. Кроме того, это не спасёт от конфликтов. Скажем, в такой табличке кто-то в одной строке изменил тип, увеличив его на пару символов; кто-то другой исправил имя в другой строке, уменьшив самую длинную строку. Оба переверстали.
Изменения должны быть максимально локальными. А навязывание выравнивания вводит неявные зависимости между несвязанными строками.
Здравствуйте, Qbit86, Вы писали:
Q>А зачем их ignore? Их не надо ignore. Кроме того, это не спасёт от конфликтов. Скажем, в такой табличке кто-то в одной строке изменил тип, увеличив его на пару символов; кто-то другой исправил имя в другой строке, уменьшив самую длинную строку. Оба переверстали.
Я считаю редкие, легко разрешимые конфликты приемлемой ценой за повышение читаемости кода.
Здравствуйте, Sinatr, Вы писали:
S>Вместо пробелов используют символы табуляции.
Даже в начале строки не стоит использовать табуляцию, а уж в середине и подавно. При чтении в IDE, браузере, текстовом просмотрщике табуляция отображается разной ширины. Если табуляция в начале строки, то исходный текст будет всегда выглядеть по-разному, но хотя бы единообразно внутри файла. А если табуляция внутри строки, то вёрстка скорее всего будет сломана напрочь.
Здравствуйте, Don Reba, Вы писали:
Q>>А зачем их ignore? Их не надо ignore. Кроме того, это не спасёт от конфликтов. Скажем, в такой табличке кто-то в одной строке изменил тип, увеличив его на пару символов; кто-то другой исправил имя в другой строке, уменьшив самую длинную строку. Оба переверстали.
DR>Я считаю редкие, легко разрешимые конфликты приемлемой ценой за повышение читаемости кода.
Это не колонка с цифрами, выравненными по разрядам. Тут сканирование чаще происходит построчно. Искусственное выравнивание не очень тут улучшает читаемость. Возможно даже ухудшает, так как внутри строки появляются нерегулярные разрывы.
Здравствуйте, Qbit86, Вы писали:
Q>Даже в начале строки не стоит использовать табуляцию, а уж в середине и подавно. При чтении в IDE, браузере, текстовом просмотрщике табуляция отображается разной ширины.
Не стоит лепить такое форматирование, для которого критична ширина таба. Тогда и съезжать ничего не будет при изменении его размера.
Здравствуйте, Lexey, Вы писали:
Q>>Даже в начале строки не стоит использовать табуляцию, а уж в середине и подавно. При чтении в IDE, браузере, текстовом просмотрщике табуляция отображается разной ширины. L>Не стоит лепить такое форматирование, для которого критична ширина таба. Тогда и съезжать ничего не будет при изменении его размера.
Что такое «форматирование, для которого некритична ширина таба», и за счёт чего гарантируется его несъезжание?
Здравствуйте, Sinatr, Вы писали: S>P.S.: на StackOverflow такие вопросы оффтоп, т.к. ну реально — opinion based ведь.
Это объективная вещь.
В +ах.
1. Чуть лучше читается.
В -ах.
1. Добавление одной строчки в коммитах может затрагивать целый блок кода, за счёт переформатирования.
2. Дополнительные телодвижения для форматирования.
Минусов больше чем плюсов — значит в рабочих проектах не надо этой фигнёй страдать.
А во всяких одноразовых скриптах можно и выровнять, что бы лучше читались, пока пишутся.
Здравствуйте, Lexey, Вы писали:
Q>>Что такое «форматирование, для которого некритична ширина таба», и за счёт чего гарантируется его несъезжание? L>Любые начальные отступы блоков кода. Несъезжание гарантируется тем, что в этих отступах нет ничего, кроме табов.
Я это отдельно оговаривал. Похоже, ты просто не читаешь собощения, лепишь минус по ключевым словам.
Здравствуйте, Lexey, Вы писали: L>Любые начальные отступы блоков кода. Несъезжание гарантируется тем, что в этих отступах нет ничего, кроме табов.
например, просмотр в редакторе с табом по умолчанию 8 не гарантирует несъезжание за пределы экрана
зато точно покажет немеряно пустого места
Иначе всё поедет при изменении ширины таба.
