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 не гарантирует несъезжание за пределы экрана
зато точно покажет немеряно пустого места
Здравствуйте, UberPsychoSvin, Вы писали: UPS>Вторая вроде бы лучше читается, но я так на всякий случай никогда не делаю, потому что ни в каких "coding convention" таких советов не читал.
невыравненный код вообще не имеет права на существование...
Здравствуйте, mDmitriy, Вы писали:
D>например, просмотр в редакторе с табом по умолчанию 8 не гарантирует несъезжание за пределы экрана D>зато точно покажет немеряно пустого места
А зачем вы так переживаете за того чувака, который юзает таб в 8 пробелов? Может дофига пустого места — это именно то, что ему нужно?
А если это у вас такой таб, что мешает просматривать отформатированный код, то ссзс, предлагаю еще и цвет текста сделать белым по белому.
Здравствуйте, Qbit86, Вы писали:
L>>Не стоит лепить такое форматирование, для которого критична ширина таба. Тогда и съезжать ничего не будет при изменении его размера.
Q>Что такое «форматирование, для которого некритична ширина таба», и за счёт чего гарантируется его несъезжание?
На практике, это использование табов только для отступов и избежание такого форматирования параметров функций:
Здравствуйте, seregaa, Вы писали:
S>Может дофига пустого места — это именно то, что ему нужно?
Нет, дофига пустого места — это настройки по умолчанию: в Google Chrome, Unity 3D, Total Commander, etc, etc, etc.
S>А если это у вас такой таб, что мешает просматривать отформатированный код, то ссзс, предлагаю еще и цвет текста сделать белым по белому.
Видишь ли, для такого таба не надо что-то специально делать. Достаточно просто не найти настройку «ширина табуляции в <pre>» в Google Chrome.
Кстати, где она? Расскажи, как ты убеждаешь ГитХаб отображать тебе исходный код с табами шириной в 4 символа, а не 8, например?
Здравствуйте, seregaa, Вы писали:
S>А зачем вы так переживаете за того чувака, который юзает таб в 8 пробелов? S>А если это у вас такой таб, что мешает просматривать отформатированный код, то ссзс
Это размер таба по умолчанию. Используется многими инструментами, которые, зачастую, нет возможности настроить или настраиваются они исключительно ректально. Например, всякие веб-приложения для просмотра исходного кода, diff-merge утилиты, консольные утилиты и пр.
Да, большая часть из них так или иначе настраивается. Но частенько с косяками. Например, WinMerge не может иметь разную величину табов для разных типов файлов, а где настраивать ширину таба в интерфейсе github'а я что-то сходу не нашёл.
Здравствуйте, UberPsychoSvin, Вы писали:
UPS>Вторая вроде бы лучше читается, но я так на всякий случай никогда не делаю, потому что ни в каких "coding convention" таких советов не читал.
Я выравниваю по возможности. Но без фанатизма.
Да, Visual Studio и прочие инструменты частенько грохают это форматирование. И аргумент про дополнительные телодвижения при добавлении новых строк тоже актуален. Но читабельность кода для меня важнее, потому в конечном счёте весь подобный код у нас форматируется таким вот образом.
Здравствуйте, Qbit86, Вы писали:
S>>Может дофига пустого места — это именно то, что ему нужно? Q>Нет, дофига пустого места — это настройки по умолчанию: в Google Chrome, Unity 3D, Total Commander, etc, etc, etc.
Ну вы пробельщики и эгоисты. Вместо того, чтобы изучить и настроить под себя свой инструмент, вы хотите насадить свои стандарты всем вокруг.
S>>А если это у вас такой таб, что мешает просматривать отформатированный код, то ссзс, предлагаю еще и цвет текста сделать белым по белому. Q>Видишь ли, для такого таба не надо что-то специально делать. Достаточно просто не найти настройку «ширина табуляции в <pre>» в Google Chrome. Q>Кстати, где она? Расскажи, как ты убеждаешь ГитХаб отображать тебе исходный код с табами шириной в 4 символа, а не 8, например?
Здравствуйте, Artem Korneev, Вы писали:
AK>Это размер таба по умолчанию. Используется многими инструментами, которые, зачастую, нет возможности настроить или настраиваются они исключительно ректально. Например, всякие веб-приложения для просмотра исходного кода, diff-merge утилиты, консольные утилиты и пр. AK>Да, большая часть из них так или иначе настраивается. Но частенько с косяками. Например, WinMerge не может иметь разную величину табов для разных типов файлов, а где настраивать ширину таба в интерфейсе github'а я что-то сходу не нашёл.
Здравствуйте, seregaa, Вы писали:
Q>>например? S>Вот если бы мне это действительно было нужно, я бы не поленился и погуглил. И нашел бы такой способ:
«This does not work on Gists, or raw file views»
S>Ну вы пробельщики и эгоисты. Вместо того, чтобы изучить и настроить под себя свой инструмент, вы хотите насадить свои стандарты всем вокруг.
Олол. Табуляторщикам проще допустить, все вокруг должны настраивать по несколько программ на всех своих рабочих компах, просто чтобы три с половиной табуляторщика наслаждались своей табуляцией. Невзирая на гайдлайны и рекомендации.
Здравствуйте, Qbit86, Вы писали:
Q> Такое искусственное выравнивание требует сопровождения: изменения одной Q> строки нуждается в ручном перевёрстывании всех остальных. Как следствие, это не diff friendly.
где вы такой diff откопали? кошерный diff кушает опцию: --ignore-space-change google://diff ignore whitespace
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, UberPsychoSvin, Вы писали:
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>Вторая вроде бы лучше читается, но я так на всякий случай никогда не делаю, потому что ни в каких "coding convention" таких советов не читал.
Есть местами. BSD'шный style(9) явно такое рекомендует:
When declaring variables in structures, declare them sorted by use, then
by size (largest to smallest), and then in alphabetical order. The first
category normally does not apply, but there are exceptions. Each one
gets its own line. Try to make the structure readable by aligning the
member names using either one or two tabs depending upon your judgment.
You should use one tab only if it suffices to align at least 90% of the
member names. Names following extremely long types should be separated
by a single space.
struct foo {
struct foo *next; /* List of active foo. */
struct mumble amumble; /* Comment for mumble. */
int bar; /* Try to align the comments. */
struct verylongtypename *baz; /* Won't fit in 2 tabs. */
};
struct foo *foohead; /* Head of global foo list. */
(подчёркивание — моё)
Тут, правда, явно требуют табы. Не влезая в уже состоявшуюся тут дискуссию, замечу, что никто не мешает заменить это на выравнивание пробелами по позициям, соответствующим обычным табуляциям.
Хуже то, что большинство сейчас ориентируется на автоформатирование в IDE, а в нём я такое ещё не видел ни разу. Вообще, это автоформатирование очень часто слишком тупое.
Здравствуйте, Lexey, Вы писали:
L>Здравствуйте, Qbit86, Вы писали:
Q>>Даже в начале строки не стоит использовать табуляцию, а уж в середине и подавно. При чтении в IDE, браузере, текстовом просмотрщике табуляция отображается разной ширины.
L>Не стоит лепить такое форматирование, для которого критична ширина таба. Тогда и съезжать ничего не будет при изменении его размера.
Реально на сейчас табуляция в коде просто вредна — экономия ничтожна, а проблемы из-за разной ширины значительно существеннее.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, seregaa, Вы писали:
Q>>>например? S>>Вот если бы мне это действительно было нужно, я бы не поленился и погуглил. И нашел бы такой способ: Q>«This does not work on Gists, or raw file views»
А почему цитату до конца не привел? "This does not work on Gists, or raw file views, but a Chrome or Opera extension can automate this."
S>>Ну вы пробельщики и эгоисты. Вместо того, чтобы изучить и настроить под себя свой инструмент, вы хотите насадить свои стандарты всем вокруг. Q>Олол. Табуляторщикам проще допустить, все вокруг должны настраивать по несколько программ на всех своих рабочих компах, просто чтобы три с половиной табуляторщика наслаждались своей табуляцией.
С табами всегда есть альтернатива — можно смотреть как есть, а можно настроить инструмент под себя.
В случае с пробелами такой альтернативы нет — ты полностью зависим от прихоти автора кода.
Q>Невзирая на гайдлайны и рекомендации.
Гайды и рекомендации разные, и если проходится участвовать в разных проектах, то приходится перенастраивать инструменты и работать с разношерстным выравниванием.
Здравствуйте, Qbit86, Вы писали:
Q>Олол. Табуляторщикам проще допустить, все вокруг должны настраивать по несколько программ на всех своих рабочих компах, просто чтобы три с половиной табуляторщика наслаждались своей табуляцией. Невзирая на гайдлайны и рекомендации.
Здравствуйте, seregaa, Вы писали:
Q>>«This does not work on Gists, or raw file views» S>А почему цитату до конца не привел?
Так и ты до конца все пункты не рассмотрел. Где настраивается отображаемый размер табуляции в инспекторе Unity 3D или в текст. просмотрщике Total Commander?
S>"This does not work on Gists, or raw file views, but a Chrome or Opera extension can automate this."
То есть ты считаешь нормальным навязывать всему миру установку каких-то сторонних экстеншнов под разные браузеры (а что насчёт Edge и Firefox?), а если кто не хочет, «то ссзс, предлагаю еще и цвет текста сделать белым по белому.»
S>С табами всегда есть альтернатива — можно смотреть как есть, а можно настроить инструмент под себя.
Не просто «настроить инструмент под себя», а перебрать все установленные на компе мерджилки, текстовые просмотрщики и браузеры, не говоря уже о каких-то консольных утилитах.
S>В случае с пробелами такой альтернативы нет — ты полностью зависим от прихоти автора кода.
А ещё, представь, ты зависим о того, переносит ли автор скобку { на новую строку или пишет в конце предыдущей. Может, стоит перед скобкой тоже вставлять какой-нибудь специальный неотображаемый символ, чтоб читатель мог настроить в своём окружении, переносить ли по этому символу скобку или нет?
Q>>Невзирая на гайдлайны и рекомендации.
Microsoft: «Use the default Code Editor settings (smart indenting, four-character indents, tabs saved as spaces).» Google: «We use spaces for indentation. Do not use tabs in your code. You should set your editor to emit spaces when you hit the tab key.» PEP 8: «Spaces are the preferred indentation method. Tabs should be used solely to remain consistent with code that is already indented with tabs.»
S>Гайды и рекомендации разные, и если проходится участвовать в разных проектах, то приходится перенастраивать инструменты и работать с разношерстным выравниванием.
Я сейчас как раз работаю в проекте, где «исторически сложилась» табуляция, будь она проклята.
Прекрасная ссылка; по ней говорится: «Upon closer examination of the data, a trend emerges: Developers increasingly prefer spaces as they gain experience. Stack Overflow reputation correlates with a preference for spaces, too: users who have 10,000 rep or more prefer spaces to tabs at a ratio of 3 to 1.»
Здравствуйте, Qbit86, Вы писали:
Q>>>...просто чтобы три с половиной табуляторщика наслаждались своей табуляцией. Невзирая на гайдлайны и рекомендации. S>>Посмотри на количество проголосовавших за табы и пробелы http://stackoverflow.com/research/developer-survey-2015#tech-tabsspaces Q>Прекрасная ссылка; по ней говорится: «Upon closer examination of the data, a trend emerges: Developers increasingly prefer spaces as they gain experience. Stack Overflow reputation correlates with a preference for spaces, too: users who have 10,000 rep or more prefer spaces to tabs at a ratio of 3 to 1.»
Так и знал, что ты обратишь на это внимание. Однако изначально ты говорил только о количестве. Так до бесконечности перескакивать (что то мне это напоминает...)
Здравствуйте, Qbit86, Вы писали:
Q>То есть ты считаешь нормальным навязывать всему миру установку каких-то сторонних экстеншнов под разные браузеры (а что насчёт Edge и Firefox?), а если кто не хочет, «то ссзс, предлагаю еще и цвет текста сделать белым по белому.»
Просто представь, что автор напечатал восемь пробелов, и не надо ничего настраивать.
Здравствуйте, seregaa, Вы писали:
Q>>Прекрасная ссылка; по ней говорится: «Upon closer examination of the data, a trend emerges: Developers increasingly prefer spaces as they gain experience. Stack Overflow reputation correlates with a preference for spaces, too: users who have 10,000 rep or more prefer spaces to tabs at a ratio of 3 to 1.» S>Так и знал, что ты обратишь на это внимание. Однако изначально ты говорил только о количестве.
Вполне вероятно, что у меня искажённая оценка количества табуляторщиков, потому что стараюсь оставаться в среде experienced developers. Если же тебя окружают вчерашние студенты, то вполне возможно они фигачат табы как в дельфи.
Здравствуйте, Qbit86, Вы писали:
Q>Я это отдельно оговаривал. Похоже, ты просто не читаешь собощения, лепишь минус по ключевым словам.
Я минус тебе влепил за "Даже в начале строки не стоит использовать табуляцию". Ибо именно в начале строки ее и желательно использовать. Твои дальнейшие оговорки никак не отменяют первое утверждение.
Здравствуйте, Don Reba, Вы писали:
Q>>То есть ты считаешь нормальным навязывать всему миру установку каких-то сторонних экстеншнов под разные браузеры (а что насчёт Edge и Firefox?), а если кто не хочет, «то ссзс, предлагаю еще и цвет текста сделать белым по белому.» DR>Просто представь, что автор напечатал восемь пробелов, и не надо ничего настраивать.
Здравствуйте, mDmitriy, Вы писали:
D>например, просмотр в редакторе с табом по умолчанию 8 не гарантирует несъезжание за пределы экрана
Это не съезжание форматирования. Это несоответствие максимальной длины строки кода размеру окна редактора. Если тебе критичен просмотр с таким размером таба в маленьком окне, то разбивай код на более короткие строки.
Здравствуйте, Qbit86, Вы писали:
Q>И кому это нужно?
Автору кода или другим пользователям редактора. Ты же сам ратуешь за отсутствие возможности подстроить под себя. Не устанавливай никаких расширений, не настраивай редакторы, просто смотри, как за тебя решили.
Здравствуйте, netch80, Вы писали:
N>Реально на сейчас табуляция в коде просто вредна — экономия ничтожна, а проблемы из-за разной ширины значительно существеннее.
Кому вредна? Мне она очень удобна. Никаких проблем нет, если код не начинают править любители замены табов на пробелы.
Вот тогда начинается геморрой с переформатированием, ибо у одного стоит таб = 4 пробела, у другого 2, etc.
Здравствуйте, Qbit86, Вы писали:
Q>>>И кому это нужно? DR>>Автору кода или другим пользователям редактора. Q>Может, автору кода удобно вообще в одну строку писать. Ну а что, настройте под себя расширение браузера для автоформатирования.
Это не аргумент — в этом случае не помогут ни табы ни пробелы.
Здравствуйте, seregaa, Вы писали:
S>в этом случае не помогут ни табы ни пробелы.
Зато поможет экстеншн для форматирования! Зачем кому-то навязывать стиль переноса фигурных скобок или аргументов функции? Пусть каждый сам настроит инструмент под себя.
Здравствуйте, Qbit86, Вы писали:
Q>Microsoft, Google и PEP единодушны в этом вопросе: табуляцию использовать не нужно.
И что? Это их внутренние стандарты, которые редко меняют из-за бюрократии и того, что уже тонны кода в таком формате написаны.
Раньше, вот, венгерку было принято использовать, но, к счастью, сейчас эту жесть уже мало где встретишь, кроме легаси-кода.
Я много использовал пробелы там, где это было оговорено внутренним стандартом, но, при наличии выбора, предпочитаю табы.
Здравствуйте, Lexey, Вы писали:
Q>>Microsoft, Google и PEP единодушны в этом вопросе: табуляцию использовать не нужно. L>И что? Это их внутренние стандарты, которые редко меняют из-за бюрократии и того, что уже тонны кода в таком формате написаны.
Нет. В этих рекомендациях обычно сказано, что хотя в старом коде при небольших изменениях приоритет у текущего стиля (консистентность внутри файла), но в новом нужно использовать уже современные гайдлайны.
L>Я много использовал пробелы там, где это было оговорено внутренним стандартом, но, при наличии выбора, предпочитаю табы.
Да я понял уже: несовместимые с оющепринятыми самопальные соглашения и прочий дельфи-стайл лучше рекомендаций от авторов платформы.
Здравствуйте, Qbit86, Вы писали:
Q>Прекрасная ссылка; по ней говорится: «Upon closer examination of the data, a trend emerges: Developers increasingly prefer spaces as they gain experience. Stack Overflow reputation correlates with a preference for spaces, too: users who have 10,000 rep or more prefer spaces to tabs at a ratio of 3 to 1.»
Кстати, что характерно, сразу после того, как пробельщики побеждают табберов, начинается война о количестве пробелов. Я видел 1, 2, 3, 4, 5, 8 штук. С четырмя пробелами соглашаются далеко не все.
Иметь ширину 4 пробела в глубоковложенных форматах типа html или xml — многовато, желательно один или два.
А в форматах с небольшой вложенностью, css или sql, например, можно и 8 поставить.
А ещё табы удобнее тем, что их можно настраивать. Скажем, когда редактируешь — удобно поставить ширину 8, а когда делаешь трёхколоночный merge, то ужимаешь до двух или даже до одного.
Насчёт браузеров — ширина табов тоже меняется, через css или адд-оны.
ЗЫЖ Если тебе лень искать как настроить в некой тулзе ширину табов, считай что код написан восьмипробельщиком.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>С четырмя пробелами соглашаются далеко не все.
Четыре пробела общеприняты для C#, это соответствует официальным рекомендациям и для совместимости с другими разработчиками имеет смысл придерживаться этого соглашения. Для других языков могут быть другие соглашения, там лучше придерживаться их. Все табберы, которы я встречал, используют эту ширину для отображения.
·>Иметь ширину 4 пробела в глубоковложенных форматах типа html или xml — многовато, желательно один или два.
Прекрасно, когда XML свёрстан в два прообела, ты увидишь именно их, никаких проблем. А если он свёрстан с табами, то в нотпаде ты увидишь то, как настроена табуляция была в последний раз. В IDE ещё можно настраивать ширины табов по-разному для разных типов файлов. А во многих других просмотрщиках текста — нельзя. XML с отступами шириной 8 символов, Карл!
·>сразу после того, как пробельщики побеждают табберов
Ещё раз: использование табов объективно вызывает у людей проблемы, с просмотром и редактированием. На что табберы говорят: ваши проблемы, ставьте себе аддоны и не используйте богомерзкую Unity 3D. Да, для нас это становится проблемой. «Считай что код написан восьмипробельщиком» — спасибо за заботу о читателе, бро!
Здравствуйте, Qbit86, Вы писали:
Q>Да я понял уже: несовместимые с оющепринятыми самопальные соглашения и прочий дельфи-стайл лучше рекомендаций от авторов платформы.
На общепринятые они никак не тянут (судя по той статистике, которую в теме приводили). В чем заключается дельфи-стайл, понятия не имею.
Здравствуйте, Qbit86, Вы писали:
Q>Четыре пробела общеприняты для C#, это соответствует официальным рекомендациям и для совместимости с другими разработчиками имеет смысл придерживаться этого соглашения. Для других языков могут быть другие соглашения, там лучше придерживаться их. Все табберы, которы я встречал, используют эту ширину для отображения.
Сишарпом вселенная не ограничивается.
Q>·>Иметь ширину 4 пробела в глубоковложенных форматах типа html или xml — многовато, желательно один или два. Q>Прекрасно, когда XML свёрстан в два прообела, ты увидишь именно их, никаких проблем.
Почему ты выбираешь только удобные тебе ситуации? Представь, что XML свёрстан с восемью пробелами.
Q>А если он свёрстан с табами, то в нотпаде ты увидишь то, как настроена табуляция была в последний раз. В IDE ещё можно настраивать ширины табов по-разному для разных типов файлов. А во многих других просмотрщиках текста — нельзя. XML с отступами шириной 8 символов, Карл!
Поставь свои любимые четыре в этих многих. И нет проблемы, будешь везде видеть свои любимые четыре пробела.
Q>·>сразу после того, как пробельщики побеждают табберов Q>Ещё раз: использование табов объективно вызывает у людей проблемы, с просмотром и редактированием. На что табберы говорят: ваши проблемы, ставьте себе аддоны и не используйте богомерзкую Unity 3D. Да, для нас это становится проблемой. «Считай что код написан восьмипробельщиком» — спасибо за заботу о читателе, бро!
У меня вызывает проблемы мерж html с четырмя пробелами, хочу видеть один пробел. И эта проблема _вообще никак_ не решается, даже в супернавороченных IDE.
Если стандартная ширина таба 8 вызывает трудности — две минуты гугленья проблему решают практически всегда. Что такое Unity 3D я не знаю, но вот вроде тоже что-то есть: http://docs.unity3d.com/ScriptReference/GUIText-tabSize.html
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Сишарпом вселенная не ограничивается.
Я приводил ссылки также на некоторые гайды по стилю C++ и Питон. Конечно, они расходятся во многих аспектах с рекомендациями для C#, единогласия нет. Только в отношении неиспользования табов они единодушны, это о чём-то говорит.
·>Почему ты выбираешь только удобные тебе ситуации? Представь, что XML свёрстан с восемью пробелами.
Потому что исхожу из своего опыта, в котором количество встреченных XML-документов, свёрстанных с 8 пробелами, равно нулю.
·>Поставь свои любимые четыре в этих многих.
Не любой софт позволяет настраивать ширину отображаемой табуляции.
·>И нет проблемы, будешь везде видеть свои любимые четыре пробела.
Здравствуйте, Qbit86, Вы писали:
Q>·>Сишарпом вселенная не ограничивается. Q>Я приводил ссылки также на некоторые гайды по стилю C++ и Питон. Конечно, они расходятся во многих аспектах с рекомендациями для C#, единогласия нет. Только в отношении неиспользования табов они единодушны, это о чём-то говорит.
Это говорит лишь о том, что ты аккуратно подбираешь удобные и отбрасываешь неудобные факты для доказательства своей т.з.
Вот, скажем https://www.kernel.org/doc/Documentation/CodingStyle — ширина 8 символов.
Q>·>Почему ты выбираешь только удобные тебе ситуации? Представь, что XML свёрстан с восемью пробелами. Q>Потому что исхожу из своего опыта, в котором количество встреченных XML-документов, свёрстанных с 8 пробелами, равно нулю.
Т.е. опять confirmation bias вместо разумных доводов.
Q>·>Поставь свои любимые четыре в этих многих. Q>Не любой софт позволяет настраивать ширину отображаемой табуляции.
Можно примеры? Особенно интересно услышать в свете confirmation bias — чем ты регулярно пользуешься лично что не позволяет настраивать размеры табов?
Q>·>И нет проблемы, будешь везде видеть свои любимые четыре пробела. Q>Я не хочу везде видеть четыре пробела. В XML иногда удобно два, в C# всегда четыре.
Не понял, это вообще-то говорит в пользу табов. Это именно табы позволят видеть столько пробелов сколько хочешь, пробелы — нет. Со сколькими пробелами XML набран — со столькими ты и будешь видеть. Если человек набирал XML на 26" мониторе с четырмя пробелами, а тебе с этим же кодом надо повозиться на 13" ноуте — что делать?
Q>·>Что такое Unity 3D я не знаю, но вот вроде тоже что-то есть: http://docs.unity3d.com/ScriptReference/GUIText-tabSize.html Q>Это не о том вообще.
А о чём? Можно ссылку о том, что в некой Unity 3D невозможно поменять размер таба?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
Q>>Я приводил ссылки также на некоторые гайды по стилю C++ и Питон. Конечно, они расходятся во многих аспектах с рекомендациями для C#, единогласия нет. Только в отношении неиспользования табов они единодушны, это о чём-то говорит. ·>Вот, скажем https://www.kernel.org/doc/Documentation/CodingStyle — ширина 8 символов.
«Addison-Wesley, Inc., 1999.» Подождите, а кто там наверху говорил про легаси? Что-нибудь из нашего века есть?
Q>>Потому что исхожу из своего опыта, в котором количество встреченных XML-документов, свёрстанных с 8 пробелами, равно нулю. ·>Т.е. опять confirmation bias вместо разумных доводов.
Остаётся только предоставить читателям самим судить насчёт разумности доводов про теоретический 8-пробельный XML.
·>Можно примеры? Особенно интересно услышать в свете confirmation bias — чем ты регулярно пользуешься лично что не позволяет настраивать размеры табов?
Unity 3D, Total Commander (просмотр по F3), Google Chrome. Про GitHub выше привели хак, но ещё есть Bitbucket и просто бложеки, где приводят код в <pre>.
Q>>Я не хочу везде видеть четыре пробела. В XML иногда удобно два, в C# всегда четыре. ·>Не понял, это вообще-то говорит в пользу табов.
Подождите, вы же говорили, что достаточно всего один раз настроить инструментарий под себя?
·>Со сколькими пробелами XML набран — со столькими ты и будешь видеть. Если человек набирал XML на 26" мониторе с четырмя пробелами, а тебе с этим же кодом надо повозиться на 13" ноуте — что делать?
Если исключить случай злонамеренности автора, то проблем с пробелами никогда не возникает. Даже при разных соглашениях, будь то XAML, или AndroidManifest.xml, или другие конфиги; часть из них удобнее с нормальными отступами, часть с компактными.
·>А о чём? Можно ссылку о том, что в некой Unity 3D невозможно поменять размер таба?
Unity 3D — это инструментарий для кроссплатформенной разработки игр; в его редакторе есть окошко Инспектора (обычно небольшое), которое показывает содержимое разных ассетов (модельки, текстурки, скрипты, etc). Он показывает текст как есть, без вычурных настроек; длинный текст обрывает и переносит. При использовании табов получается таже не куча пустого места, а просто месиво разорванных строк.
А теперь представь другую вселенную: табы запрещены, или их вообще не существовало, и кнопки такой нет. Будут ли проблемы — по-моему да. Как минимум будут войны на тему сколько пробелов должно быть в отступах — 2, 4 или 8 или 13. Притом, даже если законодательно закрепят какое-то число, например 4, то возникнет вопрос — а почему бы не заменить стандартные четыре символа на специальный символ со специальным кодом, и кнопку бы неплохо добавить... ведь нажимать четырежды сложнее? Придётся комбинацию клавиш добавлять или специальную кнопку в клавиатуры, текстовые редакторы должны будут поддерживать вставку/удаление четырех пробелов.
Q>·>Можно примеры? Особенно интересно услышать в свете confirmation bias — чем ты регулярно пользуешься лично что не позволяет настраивать размеры табов? Q>Unity 3D,
Ок, никогда это не видел, но можно поверить, что одна такая прога есть. Патч уже постили? Разрабы наотрез отказались мержить?
Q>Total Commander (просмотр по F3),
"Tab width may be specified by parameter TabWidth in section [Lister] of wincmd.ini file." Или оно не работает?
Q>Google Chrome. Про GitHub выше привели хак, но ещё есть Bitbucket и просто бложеки, где приводят код в <pre>.
С бразуерами всё просто: http://stackoverflow.com/questions/6686763/setting-pre-tab-width-in-different-web-browsers
Как сделать user style css думаю сам разберёшься.
Q>>>Я не хочу везде видеть четыре пробела. В XML иногда удобно два, в C# всегда четыре. Q>·>Не понял, это вообще-то говорит в пользу табов. Q>Подождите, вы же говорили, что достаточно всего один раз настроить инструментарий под себя?
Каждый настраивает под себя как и где ему удобно. Проблема с пробелами возникает когда разные люди с разными настройками начинают работать над одними и теми же файлами. С табами проблем нет, т.к. они учитывают "настойки под себя".
Q>·>Со сколькими пробелами XML набран — со столькими ты и будешь видеть. Если человек набирал XML на 26" мониторе с четырмя пробелами, а тебе с этим же кодом надо повозиться на 13" ноуте — что делать? Q>Если исключить случай злонамеренности автора, то проблем с пробелами никогда не возникает. Даже при разных соглашениях, будь то XAML, или AndroidManifest.xml, или другие конфиги; часть из них удобнее с нормальными отступами, часть с компактными.
И кто как договаривается какие в данном файле в данном проекте отступы делать?
Q>·>А о чём? Можно ссылку о том, что в некой Unity 3D невозможно поменять размер таба? Q>Unity 3D — это инструментарий для кроссплатформенной разработки игр; в его редакторе есть окошко Инспектора (обычно небольшое), которое показывает содержимое разных ассетов (модельки, текстурки, скрипты, etc). Он показывает текст как есть, без вычурных настроек; длинный текст обрывает и переносит. При использовании табов получается таже не куча пустого места, а просто месиво разорванных строк.
А при использовании восьми пробелов что происходит?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Don Reba, Вы писали: DR>Просто представь, что автор напечатал восемь пробелов, и не надо ничего настраивать.
от таких авторов умные люди и изобрели автоформаттеры...
Здравствуйте, Lexey, Вы писали: L>Это не съезжание форматирования. Это несоответствие максимальной длины строки кода размеру окна редактора. Если тебе критичен просмотр с таким размером таба в маленьком окне, то разбивай код на более короткие строки.
ну, может вам и нравится подстраивать свой код под сторонних табуляторщиков... мне вот нет
Здравствуйте, mDmitriy, Вы писали:
L>>Это не съезжание форматирования. Это несоответствие максимальной длины строки кода размеру окна редактора. Если тебе критичен просмотр с таким размером таба в маленьком окне, то разбивай код на более короткие строки. D>ну, может вам и нравится подстраивать свой код под сторонних табуляторщиков... мне вот нет
Ты не читаешь что-ли на что отвечаешь? Если не критичен — уменьши размер таба при просмотре. В этом случае подстраивать код ты не должен. А если критичен — то подстраивать ты будешь код и с пробелами. В этом и профит.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, mDmitriy, Вы писали:
D>ну, может вам и нравится подстраивать свой код под сторонних табуляторщиков... мне вот нет
Мне, как раз, незачем его подстраивать. Ибо ни разу не видел реальной проблемы с шириной настоящего таба. А вот кривое форматирование, которое получаются из-за разной ширины заменяемого пробелами таба у разных людей, работающих с кодом, видел не раз.
Здравствуйте, ·, Вы писали:
·>Здравствуйте, mDmitriy, Вы писали:
L>>>Это не съезжание форматирования. Это несоответствие максимальной длины строки кода размеру окна редактора. Если тебе критичен просмотр с таким размером таба в маленьком окне, то разбивай код на более короткие строки. D>>ну, может вам и нравится подстраивать свой код под сторонних табуляторщиков... мне вот нет ·>Ты не читаешь что-ли на что отвечаешь? Если не критичен — уменьши размер таба при просмотре. В этом случае подстраивать код ты не должен. А если критичен — то подстраивать ты будешь код и с пробелами. В этом и профит.
найти код с 8-ю пробелами отступа — задача не из простых...
а получить тот же отступ на табе — легче легкого
вместе с геморроем "где то место, уменьшающее таб"
код с пробелами подстраивать не надо — больше 4-х вменяемые люди обычно не используют
Здравствуйте, mDmitriy, Вы писали:
D>>>ну, может вам и нравится подстраивать свой код под сторонних табуляторщиков... мне вот нет D>·>Ты не читаешь что-ли на что отвечаешь? Если не критичен — уменьши размер таба при просмотре. В этом случае подстраивать код ты не должен. А если критичен — то подстраивать ты будешь код и с пробелами. В этом и профит. D>найти код с 8-ю пробелами отступа — задача не из простых...
Зато часто попадается с одним, или с двумя, и иногда с тремя. Подстраиваться всё равно приходится.
D>а получить тот же отступ на табе — легче легкого
Это как? Отступ на табе всегда ровно один таб.
D>вместе с геморроем "где то место, уменьшающее таб"
Если это доставляет хоть малейшее неудобство, то вылечить этот гемморой занимает минуту. А если тебе попался код не с твоим любимым количеством пробелов, то это вообще практически не лечится.
D>код с пробелами подстраивать не надо — больше 4-х
Зато меньше используют довольно часто.
D>вменяемые люди обычно не используют
Если так заявлять, то проще заявить что вменяемые люди пробелы не используют.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Don Reba, Вы писали:
DR>Здравствуйте, Qbit86, Вы писали:
Q>>А зачем их ignore? Их не надо ignore. Кроме того, это не спасёт от конфликтов. Скажем, в такой табличке кто-то в одной строке изменил тип, увеличив его на пару символов; кто-то другой исправил имя в другой строке, уменьшив самую длинную строку. Оба переверстали.
DR>Я считаю редкие, легко разрешимые конфликты приемлемой ценой за повышение читаемости кода.
Ничего себе легко разрешимые, а у вас методы в классах как отсортированы? По модификатором доступа? А внутри по алфавиту отсортированы?
·>Некоторые проекты просто ссылаются на linux kernel style.
«The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.» Серьёзно, три уровня? Там код только начинается, если в языке есть пространства имён и классы.
«Это их внутренние стандарты, которые редко меняют из-за бюрократии и того, что уже тонны кода в таком формате написаны.» Гайдлайны из прошлого тысячелетия, Карл.
Приведённые же выше гайдлайны от Гугла эволюционировали на глазах за последние несколько лет, с постепенным осторожным внедрением C++11.
·>...пробелы запрещены для отступов законодательно, высшая мера наказания и кода с пробелами не существует. Ты видишь какие-нибудь проблемы в этой вселенной?
Конечно вижу, я даже собственный код не смогу видеть единообразным в разных просмотрщиках. Не говоря уже о том, что сетка канваса редактора (при моноширинном шрифте) становится фейком. Символы занимают не те колонки, какие кажутся. Грубо говоря, управляющие символы ломают plain text. В создаваемую с нуля вселенную не стоит тащить наследие времён Телетайпа сорокалетней давности.
·>Как минимум будут войны на тему сколько пробелов должно быть в отступах — 2, 4 или 8 или 13.
Как-то же получается договариваться насчёт египетских скобок, `SNAKE_CASE` и транслита в идентификаторах?
·>а почему бы не заменить стандартные четыре символа на специальный символ со специальным кодом, и кнопку бы неплохо добавить... ведь нажимать четырежды сложнее?
Кнопку конечно, не плохо бы добавить, чтоб выравнивала пробелами по настроенному количеству знакомест. Но отдельный управляющий символ со специальным кодом? В современном мире не нужен.
·>Патч уже постили? Разрабы наотрез отказались мержить?
Это проприетарный редактор. И никто не будет тратить время на то, чтобы вместо простой вставки текста файла в стандартный компонент какого-нибудь фреймфорка а-ля `myLabel.SetText("File content")` тратить ресурсы на предварительную обработку содержимого, умную замену табуляции, etc.
·>Ок, никогда это не видел, но можно поверить, что одна такая прога есть.
Чувак, да их тысячи — программ, содержащих label'ы и textedit'ы с пользовательским текстом. Мессенджеры всякие (кстати, Скайп вставляет _один_ пробел вместо табуляции), заметки типа Google Keep, мобильные браузеры, книгочиталки. Чтобы иметь предсказуемый вид для своего же текста в случае табуляции нужно затратить слишком много усилий.
·>С бразуерами всё просто. ·>Как сделать user style css думаю сам разберёшься.
Да ты троллишь просто, да? У меня нет времени на кормёжку.
Q>>Unity 3D... При использовании табов получается таже не куча пустого места, а просто месиво разорванных строк. ·>А при использовании восьми пробелов что происходит?
Восемь порбелов, кстати, занимают меньше места, чем табулированный отступ. В окошке Инспектора текст отображается не моноширинным шрифтом.
Здравствуйте, ·, Вы писали:
·>Кстати, о теории. В теории пробелы тоже критику не выдерживают. ·>Представь себе альтернативную вселенную, где пробелы запрещены для отступов законодательно, высшая мера наказания и кода с пробелами не существует. Ты видишь какие-нибудь проблемы в этой вселенной?
"Тысячи их" (c).
Какой отступ на продолжения многострочного оператора? 0, 1, 2 таба? Я видел все эти варианты.
Если нужно несколько сходных записей одна под другой, и удобно сделать их на одном отступе, разрешать ли такой отступ для первой? Например: (во всех примерах 4 пробела за таб)
someTerribleFunction(aaa,
bbb,
ccc,
ddd);
(1)
someTerribleFunction(
aaa,
bbb,
ccc,
ddd);
(2)
someTerribleFunction(
aaa,
bbb,
ccc,
ddd
);
(3)
someTerribleFunction
( aaa,
bbb,
ccc,
ddd
);
(4)
someTerribleFunction( aaa,
bbb,
ccc,
ddd);
(5)
someTerribleFunction ( aaa,
bbb,
ccc,
ddd
);
(6)
Какой выберешь и почему? Как докажешь свой выбор соседу по комнате?
·>А теперь представь другую вселенную: табы запрещены, или их вообще не существовало, и кнопки такой нет. Будут ли проблемы — по-моему да. Как минимум будут войны на тему сколько пробелов должно быть в отступах — 2, 4 или 8 или 13. Притом, даже если законодательно закрепят какое-то число, например 4, то возникнет вопрос — а почему бы не заменить стандартные четыре символа на специальный символ со специальным кодом, и кнопку бы неплохо добавить... ведь нажимать четырежды сложнее? Придётся комбинацию клавиш добавлять или специальную кнопку в клавиатуры, текстовые редакторы должны будут поддерживать вставку/удаление четырех пробелов.
Они и так это давно поддерживают. Кроме ну самых примитивных.
·>Каждый настраивает под себя как и где ему удобно. Проблема с пробелами возникает когда разные люди с разными настройками начинают работать над одними и теми же файлами. С табами проблем нет, т.к. они учитывают "настойки под себя".
Здравствуйте, Lexey, Вы писали:
N>>Реально на сейчас табуляция в коде просто вредна — экономия ничтожна, а проблемы из-за разной ширины значительно существеннее.
L>Кому вредна? Мне она очень удобна.
Угу, пока работаешь "без ансамбля".
L> Никаких проблем нет, если код не начинают править любители замены табов на пробелы.
примеры оператора, который в любом варианте выглядит для кого-то криво. И я там не упомянул один вариант, несовместимый с табами: bbb ровно под aaa, но aaa выровнен без лишних табов. Это возможно только при определённой сетке значений длины имени функции.
Что, будешь подгонять все имена функций под стандарт "кратно ширине таба, и минус 1"?
А потом и имена классов, если надо написать в виде ${class}.${method}?
L>Вот тогда начинается геморрой с переформатированием, ибо у одного стоит таб = 4 пробела, у другого 2, etc.
Нет, не начинается. Потому что есть общий стиль для файла, который нормальные люди не ломают, и пишут в modeline.
DR>Не зависит от ширины таба и наглядно показывает структуру кода.
И самый ужасный для огромной доли пишущих.
UPD: ещё и требующих настолько много усилий для создания всего этого форматирования, что будешь послан нафиг всеми, кто (справедливо) считает, что форматирование должно быть как можно проще, в идеале — само выполняться без тебя по настроенным правилам. Автомат же для подобного явно не будут писать
Здравствуйте, ·, Вы писали: ·>Зато часто попадается с одним, или с двумя, и иногда с тремя. Подстраиваться всё равно приходится.
не-а... 1-2-3 лишних пробела обычно читабельность не нарушают, в отличии от 1-3 табов по 8
а если с кодом надо работать — это проблема форматтера его выровнять так, как я его настроил
D>>а получить тот же отступ на табе — легче легкого ·>Это как? Отступ на табе всегда ровно один таб.
на первом уровне вложения 1, на втором — 2, дальше продолжать?
D>>вместе с геморроем "где то место, уменьшающее таб" ·>Если это доставляет хоть малейшее неудобство, то вылечить этот гемморой занимает минуту.
даю вам минуту, чтобы вылечить просмотрщик/редактор Far Manager
·>А если тебе попался код не с твоим любимым количеством пробелов, то это вообще практически не лечится.
для чтения — и не надо, для работы — любой форматтер D>>код с пробелами подстраивать не надо — больше 4-х ·>Зато меньше используют довольно часто.
не мешает ·>Если так заявлять, то проще заявить что вменяемые люди пробелы не используют.
используют... сам видел
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>[/sql]
21й век на дворе, а до сих пор никто не приделал в редактор исходников поддержку вордовых таблиц. Вместо этого всё какие-то птичьи языки никому не нужные изобретают, и иконки обесцвечивают.
Здравствуйте, Qbit86, Вы писали:
Q>·>Некоторые проекты просто ссылаются на linux kernel style. Q>«The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.» Серьёзно, три уровня? Там код только начинается, если в языке есть пространства имён и классы. Q>«Это их внутренние стандарты, которые редко меняют из-за бюрократии и того, что уже тонны кода в таком формате написаны.» Гайдлайны из прошлого тысячелетия, Карл.
Допустим. Суть в том, что 4 пробела — не единственный вариант с пробелами, пробельщики договориться друг с другом не могут. В ruby афаир 2 пробела. Да ты сам с собой договриться не можешь — какие-то уже "нормальные" и "компактные" отступы придумал, притом в зависимости от желания левой пятки.
Q>Приведённые же выше гайдлайны от Гугла эволюционировали на глазах за последние несколько лет, с постепенным осторожным внедрением C++11.
По-моему, просто сложилось исторически. Замена пробелов-табов не настолько критична, чтобы заморачиваться изменением гайдлайнов.
Q>·>...пробелы запрещены для отступов законодательно, высшая мера наказания и кода с пробелами не существует. Ты видишь какие-нибудь проблемы в этой вселенной? Q>Конечно вижу, я даже собственный код не смогу видеть единообразным в разных просмотрщиках. Не говоря уже о том, что сетка канваса редактора (при моноширинном шрифте) становится фейком. Символы занимают не те колонки, какие кажутся. Грубо говоря, управляющие символы ломают plain text. В создаваемую с нуля вселенную не стоит тащить наследие времён Телетайпа сорокалетней давности.
Не понял почему. Что становится фейком? Что именно ломают? Почему у меня не ломают? У меня везде стоит ширина таба 4 по дефолту, кроме kdiff3 и xml/html-файлов — 2.
Q>·>Как минимум будут войны на тему сколько пробелов должно быть в отступах — 2, 4 или 8 или 13. Q>Как-то же получается договариваться насчёт египетских скобок, `SNAKE_CASE` и транслита в идентификаторах?
Так не получается же. А так хотя бы одной проблемой было бы меньше.
Q>·>а почему бы не заменить стандартные четыре символа на специальный символ со специальным кодом, и кнопку бы неплохо добавить... ведь нажимать четырежды сложнее? Q>Кнопку конечно, не плохо бы добавить, чтоб выравнивала пробелами по настроенному количеству знакомест.
И как бы редакторы поддерживали разные настройки у разных пользователей? Кому-то нравится два, кому-то четыре, кому-то восемь.
Q>Но отдельный управляющий символ со специальным кодом? В современном мире не нужен.
Расскажи это консорциуму Unicode.
Q>·>Патч уже постили? Разрабы наотрез отказались мержить? Q>Это проприетарный редактор. И никто не будет тратить время на то, чтобы вместо простой вставки текста файла в стандартный компонент какого-нибудь фреймфорка а-ля `myLabel.SetText("File content")` тратить ресурсы на предварительную обработку содержимого, умную замену табуляции, etc.
Т.е. я понял. Главная проблема в том, что дефолтный размер таба — 8 символов. Было бы 4 — проблем бы не было.
Q>·>Ок, никогда это не видел, но можно поверить, что одна такая прога есть. Q>Чувак, да их тысячи — программ, содержащих label'ы и textedit'ы с пользовательским текстом. Мессенджеры всякие (кстати, Скайп вставляет _один_ пробел вместо табуляции), заметки типа Google Keep, мобильные браузеры, книгочиталки. Чтобы иметь предсказуемый вид для своего же текста в случае табуляции нужно затратить слишком много усилий.
Вид текста от размера табуляции не зависит. Мы же говорим об отступах (indent) табуляцией, а не о выравнивании (alignment).
Собственно почему люди не могут договориться о размере отступа, потому что нет единственного "правильного" значения. Слишком маленький отступ ухудшает читаемость, а слишком большой отступ — увеличивает горизонтальный размер текста и он не влазит в окно, поэтому любое конкретное значение — компромисс. А значит единственный разумный подход — сделать размер отступа изменяемым, а это можно сделать только используя специальный символ табуляции для обозначения отступов, чтобы по месту можно было варьировать его величину. С пробелами эта задача решения не имеет.
Q>·>С бразуерами всё просто. Q>·>Как сделать user style css думаю сам разберёшься. Q>Да ты троллишь просто, да? У меня нет времени на кормёжку.
Ээ.. Это ты троллишь про "почти все программы". Как начинаю разбираться — так выясняется, таких программ одна штука, притом довольно специфичная.
Q>>>Unity 3D... При использовании табов получается таже не куча пустого места, а просто месиво разорванных строк. Q>·>А при использовании восьми пробелов что происходит? Q>Восемь порбелов, кстати, занимают меньше места, чем табулированный отступ. В окошке Инспектора текст отображается не моноширинным шрифтом.
Эээ.. По-моему бага какая-то.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, netch80, Вы писали:
N>·>Кстати, о теории. В теории пробелы тоже критику не выдерживают. N>·>Представь себе альтернативную вселенную, где пробелы запрещены для отступов законодательно, высшая мера наказания и кода с пробелами не существует. Ты видишь какие-нибудь проблемы в этой вселенной?
N>"Тысячи их" (c). N>Какой отступ на продолжения многострочного оператора? 0, 1, 2 таба? Я видел все эти варианты.
Ты с темы не слезай. Ты расскажи вначале решение этой проблемы в вселенной с пробелами.
Я не утверждал, что табы решают все проблемы, рак, думаю, они не вылечат. Они решают проблему размера отступов.
N>Они и так это давно поддерживают. Кроме ну самых примитивных.
Так себе поддерживают, ибо задача не имеет простого алгоритмического решения. Никогда не попадались файлы с разным количеством пробелов в отступе в разных строках?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, mDmitriy, Вы писали:
D>·>Зато часто попадается с одним, или с двумя, и иногда с тремя. Подстраиваться всё равно приходится. D>не-а... 1-2-3 лишних пробела обычно читабельность не нарушают, в отличии от 1-3 табов по 8
Ну поставь размер таба в 4.
D>а если с кодом надо работать — это проблема форматтера его выровнять так, как я его настроил
А ещё проблема мержа, диффа, патча, ревьювера и т.п.
D>>>а получить тот же отступ на табе — легче легкого D>·>Это как? Отступ на табе всегда ровно один таб. D>на первом уровне вложения 1, на втором — 2, дальше продолжать?
Продолжай.
D>>>вместе с геморроем "где то место, уменьшающее таб" D>·>Если это доставляет хоть малейшее неудобство, то вылечить этот гемморой занимает минуту. D>даю вам минуту, чтобы вылечить просмотрщик/редактор Far Manager
Для установки дефолтного значения: F9 -> Options -> Viewer Settings -> Tab size
Для временного изменения в открытом просмотрщике: Alt+Shift+F9 -> Tab size
D>>>код с пробелами подстраивать не надо — больше 4-х D>·>Зато меньше используют довольно часто. D>не мешает
Т.е. тебе просто тупо не нравится дефолт в 8 пробелов. Можешь себе локальный рай устроить — поменяй дефолт в 4 пробела.
D>·>Если так заявлять, то проще заявить что вменяемые люди пробелы не используют. D>используют... сам видел
Рыбак рыбака...
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
примеры оператора, который в любом варианте выглядит для кого-то криво. И я там не упомянул один вариант, несовместимый с табами: bbb ровно под aaa, но aaa выровнен без лишних табов. Это возможно только при определённой сетке значений длины имени функции.
Ключевое слово я выделил. ИМХО, вменяемые там только варианты 1 — 3. Для меня они будут нормально выглядеть и с другим размером таба.
Хотя, предпочту я такой стиль:
public void SomeFunction(int a
, int b
, string c)
{
}
В общем, опять получается спор о вкусе фломастеров.
L>>Вот тогда начинается геморрой с переформатированием, ибо у одного стоит таб = 4 пробела, у другого 2, etc. N>Нет, не начинается. Потому что есть общий стиль для файла, который нормальные люди не ломают, и пишут в modeline.
Начинается. Потому что новый человек лезет в старый код с другими настройками редактора. И может даже не замечать, что форматирование съехало. Результаты такого редактирования видел неоднократно.
Что такое "modeline", понятия не имею.
Здравствуйте, Lexey, Вы писали: L>Хотя, предпочту я такой стиль: L>
L> public void SomeFunction(int a
L> , int b
L> , string c)
L> {
L> }
L>
Запятая в начале строки, для того, что бы, при добавлении строки, нужно было изменить одну строчку вместо двух? )
Задолбали эти стили, если честно. По одному гайду надо так скобку ставить, по другому сяк, по третьему наперекосяк.
Нет бы, делали так, что-бы компилятор, только один вариант синтаксиса переваривал.
Здравствуйте, ·, Вы писали:
·>В ruby афаир 2 пробела.
Так и есть, выше была ссылка на style guide. Два пробела, и никаких табов.
Q>>...сетка канваса редактора (при моноширинном шрифте) становится фейком. Символы занимают не те колонки, какие кажутся. Грубо говоря, управляющие символы ломают plain text. ·>Не понял почему. Что становится фейком? Что именно ломают? Почему у меня не ломают? У меня везде стоит ширина таба 4 по дефолту.
Посмотри на статус-строку в Visual Studio под открытым файлол. Видишь там цифры типа «Col 17» и «Ch 17»? При честных пробелах эти цифры одинаковые; у тебя — нет.
·>Так не получается же. А так хотя бы одной проблемой было бы меньше.
По факту, с табуляцией одной проблемой больше.
·>И как бы редакторы поддерживали разные настройки у разных пользователей? Кому-то нравится два, кому-то четыре, кому-то восемь.
С табуляцией даже для одного пользователя тяжело добиться одинакового отображения.
·>Ээ.. Это ты троллишь про "почти все программы". Как начинаю разбираться — так выясняется, таких программ одна штука, притом довольно специфичная.
Здравствуйте, UberPsychoSvin, Вы писали:
UPS>Запятая в начале строки, для того, что бы, при добавлении строки, нужно было изменить одну строчку вместо двух? )
Если добавляемая строка не становится первой или последней, то (в смысле минимальности диффа) всё равно, где запятая.
Иногда встречаются контексты, где запятую можно использовать как delimiter, а не separator. Скажем, в C# можно хвостовую запятую ставить в enum'ах или инициализации списков. Но в таких случаях запятая всегда справа от элемента, и никогда слева (как буллит в списке).
Здравствуйте, Osaka, Вы писали:
O>21й век на дворе, а до сих пор никто не приделал в редактор исходников поддержку вордовых таблиц. Вместо этого всё какие-то птичьи языки никому не нужные изобретают, и иконки обесцвечивают.
В Emacs есть редактор таблиц. И даже есть электронные таблицы в Org-Mode (заметки, Outliner, Reproducible Research а-ля Ipython/Jupyter, Literate Programming).
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Osaka, Вы писали:
O>>21й век на дворе, а до сих пор никто не приделал в редактор исходников поддержку вордовых таблиц. Вместо этого всё какие-то птичьи языки никому не нужные изобретают, и иконки обесцвечивают.
EP>В Emacs есть редактор таблиц. И даже есть электронные таблицы в Org-Mode (заметки, Outliner, Reproducible Research а-ля Ipython/Jupyter, Literate Programming).
Отдельно я и excel могу запустить. А вот чтобы название функции текстом, дальше таблица с параметрами {тип, имя, размер}, дальше снова текстом код. И чтобы компилятор это понимал, и diff бы отображался.
Здравствуйте, Lexey, Вы писали:
L>Ключевое слово я выделил. ИМХО, вменяемые там только варианты 1 — 3. Для меня они будут нормально выглядеть и с другим размером таба.
Ну то есть, что aaa отрывается от выравнивания с остальными, тебя устраивает. Понятно.
L>В общем, опять получается спор о вкусе фломастеров.
Вопрос в том, что ряд особенностей "вкуса фломастера" устраивает почти всех, а некоторые — слишком радикальны, чтобы кого-то устроить.
Стили, которые отработаны в большом проекте, тем и интересны, что обычно уже являются результатами консенсуса между совершенно разными людьми.
L>Начинается. Потому что новый человек лезет в старый код с другими настройками редактора. И может даже не замечать, что форматирование съехало. Результаты такого редактирования видел неоднократно.
Если у редактора нет желания переконвертить под себя всё, включая то, что не трогалось, а у человека — элементарный опыт писать более-менее похоже на то, что он видит вокруг — больших проблем не будет. На отдельные незамеченные детальки есть peer review, а если последнего нет — то и не так страшно.
L>Что такое "modeline", понятия не имею.
Механизм vim и emacs по указанию параметров форматирования для конкретного файла, задаётся строчкой из первых или последних 3 строк файла.
Как минимум предпочтение табов или пробелов там задаётся (et/noet), ширина таба (ts), стандартный отступ (sw) — это всё в названиях vim.
Здравствуйте, ·, Вы писали:
N>>·>Кстати, о теории. В теории пробелы тоже критику не выдерживают. N>>·>Представь себе альтернативную вселенную, где пробелы запрещены для отступов законодательно, высшая мера наказания и кода с пробелами не существует. Ты видишь какие-нибудь проблемы в этой вселенной?
N>>"Тысячи их" (c). N>>Какой отступ на продолжения многострочного оператора? 0, 1, 2 таба? Я видел все эти варианты. ·>Ты с темы не слезай.
Это я, оказывается, слезаю с темы?
·> Ты расскажи вначале решение этой проблемы в вселенной с пробелами.
Во-первых, не указывай другим, что делать, и они не скажут, куда тебе пойти.
Я потому и не хочу зацикливаться на одном твоём вопросе именно потому, что считаю его малосущественным по сравнению со многими другими в оформлении кода.
Во-вторых, если уж ты хочешь в первую очередь прямого ответа на это — я просто не считаю, что это проблема. В моих краях это обычно решается тем, что нажатие Tab вставляет нужное количество пробелов, а нажатие BS на пустом месте его съедает, и этого достаточно, чтобы поддерживать согласованный вариант. Я просто не вижу глубокого смысла в желании иметь какой-то плавный ползунок, которым регулировать эти отступы, расширяя и сжимая текст; но если кому-то это нужно — это реализуется и на пробелах. Да, пожалуй, ещё нельзя сказать "элементарно реализуется" — проблема в продолжениях операторов.
И вот тут как раз видно, что это ты "слезаеш с темы" — ты, а не я.
Потому что мои примеры ты поскипал и не ответил. А между тем примеры 5 и 6 как раз на тему того, как испортится выравнивание при табуляциях, меняющих длину.
·>Я не утверждал, что табы решают все проблемы, рак, думаю, они не вылечат. Они решают проблему размера отступов.
Ещё и ёрничаешь на ровном месте.
N>>Они и так это давно поддерживают. Кроме ну самых примитивных. ·>Так себе поддерживают, ибо задача не имеет простого алгоритмического решения. Никогда не попадались файлы с разным количеством пробелов в отступе в разных строках?
В смысле — часть табами, часть пробелами? Попадались. И что?
Там, где отступы принципиально важны для интерпретации (как в Python или Makefile), это вызывает просто ошибку компиляции. Там, где не важны (C с компанией), там нет проблем для машины; а для человека — один лишний раз дочистить.
Выдержка единого средства (табы или пробелы) тут важнее, чем выбор между ними; но при выборе уже между ними я предпочту пробелы из-за заведомо меньшей конфликтности для таких ситуаций.
И тут же — я участвовал в разработке софтин, в стиле которых было принято tabstop=8, но shiftwidth=4. Отступ кратный 8 делался только табами, а кратный 4, но не 8 — табы плюс 4 пробела. Между прочим, такой стиль ну очень распространён. И ты его своими "плавными" регулированиями сломаешь на корню
Здравствуйте, AndrewVK, Вы писали:
N>>Какой выберешь и почему? Как докажешь свой выбор соседу по комнате?
AVK>А зачем это нужно доказывать соседу по комнате?
Извини, я всё время забываю про существование openspace.
Здравствуйте, Osaka, Вы писали:
EP>>В Emacs есть редактор таблиц. И даже есть электронные таблицы в Org-Mode (заметки, Outliner, Reproducible Research а-ля Ipython/Jupyter, Literate Programming). O>Отдельно я и excel могу запустить.
В Org-Mode электронные таблицы (+ формулы, + изображения) вперемешку с кодом. Они могут вводится вручную, быть результатом блока кода (на разных языках), и подаваться в качестве переменной в другой блок кода.
O>А вот чтобы название функции текстом, дальше таблица с параметрами {тип, имя, размер}, дальше снова текстом код. И чтобы компилятор это понимал, и diff бы отображался.
Если нужно чтобы компилятор понимал, то придётся делать либо дополнительный препроцессинг, либо не вставлять разметку таблицы в код, а только отображать её визуально. То есть в редакторе ты будешь видеть список параметров как таблицу, а в самом исходнике всё будет по обычному. На подобную технику есть режим GlassesMode:
GlassesMode changes the way StudlyCaps/CamelCase is displayed so you can see the difference. The default setting is to separate the Capped bits with an underscore, so EmacsIsStudly shows as Emacs_Is_Studly.
При необходимости подобное можно сделать и для таблиц.
Здравствуйте, Qbit86, Вы писали:
Q>·>В ruby афаир 2 пробела. Q>Так и есть, выше была ссылка на style guide. Два пробела, и никаких табов.
Сочувствую.
Q>>>...сетка канваса редактора (при моноширинном шрифте) становится фейком. Символы занимают не те колонки, какие кажутся. Грубо говоря, управляющие символы ломают plain text. Q>·>Не понял почему. Что становится фейком? Что именно ломают? Почему у меня не ломают? У меня везде стоит ширина таба 4 по дефолту. Q>Посмотри на статус-строку в Visual Studio под открытым файлол. Видишь там цифры типа «Col 17» и «Ch 17»? При честных пробелах эти цифры одинаковые; у тебя — нет.
Эээ... И что? Почему это проблема?
Q>·>Так не получается же. А так хотя бы одной проблемой было бы меньше. Q>По факту, с табуляцией одной проблемой больше.
Объясни вначале что это проблема. Какие неудобства создаёт?
Q>·>И как бы редакторы поддерживали разные настройки у разных пользователей? Кому-то нравится два, кому-то четыре, кому-то восемь. Q>С табуляцией даже для одного пользователя тяжело добиться одинакового отображения.
Не надо повторять это. Лучше объясни что значит добиться одинакового и в чём тяжесть.
Q>·>Ээ.. Это ты троллишь про "почти все программы". Как начинаю разбираться — так выясняется, таких программ одна штука, притом довольно специфичная. Q>Так что насчёт Скайпа? Слишком специфичная?
А что не так в скайпе? Пусть рисует табы шириной в один пробел, что в общем-то логично для узкого окна чата. Считай что в коде отступы сделаны одним пробелом.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, netch80, Вы писали: N>Если нужно несколько сходных записей одна под другой, и удобно сделать их на одном отступе, разрешать ли такой отступ для первой? Например: (во всех примерах 4 пробела за таб)
N>Какой выберешь и почему? Как докажешь свой выбор соседу по комнате?
Я правильно понял, что во всех примерах строчки-продолжения отбиты табами? Это — наркомания, которую надо лечить лоботомией.
Правильный вариант — это в каждой из строчек одинаковое количество табов в начале, а межстрочное выравнивание добито пробелами.
Потому что табы — это уровень nesting-а кода, который тут везде одинаков:
Здравствуйте, netch80, Вы писали:
N>>>Какой отступ на продолжения многострочного оператора? 0, 1, 2 таба? Я видел все эти варианты. N>·>Ты с темы не слезай. N>Это я, оказывается, слезаю с темы?
Ты хочешь сказать, что я слезаю? В каком месте?
N>·> Ты расскажи вначале решение этой проблемы в вселенной с пробелами. N>Во-первых, не указывай другим, что делать, и они не скажут, куда тебе пойти. N>Я потому и не хочу зацикливаться на одном твоём вопросе
Я решаю один вопрос, а ты вносишь другие. Притом они вообще никак не связаны с изначальным. Как делать _отступы_ (не выравнивание!) в многострочных выражениях от табов/пробелов никак не зависит.
N>именно потому, что считаю его малосущественным по сравнению со многими другими в оформлении кода.
Это и называется слезать с темы. Вопросы оформления кода так же малосущественны по сравнению с многими другими, которые могут возникнуть в жизни программиста. Например, как вылечить рак.
N>Во-вторых, если уж ты хочешь в первую очередь прямого ответа на это — я просто не считаю, что это проблема. В моих краях это обычно решается тем, что нажатие Tab вставляет нужное количество пробелов,
Ты мне точно скажи какое количество пробелов нужное? И объясни почему все не используют именно это количество.
N>а нажатие BS на пустом месте его съедает, и этого достаточно, чтобы поддерживать согласованный вариант. Я просто не вижу глубокого смысла в желании иметь какой-то плавный ползунок, которым регулировать эти отступы, расширяя и сжимая текст; но если кому-то это нужно — это реализуется и на пробелах. Да, пожалуй, ещё нельзя сказать "элементарно реализуется" — проблема в продолжениях операторов.
Не реализуется это на пробелах. Как мне такое реализовать на пробелах, если в окне редактора я хочу видеть четыре пробела, т.к. удобнее читать, а в окне мержа с тремя столбиками мне нужно 1 или два пробела, т.к. иначе в ширину экрана не помещается?
N>И вот тут как раз видно, что это ты "слезаеш с темы" — ты, а не я. N>Потому что мои примеры ты поскипал и не ответил. А между тем примеры 5 и 6
(5) и (6) вообще страх какой-то. Я думал ты по приколу их предложил. Они кстати разъедутся и при простом переименовании функции например. Если тебе и правда интересно моё мнение, то я предпочту (2) или может быть (3), а (1) может сгодиться если первый параметр функции какой-то особый.
N>как раз на тему того, как испортится выравнивание при табуляциях, меняющих длину.
Опять двадцать пять. Не надо путать выравниваение (alignment) и отступ (indent).
N>·>Я не утверждал, что табы решают все проблемы, рак, думаю, они не вылечат. Они решают проблему размера отступов. N>Ещё и ёрничаешь на ровном месте.
Не люблю тупую софистику.
N>·>Так себе поддерживают, ибо задача не имеет простого алгоритмического решения. Никогда не попадались файлы с разным количеством пробелов в отступе в разных строках? N>В смысле — часть табами, часть пробелами? Попадались. И что?
Нет, часть двумя пробелами, часть четырьмя, а местами случайно вставлено три.
N>Там, где отступы принципиально важны для интерпретации (как в Python или Makefile), это вызывает просто ошибку компиляции. Там, где не важны (C с компанией), там нет проблем для машины; а для человека — один лишний раз дочистить. N>Выдержка единого средства (табы или пробелы) тут важнее, чем выбор между ними; но при выборе уже между ними я предпочту пробелы из-за заведомо меньшей конфликтности для таких ситуаций.
Так с пробелами возникнет конфликт с их количеством. Поэтому я выбираю табы.
N>И тут же — я участвовал в разработке софтин, в стиле которых было принято tabstop=8, но shiftwidth=4. Отступ кратный 8 делался только табами, а кратный 4, но не 8 — табы плюс 4 пробела. Между прочим, такой стиль ну очень распространён. И ты его своими "плавными" регулированиями сломаешь на корню
Жуть конечно. Но если ставить ширину таба больше 4, то проблем не будет.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Sinclair, Вы писали:
S>Правильный вариант — это в каждой из строчек одинаковое количество табов в начале, а межстрочное выравнивание добито пробелами. S>
Здравствуйте, ·, Вы писали: D>>не-а... 1-2-3 лишних пробела обычно читабельность не нарушают, в отличии от 1-3 табов по 8 ·>Ну поставь размер таба в 4.
и в каком волшебном месте это можно сделать один раз на все? D>>а если с кодом надо работать — это проблема форматтера его выровнять так, как я его настроил ·>А ещё проблема мержа, диффа, патча, ревьювера и т.п.
нет у меня такой проблемы... "ignore spaces" рулит D>>на первом уровне вложения 1, на втором — 2, дальше продолжать? ·>Продолжай.
продолжаю — количество видимых на экране уровней обратно пропорционально размеру таба D>>даю вам минуту, чтобы вылечить просмотрщик/редактор Far Manager ·>Для установки дефолтного значения: F9 -> Options -> Viewer Settings -> Tab size ·>Для временного изменения в открытом просмотрщике: Alt+Shift+F9 -> Tab size
раз
даю еще минуту для Notepada
ну и чтобы два раза не вставать — для просмотрщика строк в отладчике студии (и для текста, для и xml)
·>Т.е. тебе просто тупо не нравится дефолт в 8 пробелов. Можешь себе локальный рай устроить — поменяй дефолт в 4 пробела.
мне тупо не нравится/лень/нет времени ползать по настройкам разных программных продуктов и устанавливать у них размер таба
был приятно удивлен, что есть любители подобного времяпровождения
·>Рыбак рыбака...
вменяемых людей не так мало как кажется, %username%...
Здравствуйте, ·, Вы писали:
Q>>·>Так не получается же. А так хотя бы одной проблемой было бы меньше. Q>>По факту, с табуляцией одной проблемой больше.
...Как в комик-стрипе про N+1 стандарт.
Q>>С табуляцией даже для одного пользователя тяжело добиться одинакового отображения.
·>Не надо повторять это. Лучше объясни что значит добиться одинакового и в чём тяжесть. ·>Объясни вначале что это проблема. Какие неудобства создаёт? ·>А что не так в скайпе? Пусть рисует табы шириной в один пробел, что в общем-то логично для узкого окна чата. Считай что в коде отступы сделаны одним пробелом.
Допустим, ты расшариваешь код-сниппет с кем-то через Битбакет или Скайп. Твой адресат ожидает увидеть нормально отформатированный код. Вместо этого видит отступы шириной 8 знакомест, в другом месте шириной 1 (а в случае пропорционального шрифта вообще непонятно какого размера). Что ты ему скажешь? «Твои проблемы: настроить экстеншны и css-стили в браузере плёвое дело. И вообще считай, что я изначально набирал с восьмерными или одинарными отступами. Шли реквест в Майкрософт чтобы добавили настройку табуляции в Скайпе!»
Здравствуйте, Qbit86, Вы писали:
Q>Допустим, ты расшариваешь код-сниппет с кем-то через Битбакет или Скайп. Твой адресат ожидает увидеть нормально отформатированный код. Вместо этого видит отступы шириной 8 знакомест, в другом месте шириной 1 (а в случае пропорционального шрифта вообще непонятно какого размера). Что ты ему скажешь? «Твои проблемы: настроить экстеншны и css-стили в браузере плёвое дело. И вообще считай, что я изначально набирал с восьмерными или одинарными отступами. Шли реквест в Майкрософт чтобы добавили настройку табуляции в Скайпе!»
Ты так говоришь, как будто это что-то плохое. Допустим видит. И что?
Нормальность нормально отформатированного кода от ширины таба не зависит.
А что ты ему скажешь если ты ему посылаешь xml набранный с четырмя пробелами на 26", а на его 10" планшетике он занимает в ширину в три экрана?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали: ·>А что ты ему скажешь если ты ему посылаешь xml набранный с четырмя пробелами на 26", а на его 10" планшетике он занимает в ширину в три экрана?
Я тем временем смеюсь с темы разговора. Вы вообще пробовали код в Скайпе отправлять? В контексте замены комментариев смайликами всерьёз рассуждать о важности табов или пробелов может только шизофреник.
На всякий случай напомню, что в скайпе вообще нельзя сделать ширину разговора больше захардкоженной производителем. ЛЮБОЙ код превращается в скайпе в нечитаемое месиво.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, ·, Вы писали:
·>А что ты ему скажешь если ты ему посылаешь xml набранный с четырмя пробелами на 26", а на его 10" планшетике он занимает в ширину в три экрана?
Это хотя бы предсказуемо и надёжно. Не то что настраивать CSS-стили в мобильном браузере на планшете, чтобы у тебя восьмизнаковый таб не превращал ширину документа в шесть экранов.
Здравствуйте, Sinclair, Вы писали:
S>·>А что ты ему скажешь если ты ему посылаешь xml набранный с четырмя пробелами на 26", а на его 10" планшетике он занимает в ширину в три экрана? S>Я тем временем смеюсь с темы разговора. Вы вообще пробовали код в Скайпе отправлять? В контексте замены комментариев смайликами всерьёз рассуждать о важности табов или пробелов может только шизофреник.
Добавь в начало сообщения то что в кавычках "!! ", потом код — там и смайлки не подставляются, и шрифт моноширинный.
S>На всякий случай напомню, что в скайпе вообще нельзя сделать ширину разговора больше захардкоженной производителем.
Ширина разговора меняется мышкой, за край области "Type a message here".
S>ЛЮБОЙ код превращается в скайпе в нечитаемое месиво.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Добавь в начало сообщения то что в кавычках "!! ", потом код — там и смайлки не подставляются, и шрифт моноширинный.
Причём, табы по прежнему отображаются одним пробелом (тестовый гист).
Здравствуйте, Sinclair, Вы писали:
S>Он не нравится лично мне тем, что переход между "короткий список аргументов" и "длинный список аргументов" слишком резкий.
Закрывающую скобку не обязательно переносить на новую строку.
someNiceFunction(aaa); // так?
someNiceFunction( // или так?
aaa);
Здравствуйте, ·, Вы писали:
N>>>>Какой отступ на продолжения многострочного оператора? 0, 1, 2 таба? Я видел все эти варианты. N>>·>Ты с темы не слезай. N>>Это я, оказывается, слезаю с темы? ·>Ты хочешь сказать, что я слезаю? В каком месте?
То есть ты отвечаешь, не прочитав всё письмо.
N>>·> Ты расскажи вначале решение этой проблемы в вселенной с пробелами. N>>Во-первых, не указывай другим, что делать, и они не скажут, куда тебе пойти. N>>Я потому и не хочу зацикливаться на одном твоём вопросе ·>Я решаю один вопрос, а ты вносишь другие. Притом они вообще никак не связаны с изначальным. Как делать _отступы_ (не выравнивание!) в многострочных выражениях от табов/пробелов никак не зависит.
Именно что напрямую зависит, потому что эти отступы делаются по многим канонам именно табами, и твоё свободное варьирование их ширины сломает форматирование.
N>>Во-вторых, если уж ты хочешь в первую очередь прямого ответа на это — я просто не считаю, что это проблема. В моих краях это обычно решается тем, что нажатие Tab вставляет нужное количество пробелов, ·>Ты мне точно скажи какое количество пробелов нужное? И объясни почему все не используют именно это количество.
Согласно канону. Который в каждом месте может быть свой.
Точно так же и с табами. Почему ты считаешь, что обычный отступ вложенности — один таб? Я встречал традицию, где это — два таба.
А один используется под полуотступ для некоторых особых случаев.
Так что твоё представление, что один таб это универсальный закон программного бытия, как минимум поспешно.
N>>а нажатие BS на пустом месте его съедает, и этого достаточно, чтобы поддерживать согласованный вариант. Я просто не вижу глубокого смысла в желании иметь какой-то плавный ползунок, которым регулировать эти отступы, расширяя и сжимая текст; но если кому-то это нужно — это реализуется и на пробелах. Да, пожалуй, ещё нельзя сказать "элементарно реализуется" — проблема в продолжениях операторов. ·>Не реализуется это на пробелах. Как мне такое реализовать на пробелах, если в окне редактора я хочу видеть четыре пробела, т.к. удобнее читать, а в окне мержа с тремя столбиками мне нужно 1 или два пробела, т.к. иначе в ширину экрана не помещается?
А если у тебя и с 1 пробелом на таб не поместится? У меня именно так, потому что я предпочитаю крупные шрифты, а писать вообще в 25x80.
Какой-то у тебя ну очень частный случай для оправдания.
N>>И вот тут как раз видно, что это ты "слезаеш с темы" — ты, а не я. N>>Потому что мои примеры ты поскипал и не ответил. А между тем примеры 5 и 6 ·>(5) и (6) вообще страх какой-то. Я думал ты по приколу их предложил.
Не-а, полностью серьёзно.
·>ни кстати разъедутся и при простом переименовании функции например.
Переименование обычно включает в себя и изменение роли, аргументов, etc?
·> Если тебе и правда интересно моё мнение, то я предпочту (2) или может быть (3), а (1) может сгодиться если первый параметр функции какой-то особый.
Мне оно интересно, но исключительно в контексте данного обсуждения
OK, понятно.
N>>как раз на тему того, как испортится выравнивание при табуляциях, меняющих длину. ·>Опять двадцать пять. Не надо путать выравниваение (alignment) и отступ (indent).
Так если и то, и другое делают табами в тех стандартах, где применяются табы, то зачем мне их различать?
Это если ты утверждаешь, что indentation делаешь табами, а alignment пробелами, то твой подход заметно другой, чем стандартный.
См. я приводил пример с отступами табами для полей структуры. Вот там у тебя вообще всё съедет к лешим.
N>>·>Я не утверждал, что табы решают все проблемы, рак, думаю, они не вылечат. Они решают проблему размера отступов. N>>Ещё и ёрничаешь на ровном месте. ·>Не люблю тупую софистику.
Тогда зачем сам её применяешь, причём первым?
N>>·>Так себе поддерживают, ибо задача не имеет простого алгоритмического решения. Никогда не попадались файлы с разным количеством пробелов в отступе в разных строках? N>>В смысле — часть табами, часть пробелами? Попадались. И что? ·>Нет, часть двумя пробелами, часть четырьмя, а местами случайно вставлено три.
Ну так будет точно так же неровное количество табов. Тому, кто так делает, пофиг на выравнивание при любом подходе.
(Собственно, я сам такой, когда ну очень спешно что-то делаю... хотя я такое не коммичу)
N>>Там, где отступы принципиально важны для интерпретации (как в Python или Makefile), это вызывает просто ошибку компиляции. Там, где не важны (C с компанией), там нет проблем для машины; а для человека — один лишний раз дочистить. N>>Выдержка единого средства (табы или пробелы) тут важнее, чем выбор между ними; но при выборе уже между ними я предпочту пробелы из-за заведомо меньшей конфликтности для таких ситуаций. ·>Так с пробелами возникнет конфликт с их количеством. Поэтому я выбираю табы.
И там тот же конфликт. А рекомендованное количество пробелов обычно соответствует духу языка, насколько его можно сформулировать
N>>И тут же — я участвовал в разработке софтин, в стиле которых было принято tabstop=8, но shiftwidth=4. Отступ кратный 8 делался только табами, а кратный 4, но не 8 — табы плюс 4 пробела. Между прочим, такой стиль ну очень распространён. И ты его своими "плавными" регулированиями сломаешь на корню ·>Жуть конечно. Но если ставить ширину таба больше 4, то проблем не будет.
Так это ж нетипичный вариант. Типичные — 8, 4, 3, 2 — и из них под твоё условие подходит только 8.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, ·, Вы писали: S>·>А что ты ему скажешь если ты ему посылаешь xml набранный с четырмя пробелами на 26", а на его 10" планшетике он занимает в ширину в три экрана? S>Я тем временем смеюсь с темы разговора. Вы вообще пробовали код в Скайпе отправлять? В контексте замены комментариев смайликами всерьёз рассуждать о важности табов или пробелов может только шизофреник.
Это выключается в настройках.
S>На всякий случай напомню, что в скайпе вообще нельзя сделать ширину разговора больше захардкоженной производителем. ЛЮБОЙ код превращается в скайпе в нечитаемое месиво.
Из линуксового скайпа, по крайней мере, код копируется так, что после каждой строки кода появляется дополнительная пустая строка.
Вот этот эффект более выдающийся, чем табы
Здравствуйте, Qbit86, Вы писали:
Q>·>А что ты ему скажешь если ты ему посылаешь xml набранный с четырмя пробелами на 26", а на его 10" планшетике он занимает в ширину в три экрана? Q>Это хотя бы предсказуемо и надёжно. Не то что настраивать CSS-стили в мобильном браузере на планшете, чтобы у тебя восьмизнаковый таб не превращал ширину документа в шесть экранов.
А восьмипробельный отступ не превращает?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, netch80, Вы писали:
N>>>Во-первых, не указывай другим, что делать, и они не скажут, куда тебе пойти. N>>>Я потому и не хочу зацикливаться на одном твоём вопросе N>·>Я решаю один вопрос, а ты вносишь другие. Притом они вообще никак не связаны с изначальным. Как делать _отступы_ (не выравнивание!) в многострочных выражениях от табов/пробелов никак не зависит. N>Именно что напрямую зависит, потому что эти отступы делаются по многим канонам именно табами, и твоё свободное варьирование их ширины сломает форматирование.
Ну да, отступы — табами. Почему это ломает форматирование?
N>·>Ты мне точно скажи какое количество пробелов нужное? И объясни почему все не используют именно это количество. N>Согласно канону. Который в каждом месте может быть свой.
И что приводит к полному бардаку.
N>Точно так же и с табами. Почему ты считаешь, что обычный отступ вложенности — один таб? Я встречал традицию, где это — два таба. N>А один используется под полуотступ для некоторых особых случаев.
Эээ.. "- Так не делайте так!"(с)
N>Так что твоё представление, что один таб это универсальный закон программного бытия, как минимум поспешно.
Понятно что можно извратить любую идею.
N>·>Не реализуется это на пробелах. Как мне такое реализовать на пробелах, если в окне редактора я хочу видеть четыре пробела, т.к. удобнее читать, а в окне мержа с тремя столбиками мне нужно 1 или два пробела, т.к. иначе в ширину экрана не помещается? N>А если у тебя и с 1 пробелом на таб не поместится? У меня именно так, потому что я предпочитаю крупные шрифты, а писать вообще в 25x80.
Код значит плохой. Он и с пробельными отступами плохой будет. Причём тут табы?
N>Какой-то у тебя ну очень частный случай для оправдания.
Частный?? Ты хочешь сказать, что на самом деле, в общем случае — код с отступом в один пробел и плохо помещается. Я правильно понял?!
N>·>(5) и (6) вообще страх какой-то. Я думал ты по приколу их предложил. N>Не-а, полностью серьёзно.
Ну тогда выравнивай такую каку пробелами, сделав отступ табами.
N>·>ни кстати разъедутся и при простом переименовании функции например. N>Переименование обычно включает в себя и изменение роли, аргументов, etc?
Нет. Просто переименование.
Да даже если происходит изменение аргументов, то явно не всех, а выравнивание едет у всех.
А ещё чаще встречается такая конструкция:
SomeType result = someTerribleMethod(aaa,
bbb);
Т.е. выравнивание портиться будет не только при переименовании метода, но и переменной "result" или её типа "SomeType", а если тип ещё и с параметром "SomeType<ArgType>", то такое спагетти начинается...
N>·> Если тебе и правда интересно моё мнение, то я предпочту (2) или может быть (3), а (1) может сгодиться если первый параметр функции какой-то особый. N>Мне оно интересно, но исключительно в контексте данного обсуждения N>OK, понятно.
На самом деле если пойти дальше, то выравнивание тоже надо запретить вообще везде. Ну может только в каких-то особых частях кода такое ещё имеет смысл... Но это не должно быть повседневно используемым способом форматирования.
N>>>как раз на тему того, как испортится выравнивание при табуляциях, меняющих длину. N>·>Опять двадцать пять. Не надо путать выравниваение (alignment) и отступ (indent). N>Так если и то, и другое делают табами в тех стандартах, где применяются табы, то зачем мне их различать?
Затем, что они — совершенно разные по смыслу. Отступ показывает иерархию вложенности, а выравнивание — вертикальную структуру, табличное отображение.
N>Это если ты утверждаешь, что indentation делаешь табами, а alignment пробелами, то твой подход заметно другой, чем стандартный.
alignment я вообще стараюсь не делать, ибо с ним больше мороки, чем эффекта. Но alignment если делать, то только пробелами. Ибо ты должен ввести ровно столько пробелов, чтобы подогнать под ширину столбца.
N>См. я приводил пример с отступами табами для полей структуры. Вот там у тебя вообще всё съедет к лешим.
А табами и не надо выравнивать. Да и, как мне кажется, выравнивать вообще не надо. По мне такое читается проще:
struct foo
{
/* List of active foo. */struct foo *next;
/* Comment for mumble. and you could write really big comments, not reinventing a new special formatting for them.
And even multiline.
*/struct mumble amumble;
/* Try to align the comments. */int bar;
/* Won't fit in 2 tabs. */struct verylongtypename *baz;
};
/* Head of global foo list. */struct foo *foohead;
N>>>·>Так себе поддерживают, ибо задача не имеет простого алгоритмического решения. Никогда не попадались файлы с разным количеством пробелов в отступе в разных строках? N>>>В смысле — часть табами, часть пробелами? Попадались. И что? N>·>Нет, часть двумя пробелами, часть четырьмя, а местами случайно вставлено три. N>Ну так будет точно так же неровное количество табов. Тому, кто так делает, пофиг на выравнивание при любом подходе. N>(Собственно, я сам такой, когда ну очень спешно что-то делаю... хотя я такое не коммичу)
Нет, просто файл редактируется разными людьми, у которых стоит разное количество пробелов (или даже одним человеком, который решил, что 2 пробела мало, настройки поменял, но сразу весь код менять лениво). Или куски кода кочуют из других файлов, с другими отступами.
А три пробела — часто простая опечатка. Трудно заметить через 11 или 12 пробелов ты тыкнул мышой для начала правки, а с соседними строками разница не заметна.
С табами ошибиться практически невозможно.
N>>>Выдержка единого средства (табы или пробелы) тут важнее, чем выбор между ними; но при выборе уже между ними я предпочту пробелы из-за заведомо меньшей конфликтности для таких ситуаций. N>·>Так с пробелами возникнет конфликт с их количеством. Поэтому я выбираю табы. N>И там тот же конфликт. А рекомендованное количество пробелов обычно соответствует духу языка, насколько его можно сформулировать
Не видел я таких конфликтов. Отступ — 1 таб всегда.
Кстати, даже если тот твой упомянутый стиль с двумя табами — он, конечно, очень странный, но можно поставить размер таба "2" и видеть код в привычном виде. С пробелами же — только мучиться.
N>>>И тут же — я участвовал в разработке софтин, в стиле которых было принято tabstop=8, но shiftwidth=4. Отступ кратный 8 делался только табами, а кратный 4, но не 8 — табы плюс 4 пробела. Между прочим, такой стиль ну очень распространён. И ты его своими "плавными" регулированиями сломаешь на корню N>·>Жуть конечно. Но если ставить ширину таба больше 4, то проблем не будет. N>Так это ж нетипичный вариант. Типичные — 8, 4, 3, 2 — и из них под твоё условие подходит только 8.
Так с табами типичность варианта никого не колышет. Поставю себе таб размером 5 — моё дело, никого не касается.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, mDmitriy, Вы писали:
D>>>не-а... 1-2-3 лишних пробела обычно читабельность не нарушают, в отличии от 1-3 табов по 8 D>·>Ну поставь размер таба в 4. D>и в каком волшебном месте это можно сделать один раз на все?
В том, в котором ты пользуешься. Зачем тебе все?
D>>>а если с кодом надо работать — это проблема форматтера его выровнять так, как я его настроил D>·>А ещё проблема мержа, диффа, патча, ревьювера и т.п. D>нет у меня такой проблемы... "ignore spaces" рулит
Оно не рулит. Оно делает менее информативный дифф, что может запутать ревьювера.
Т.к. когда отступы меняются не по прихоти очередного ре-формата, а реально — это должно означать, что меняется структура кода. Т.е. если у тебя было
if(a)
b;
c;
а стало
if(a)
{
b;
c;
}
строчка "c;" не появится в диффе. Скрывать из диффа изменение "незначащих" пробелов около "c;" — чревато, ревьювер может не заметить изменение логики.
Мало того, вылезает эта же проблема: "и в каком волшебном месте это можно сделать один раз на все?".
D>·>Для установки дефолтного значения: F9 -> Options -> Viewer Settings -> Tab size D>·>Для временного изменения в открытом просмотрщике: Alt+Shift+F9 -> Tab size D>раз
Т.е. ты будешь меня мучить пока на найдёшь кривые проги, которые настроить нормально нельзя?
D>даю еще минуту для Notepada
Фтопку notepad, кто им пользуется?!
D>ну и чтобы два раза не вставать — для просмотрщика строк в отладчике студии (и для текста, для и xml)
Отладчик Студии отображает не код (или ты компиляторы пишешь?).
D>·>Т.е. тебе просто тупо не нравится дефолт в 8 пробелов. Можешь себе локальный рай устроить — поменяй дефолт в 4 пробела. D>мне тупо не нравится/лень/нет времени ползать по настройкам разных программных продуктов и устанавливать у них размер таба D>был приятно удивлен, что есть любители подобного времяпровождения
Один раз настраивается и забывается.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали: D>>и в каком волшебном месте это можно сделать один раз на все? ·>В том, в котором ты пользуешься. Зачем тебе все?
потому что я пользуюсь всем, что наиболее удобно в данный момент
вот понадобился просмотрщик огромных логов — ох, пля...
какой-то сумрачный гений кододизайна решил, что оформлять лог табами — это и есть реализация вековой мечты человечества
"и места меньше занимает"(с), ага...
·>Оно не рулит. Оно делает менее информативный дифф, что может запутать ревьювера. ·>Т.к. когда отступы меняются не по прихоти очередного ре-формата, а реально — это должно означать, что меняется структура кода. Т.е. если у тебя было ·>Мало того, вылезает эта же проблема: "и в каком волшебном месте это можно сделать один раз на все?".
не вылезает... форматтер, который сам меняет логику кода, отправляется в корзину и заносится в черный список один раз и навсегда
·>Фтопку notepad, кто им пользуется?!
я пользуюсь... очень удобный для моих задач
основной недостаток — запускается только один процесс
итак, с notepad вы не справились
D>>ну и чтобы два раза не вставать — для просмотрщика строк в отладчике студии (и для текста, для и xml) ·>Отладчик Студии отображает не код (или ты компиляторы пишешь?).
если я в переменной передаю код, который должен быть динамически скомпилирован, то отладчик отобразит код, как это ни странно
итак, студию вы тоже не победили
·>Один раз настраивается и забывается.
я так и делаю — один раз настраиваю в коде запрет табуляции
Здравствуйте, mDmitriy, Вы писали:
D>·>В том, в котором ты пользуешься. Зачем тебе все? D>потому что я пользуюсь всем, что наиболее удобно в данный момент D>вот понадобился просмотрщик огромных логов — ох, пля... D>какой-то сумрачный гений кододизайна решил, что оформлять лог табами — это и есть реализация вековой мечты человечества D>"и места меньше занимает"(с), ага...
less умеет размер табов. bash тоже. В любом случае, ты не пользуешься всеми инструментами, ты повседневно пользуешься максиум десятком. А если даже и изредка приходится воспользоваться каким-то новым — 8 табов выглядят непривычно, но не смертельно. Больше проблем обычно доставляет другие отличия — размер/цвет/тип шрифтов.
D>·>Оно не рулит. Оно делает менее информативный дифф, что может запутать ревьювера. D>·>Т.к. когда отступы меняются не по прихоти очередного ре-формата, а реально — это должно означать, что меняется структура кода. Т.е. если у тебя было D>·>Мало того, вылезает эта же проблема: "и в каком волшебном месте это можно сделать один раз на все?". D>не вылезает...
Как это? Ты сходу назовёшь как в github/gerrit/gitlab/kdiff3/diff/vmdiff/tortoisemerge включить игнорирование пробелов?
А вообще, если ты постоянно переформатируешь количество пробелов, то наличие табов проблемой не будет.
D>форматтер, который сам меняет логику кода, отправляется в корзину и заносится в черный список один раз и навсегда
Ты не понял. Логику меняет программист, а ревьювер, по привычке игнорировния пробелов, т.к. код постоянно переформатируется, не замечает это изменение.
D>·>Фтопку notepad, кто им пользуется?! D>я пользуюсь... очень удобный для моих задач D>основной недостаток — запускается только один процесс
Это не единственный недостаток. В любом случае, даже в нём лучше использовать табы. Выглядят они конечно, не очень приятно, но терпимо, а вот редактировать с табами гораздо проще. Стирать/набирть/навигировать по 4 пробела сложнее, чем один таб. А auto-indent он не умеет.
D>итак, с notepad вы не справились
С notepad справляются просто — используют notepad++ или чего угодно другое более вменяемое.
D>>>ну и чтобы два раза не вставать — для просмотрщика строк в отладчике студии (и для текста, для и xml) D>·>Отладчик Студии отображает не код (или ты компиляторы пишешь?). D>если я в переменной передаю код, который должен быть динамически скомпилирован, то отладчик отобразит код, как это ни странно D>итак, студию вы тоже не победили
Я Студию последний раз больше 10 лет назад видел, понятия не имею. С современными IDE проблем нет.
D>·>Один раз настраивается и забывается. D>я так и делаю — один раз настраиваю в коде запрет табуляции
Каким образом можно настроить запрет табуляции или запрет использования неправильного количества пробелов? Притом один раз?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали: ·>less умеет размер табов. bash тоже. В любом случае, ты не пользуешься всеми инструментами, ты повседневно пользуешься максиум десятком. А если даже и изредка приходится воспользоваться каким-то новым — 8 табов выглядят непривычно, но не смертельно. Больше проблем обычно доставляет другие отличия — размер/цвет/тип шрифтов.
вы путаете теплое с мягким: шрифты и пр. — это особенности дефолтовых настроек конкретного инструмента, а табы — часть контента
·>Как это? Ты сходу назовёшь как в github/gerrit/gitlab/kdiff3/diff/vmdiff/tortoisemerge включить игнорирование пробелов?
не назову... но точно знаю, что эту галку я исправно ставлю в визарде мержинга, как и игнор регистра
запоминается она в постоянных настройки или нет — не знаю
поскольку галка доступна в процессе, меня не напрягает ее поставить
·>А вообще, если ты постоянно переформатируешь количество пробелов, то наличие табов проблемой не будет.
потому что я сохраняю код уже без них — поэтому и не будет
·>Ты не понял. Логику меняет программист, а ревьювер, по привычке игнорировния пробелов, т.к. код постоянно переформатируется, не замечает это изменение.
не встречал ревьюера, чтобы сам расставлял блоки кода по отступам
·>Это не единственный недостаток. В любом случае, даже в нём лучше использовать табы. Выглядят они конечно, не очень приятно, но терпимо, а вот редактировать с табами гораздо проще. Стирать/набирть/навигировать по 4 пробела сложнее, чем один таб. А auto-indent он не умеет.
а я в нем ничего и не набираю — только смотрю
·>С notepad справляются просто — используют notepad++ или чего угодно другое более вменяемое.
пардон, я и имел ввиду notepad++, разумеется...
·>Я Студию последний раз больше 10 лет назад видел, понятия не имею. С современными IDE проблем нет.
VS 2015 считается вроде как вполне себе современное IDE
·>Каким образом можно настроить запрет табуляции или запрет использования неправильного количества пробелов? Притом один раз?
VS, Решарпер и автоформат без фанатизма при сохранении
Здравствуйте, mDmitriy, Вы писали:
D>·>less умеет размер табов. bash тоже. В любом случае, ты не пользуешься всеми инструментами, ты повседневно пользуешься максиум десятком. А если даже и изредка приходится воспользоваться каким-то новым — 8 табов выглядят непривычно, но не смертельно. Больше проблем обычно доставляет другие отличия — размер/цвет/тип шрифтов. D>вы путаете теплое с мягким: шрифты и пр. — это особенности дефолтовых настроек конкретного инструмента, а табы — часть контента
_Ширина_ табов — это особенности дефолтовых настроек конкретного инструмента.
D>·>Как это? Ты сходу назовёшь как в github/gerrit/gitlab/kdiff3/diff/vmdiff/tortoisemerge включить игнорирование пробелов? D>не назову... но точно знаю, что эту галку я исправно ставлю в визарде мержинга, как и игнор регистра D>запоминается она в постоянных настройки или нет — не знаю D>поскольку галка доступна в процессе, меня не напрягает ее поставить
Чем галка принципиально отличается от поля с циферкой "размер таба"?
D>·>А вообще, если ты постоянно переформатируешь количество пробелов, то наличие табов проблемой не будет. D>потому что я сохраняю код уже без них — поэтому и не будет
Да и с ними не будет.
D>·>Ты не понял. Логику меняет программист, а ревьювер, по привычке игнорировния пробелов, т.к. код постоянно переформатируется, не замечает это изменение. D>не встречал ревьюера, чтобы сам расставлял блоки кода по отступам
Перечитай ещё раз на что отвечаешь. Ты в смысл фразы не вникаешь что-ли? Или я как-то непонятно пишу? Каким образом из моих слов можно вывести, что ревьювер что-то расставляет?
D>·>Это не единственный недостаток. В любом случае, даже в нём лучше использовать табы. Выглядят они конечно, не очень приятно, но терпимо, а вот редактировать с табами гораздо проще. Стирать/набирть/навигировать по 4 пробела сложнее, чем один таб. А auto-indent он не умеет. D>а я в нем ничего и не набираю — только смотрю
Хых, даже less и то лучше для просмотра файлов.
D>·>С notepad справляются просто — используют notepad++ или чего угодно другое более вменяемое. D>пардон, я и имел ввиду notepad++, разумеется...
Ээээ... Ну тогда и проблем нет: http://stackoverflow.com/questions/23181724/how-i-can-increase-tab-width-in-notepad-v6-5
D>·>Я Студию последний раз больше 10 лет назад видел, понятия не имею. С современными IDE проблем нет. D>VS 2015 считается вроде как вполне себе современное IDE
Я её не видел, последнюю я видел вроде 2003 что-ли, проблем с табами не помню. Поковыряйся в настройках, должно быть.
D>·>Каким образом можно настроить запрет табуляции или запрет использования неправильного количества пробелов? Притом один раз? D>VS, Решарпер и автоформат без фанатизма при сохранении
_запрет_? Т.е. если я файлик поредактирую в notepad какая магия заставит поставить правильное количество пробелов?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, seregaa, Вы писали:
S>Ответил в предыдущем сообщении.
Только про github.
Что делать с WinMerge и прочим зоопарком инструментов? WinMerge имеет ровно одну глобальную настройку — табы, либо пробелы. Нельзя настроить пробелы для C# и табы для JS. У нас везде кроме фронт-енда используются пробелы, а архитектор фронтенда любит табы и каждые две-три недели ругается что чей-то коммит ему опять всю разметку испортил.
Здравствуйте, ·, Вы писали:
·> пробелы запрещены для отступов законодательно, высшая мера наказания и кода с пробелами не существует.
Если клавишу пробела заблокировать или удалить, то проблем, разумеется, не будет.
В проектах, где в соглашениях по оформлению кода требуется таб, я регулярно видел попадающиеся пробелы. Но это ещё что.. слегка портит внешний вид кода, но не фатально. Из фатального я один раз видел критический баг, появившийся из-за таба. К обсуждаемой теме оно, конечно, не относится, но баг был очень интересным. Сначала один разработчик отформатировал код табами:
Таких вызовов было почти с десяток, разбросанных по коду.
Потом этот код отрефакторили, убрали большую часть аргументов и переформатировали, переписав в одну строчку
SomeClass.SomeMethod(Argument1, Argument2);
Но при этом разделителем остался таб, т.е. фактически там было:
SomeClass.SomeMethod(Argument1,\tArgument2);
А ещё через пару недель один разработчик решил поменять параметры местами и сделал это через поиск и замену. И, разумеется, он поменял строку "Argument1, Argument2" на "Argument2, Argument1", но в одном месте, где между аргументами попался таб, аргументы так и остались в том же порядке.
Здравствуйте, Artem Korneev, Вы писали:
AK>Что делать с WinMerge и прочим зоопарком инструментов? WinMerge имеет ровно одну глобальную настройку — табы, либо пробелы. Нельзя настроить пробелы для C# и табы для JS. У нас везде кроме фронт-енда используются пробелы, а архитектор фронтенда любит табы и каждые две-три недели ругается что чей-то коммит ему опять всю разметку испортил.
Но виноват, разумеется, не зоопарк у вас в проекте, а табы.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Таб тут причём? Та же грустная история произошла бы, если бы был не таб, а два пробела. Мораль одна: пишите юнит-тесты. Без них за рефакторинг лучше не браться, особенно если используется примитивная IDE.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали: ·>_Ширина_ табов — это особенности дефолтовых настроек конкретного инструмента.
что при отсутствии табов вообще не имеет значения
·>Чем галка принципиально отличается от поля с циферкой "размер таба"?
еще раз — галка попадается по ходу мержинга, ее не надо отдельно искать в настройках
·>Да и с ними не будет.
если бы их не было, не было бы всего этого треда вообще
·>Перечитай ещё раз на что отвечаешь. Ты в смысл фразы не вникаешь что-ли? Или я как-то непонятно пишу? Каким образом из моих слов можно вывести, что ревьювер что-то расставляет? ·>Т.к. когда отступы меняются не по прихоти очередного ре-формата, а реально — это должно означать, что меняется структура кода. Т.е. если у тебя было ·>if(a) ·> b; ·>c;
·>а стало ·>if(a) ·>{ ·> b; ·> c; ·>}
а это кто писал? или это не изменение структуры кода?
D>>а я в нем ничего и не набираю — только смотрю ·>Хых, даже less и то лучше для просмотра файлов.
может быть... но не попадался пока
·>Ээээ... Ну тогда и проблем нет: http://stackoverflow.com/questions/23181724/how-i-can-increase-tab-width-in-notepad-v6-5
итак, 2 программных продукта победили, ура
·>Я её не видел, последнюю я видел вроде 2003 что-ли, проблем с табами не помню. Поковыряйся в настройках, должно быть.
опять 25... зачем мне ковыряться в настройках, если у меня табов нет и не будет7
·>_запрет_? Т.е. если я файлик поредактирую в notepad какая магия заставит поставить правильное количество пробелов?
причем тут нотепад? я код пишу в студии, он меня там и волнует
в студии есть механизм автоматического избавления от табов
Здравствуйте, mDmitriy, Вы писали:
D>·>_Ширина_ табов — это особенности дефолтовых настроек конкретного инструмента. D>что при отсутствии табов вообще не имеет значения
А при отсутствии цветных мониторов не имеет значения настройки цвета. И что? К чему клонишь-то?
D>·>Чем галка принципиально отличается от поля с циферкой "размер таба"? D>еще раз — галка попадается по ходу мержинга, ее не надо отдельно искать в настройках
Т.е. аппелируешь к особенностям конкретного UI, клёво.
А если подумать, это лишь говорит о том, что бардак с пробелами случается чаще и доставляет больше проблем, чем с табами. Поэтому и вынесли этот пунктик в основной сценарий использования UI.
D>·>Да и с ними не будет. D>если бы их не было, не было бы всего этого треда вообще
Если бы никто пробелами не делал отступы — тоже бы треда не было вообще. И что?
D>а это кто писал? или это не изменение структуры кода?
Я писал, что код меняет программист. А ревьювер — ревьювит, с рекомеднованным тобой игнором пробельных символов. Мой тезис — игнорировать изменение пробельных символов — плохая практика ведущая к проблемам. И, как я вижу, вынужденная при частом использовании автоформаттеров пробелов, что неизбежно, ибо не существует единственно верного количества пробелов в отступах. Если отступы сделаны табами, то переформатировать не надо вообще, достаточно менять ширину табов в настройках конкретных инструментов.
Если всё равно непонятно, попробуй подумать с другой стороны. Зачем вообще делают отступы? Если они так не важны — не делай их вообще, тогда и игнорировать не придётся, и автоформаттеры не нужны. А если таки важны, то почему ты решил они становятся неважны в диффе, почему ты предлагаешь их игнорировать?
D>·>Ээээ... Ну тогда и проблем нет: http://stackoverflow.com/questions/23181724/how-i-can-increase-tab-width-in-notepad-v6-5 D>итак, 2 программных продукта победили, ура
Да собственно любые более менее современные профессиональные редакторы/просмотрщики/среды позволяют.
D>·>Я её не видел, последнюю я видел вроде 2003 что-ли, проблем с табами не помню. Поковыряйся в настройках, должно быть. D>опять 25... зачем мне ковыряться в настройках, если у меня табов нет и не будет7
Затем же зачем ты ковыряешься с автоформаттерами, количеством пробелов, игнором пробелов и прочей фигнёй.
D>·>_запрет_? Т.е. если я файлик поредактирую в notepad какая магия заставит поставить правильное количество пробелов? D>причем тут нотепад? я код пишу в студии, он меня там и волнует D>в студии есть механизм автоматического избавления от табов
Причём тут табы? Я спрашиваю "поставить правильное количество пробелов".
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
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" таких советов не читал.
-- ВЫРОВНЕННАЯ ВЕРСИЯ.create table DocStream
(
Id bigint not null,
Md5 char(32) null,
Sha1 char(40) null,
Status int not null
);
Здравствуйте, Don Reba, Вы писали:
DR>Табуляция только для отступов. Иначе всё поедет при изменении ширины таба.
А кто его когда меняет в здравом рассудке. "Приказои по части" АКА Coding guidelines ставится фиксированная величина, обычно 3-4 пробела и всё. Все у кого иначе ССЗБ и грызут болт.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Qbit86, Вы писали:
Q>При чтении в IDE, браузере, текстовом просмотрщике табуляция отображается разной ширины.
Это всё давно настраиваемо.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, mDmitriy, Вы писали:
D>например, просмотр в редакторе с табом по умолчанию 8 не гарантирует несъезжание за пределы экрана
Один раз исправляется размер таба по умолчанию и проблемы больше нет.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Qbit86, Вы писали:
Q>Так и ты до конца все пункты не рассмотрел. Где настраивается отображаемый размер табуляции в инспекторе Unity 3D или в текст. просмотрщике Total Commander?
Если там нет такой настройки это всего лишь означает что тул — говно!
Q>Не просто «настроить инструмент под себя», а перебрать все установленные на компе мерджилки, текстовые просмотрщики и браузеры, не говоря уже о каких-то консольных утилитах.
Не вижу проблемы. Всё одно environment под проект надо настраивать.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
DR>>Табуляция только для отступов. Иначе всё поедет при изменении ширины таба. CC>А кто его когда меняет в здравом рассудке. "Приказои по части" АКА Coding guidelines ставится фиксированная величина, обычно 3-4 пробела и всё. Все у кого иначе ССЗБ и грызут болт.
А зачем тогда вообще использовать табы в таком случае, если при изменении отображаемой ширины всё поедет? Если так важна привязка к конкретной ширине логических отступов — то и используй пробелы
(я понимаю когда табы используются для логических отступов + пробелы для фигурного форматирования со стыковкой на соседних уровнях — тогда ничего не уезжает при изменении отображаемой ширины таба)
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>А зачем тогда вообще использовать табы в таком случае, если при изменении отображаемой ширины всё поедет?
Для начала объясните зачем её менять, эту ширину?
EP>Если так важна привязка к конкретной ширине логических отступов — то и используй пробелы
Табы просто удобнее лазать курсором по коду, перескакиваешь за одно нажатие сразу на ширину отступа.
EP>я понимаю когда табы используются для логических отступов + пробелы для фигурного форматирования со стыковкой на соседних уровнях
Дык при единой на всём проекте ширине таба точно так же ничего не едет.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, AndrewVK, Вы писали:
AVK>Но виноват, разумеется, не зоопарк у вас в проекте, а табы.
Благородный дон ни разу не видел компании с "over 9000" разработчиков, где в разных проектах, разных командах, на разных языках могут быть разные стандарты кодирования?
Нет никакого зоопарка. Для написания фронт-енда нужно было взаимодействовать с другой командой, которая предоставила свою базу исходных кодов и там принято делать отступы табами. C#-программеры сильно старались, но всё равно эпизодически делали кашу из табов и пробелов — то копи/пастой, то через WinMerge, то ещё как. На код-ревью этих изменений не видно, автоматически они не выявляются, замечает их только UI-архитектор со своим мак-буком, настроенным на два пробела в табе.
Здравствуйте, Lexey, Вы писали:
L>Не стоит лепить такое форматирование, для которого критична ширина таба. Тогда и съезжать ничего не будет при изменении его размера.
Не со всеми редакторами это прокатывает. Я когда-то давно использовал visual studio, так эта сволочь заменяла пробелы на табы (у меня табы стояли в настройках) внутри строки, приходилось работать с включенным visible whitespace и заменять все взад. Еще коллеги иногда пакостили, так что привычка работать с visible whitespace осталась у меня до сих пор, даже когда я работаю на проекте, в котором принят другой стандарт кодирования. Может конечно это не студия делала а viemu, я уже не помню точно, честно говоря.
Здравствуйте, UberPsychoSvin, Вы писали:
UPS>Вторая вроде бы лучше читается, но я так на всякий случай никогда не делаю, потому что ни в каких "coding convention" таких советов не читал.
Только в сезон обострения.
Здравствуйте, CreatorCray, Вы писали:
CC>А кто его когда меняет в здравом рассудке. "Приказои по части" АКА Coding guidelines ставится фиксированная величина, обычно 3-4 пробела и всё. Все у кого иначе ССЗБ и грызут болт.
В гайдлайне могут быть прописаны отступы пробелами фиксированной ширины, либо табами произвольной. Фиксировать ширину таба было бы очень странно.
Здравствуйте, Don Reba, Вы писали:
R>либо табами произвольной.
Никогда! Смысл?!
DR>Фиксировать ширину таба было бы очень странно.
Вот как раз прописывают размер таба.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Artem Korneev, Вы писали:
AK>Благородный дон ни разу не видел компании с "over 9000" разработчиков
Я в такой работаю.
AK>где в разных проектах, разных командах, на разных языках могут быть разные стандарты кодирования?
Каждая команда пилит своё, по своим стандартам.
AK> Для написания фронт-енда нужно было взаимодействовать с другой командой, которая предоставила свою базу исходных кодов и там принято делать отступы табами.
А накой самим туда лазать? Выкатывайте им API, они его вам сделают.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
R>>либо табами произвольной. CC>Никогда! Смысл?!
Смысл табов в том, что они могут быть произвольной ширины. Когда это неприемлемо, то используют пробелы.
DR>>Фиксировать ширину таба было бы очень странно. CC>Вот как раз прописывают размер таба.
Здравствуйте, Don Reba, Вы писали:
DR>Смысл табов в том, что они могут быть произвольной ширины.
Смысл табов — один широкий пробел с автоматической переменной длиной: с выровненной по сетке шага табуляции правой границей и flexible левой. Который визуально может быть длинный а вставить/удалить/перескочить его можно одним нажатием.
Применяется для выравнивания чего либо по общей границе.
Ни один вменяемый девелопер размер таба в процессе работы не меняет. Он выставляется один раз при конфигурировании environment и больше не трогается. Все проекты точатся под единый размер tab.
DR>>>Фиксировать ширину таба было бы очень странно. CC>>Вот как раз прописывают размер таба. DR>Наверное, всякое бывает, но никогда не встречал.
Видимо просто не пересекался с теми, где табами умеют пользоваться правильно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Don Reba, Вы писали:
DR>Наверное, всякое бывает, но никогда не встречал.
Вон же, выше откопали ссылку на гайдлайн из прошлого века. Там не просто используются табы, но ещё и предписывают отображение в 8 знакомест.
Выше пробельщикам вменяли разделение на лагеря двухпробельщиков и четырёхпробельщиков; но никто не мог предположить, что начнётся *рач между гибкими табуляторщиками и жёсткими табуляторщиками :)
Здравствуйте, LuciferSaratov, Вы писали:
LS>а как оно работает? изменение количества пробелов внутри строкового литерала оно тоже проигнорирует?
--ignore-space-change
Ignore changes in amount of whitespace. This ignores whitespace at line end, and considers all other sequences of one or more whitespace characters to be equivalent.
Здравствуйте, CreatorCray, Вы писали:
DR>>Смысл табов в том, что они могут быть произвольной ширины. CC>Смысл табов — один широкий пробел с автоматической переменной длиной: с выровненной по сетке шага табуляции правой границей и flexible левой. Который визуально может быть длинный а вставить/удалить/перескочить его можно одним нажатием.
Современные редакторы перескакивают как надо, не только по пробельным символам, но и идентификаторам, скобкам и т.п.
CC>Применяется для выравнивания чего либо по общей границе.
Не надо применять табы для выравнивания (alignment). Для этого есть пробелы. Да и вообще выравнивание делать не стоит, ибо проблемы с ним одни.
Табы нужны для отступов (indent), как механизм выражения древовидной структуры (вложенность выражений) посредством линейного текста.
Произвольная ширина табов нужна для того, чтобы можно было один и тот же текст просматривать/редактировать в различных инструментах по-разному.
Ширина таба — компромисс между удобством восприятия структуры (чем шире отступ, тем лучше) и общей горизонтальной шириной текста (чем уже отступ, тем лучше).
Например, когда редакируешь код, удобнее отображать таб как 4 или 6 символов. А когда делаешь 3-way merge, когда отображается три колонки с версиями кода — удобнее смотреть код с шириной таба 1 или 2.
Ещё пример. Некоторые типы кода (конфиг какой-нибудь, например) удобно изображать с широким табом, т.к. вложенность мала и важна, можно поставить 8. А вот html может иметь очень сильную вложенность, то можно уменьшить до 2.
CC>Ни один вменяемый девелопер размер таба в процессе работы не меняет. Он выставляется один раз при конфигурировании environment и больше не трогается. Все проекты точатся под единый размер tab.
Это какой? И почему именно такой?
CC>>>Вот как раз прописывают размер таба. DR>>Наверное, всякое бывает, но никогда не встречал. CC>Видимо просто не пересекался с теми, где табами умеют пользоваться правильно.
Жуть. Из-за таких как ты — пробельщики побеждают.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, CreatorCray, Вы писали:
EP>>А зачем тогда вообще использовать табы в таком случае, если при изменении отображаемой ширины всё поедет? CC>Для начала объясните зачем её менять, эту ширину?
Кому-то/где-то удобнее 4, где-то 8 и т.п. В Vim например по-умолчанию 8.
EP>>Если так важна привязка к конкретной ширине логических отступов — то и используй пробелы CC>Табы просто удобнее лазать курсором по коду, перескакиваешь за одно нажатие сразу на ширину отступа.
В принципе аргумент, но как-то совсем малозначительно в обмен на съезжающее форматирование при неправильной настройке.
Да и редактор кода можно точно также попросить скакать по столбцам индентации через пробелы, не говоря уже о переходах по скобкам/уровням.
EP>>я понимаю когда табы используются для логических отступов + пробелы для фигурного форматирования со стыковкой на соседних уровнях CC>Дык при единой на всём проекте ширине таба точно так же ничего не едет.
Вот выше Skype обсуждали — в нём поедет в том числе.
То есть из четырёх вариантов:
1. Пробелы для индентации и форматирования
2. Табы для индентации, пробелы для форматирования
3. Табы для индентации, фигурное форматирование не используется
4. Табы для индетнации и форматирования, во всех просмотрщиках нужно использовать фиксированную ширину таба.
Ты предлагаешь единственный в котором всё может поехать при другой настройке просмоторщика
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>А зачем тогда вообще использовать табы в таком случае, если при изменении отображаемой ширины всё поедет? CC>>Для начала объясните зачем её менять, эту ширину? EP>Кому-то/где-то удобнее 4, где-то 8 и т.п. В Vim например по-умолчанию 8.
Есть проект и жёстко заданные guidelines для проекта. Вопрос "а мне так удобнее" не стоит в принципе.
EP>Вот выше Skype обсуждали — в нём поедет в том числе.
Затачиваться на смотрение кода скайпом — странный use case.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, ·, Вы писали:
·>Современные редакторы перескакивают как надо, не только по пробельным символам, но и идентификаторам, скобкам и т.п.
Это какие? Emacs?
Сколько кнопок надо для этого нажать?
CC>>Ни один вменяемый девелопер размер таба в процессе работы не меняет. Он выставляется один раз при конфигурировании environment и больше не трогается. Все проекты точатся под единый размер tab. ·>Это какой? И почему именно такой?
Какой указан в coding standard для проекта.
CC>>Видимо просто не пересекался с теми, где табами умеют пользоваться правильно. ·>Жуть. Из-за таких как ты — пробельщики побеждают.
Башню 16го века тоже я развалил?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
EP>>>>А зачем тогда вообще использовать табы в таком случае, если при изменении отображаемой ширины всё поедет? CC>>>Для начала объясните зачем её менять, эту ширину? EP>>Кому-то/где-то удобнее 4, где-то 8 и т.п. В Vim например по-умолчанию 8. CC>Есть проект и жёстко заданные guidelines для проекта. Вопрос "а мне так удобнее" не стоит в принципе.
Речь о том почему в эти жёстко заданные guidelines попала ширина отображения таба, точнее насколько это вообще оправданно, и стоит ли применять в других проектах.
EP>>Вот выше Skype обсуждали — в нём поедет в том числе. CC>Затачиваться на смотрение кода скайпом — странный use case.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Речь о том почему в эти жёстко заданные guidelines попала ширина отображения таба
Да хотя бы для устранения вот таких вот непоняток.
EP> точнее насколько это вообще оправданно, и стоит ли применять в других проектах.
По опыту — стоит. Нет никаких непоняток с табами.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>·>Современные редакторы перескакивают как надо, не только по пробельным символам, но и идентификаторам, скобкам и т.п. CC>Это какие? Emacs? CC>Сколько кнопок надо для этого нажать?
IDEA, ctrl+стрелки — ходить по идентификаторам/отступам. Клавиша Home ставит в начало строки или на первый непробельный символ в строке.
CC>>>Ни один вменяемый девелопер размер таба в процессе работы не меняет. Он выставляется один раз при конфигурировании environment и больше не трогается. Все проекты точатся под единый размер tab. CC>·>Это какой? И почему именно такой? CC>Какой указан в coding standard для проекта.
Богом данный? А рациональные доводы есть?
CC>>>Видимо просто не пересекался с теми, где табами умеют пользоваться правильно. CC>·>Жуть. Из-за таких как ты — пробельщики побеждают. CC>Башню 16го века тоже я развалил?
Башню-то ещё можно простить...
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Gattaka, Вы писали:
DR>>Я чаще работаю в Виме, чем в Студии. А Решарпер умеет делать табличное форматирование?
G>Не знаю, я бы запретил...
Здравствуйте, oziro, Вы писали:
CC>>"Больше ада! Больше угара! Внесите чучело козла!" (С) Belnetmon O>кстати, куда он пропал? Раньше читал периодически его ЖЖ, сейчас все исчезло
"Ребе Кахес" сбежал из ЖЖ в Facebook, где отгородился от анонимных троллей, которые порой набегали.
Здравствуйте, Qbit86, Вы писали:
Q>А зачем их ignore? Их не надо ignore. Кроме того, это не спасёт от конфликтов. Скажем, в такой табличке кто-то в одной строке изменил тип, увеличив его на пару символов; кто-то другой исправил имя в другой строке, уменьшив самую длинную строку. Оба переверстали.
Да ну нафиг такую работу с кодом, и такую организацию работы вообще.
Вы там одну и ту же строку не правите часом параллельно?
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Dair, Вы писали:
CC>>"Больше ада! Больше угара! Внесите чучело козла!" (С) Belnetmon D>Ба, да вы знакомы с ребе Кахесом?..
Отож!
На белнетмоновках с ним бухали, да.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>>>"Больше ада! Больше угара! Внесите чучело козла!" (С) Belnetmon D>>Ба, да вы знакомы с ребе Кахесом?.. CC>Отож! CC>На белнетмоновках с ним бухали, да.
Я с ним выпивал пиво, когда Минск посещал, пару раз, да
Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, vsb, Вы писали:
vsb>>....Больше ничего ни в каких языках так не выравниваю.
Ф>Это ты ни с чем подобным не сталкивался просто.
Ф>
Ф>#define F(x,y,z) (z ^ (x & (y ^ z)))
Ф> P( A, B, C, D, 0, 7, 0xD76AA478 );
Ф> P( D, A, B, C, 1, 12, 0xE8C7B756 );
Ф> P( C, D, A, B, 2, 17, 0x242070DB );
Ф> P( B, C, D, A, 3, 22, 0xC1BDCEEE );
Ф> P( A, B, C, D, 4, 7, 0xF57C0FAF );
Ф> P( D, A, B, C, 5, 12, 0x4787C62A );
Ф> P( C, D, A, B, 6, 17, 0xA8304613 );
Ф> P( B, C, D, A, 7, 22, 0xFD469501 );
Ф> P( A, B, C, D, 8, 7, 0x698098D8 );
Ф> P( D, A, B, C, 9, 12, 0x8B44F7AF );
Ф> P( C, D, A, B, 10, 17, 0xFFFF5BB1 );
Ф> P( B, C, D, A, 11, 22, 0x895CD7BE );
Ф> P( A, B, C, D, 12, 7, 0x6B901122 );
Ф> P( D, A, B, C, 13, 12, 0xFD987193 );
Ф> P( C, D, A, B, 14, 17, 0xA679438E );
Ф> P( B, C, D, A, 15, 22, 0x49B40821 );
Ф>#undef F
Ф>#define F(x,y,z) (y ^ (z & (x ^ y)))
Ф> P( A, B, C, D, 1, 5, 0xF61E2562 );
Ф> P( D, A, B, C, 6, 9, 0xC040B340 );
Ф> P( C, D, A, B, 11, 14, 0x265E5A51 );
Ф> P( B, C, D, A, 0, 20, 0xE9B6C7AA );
Ф> P( A, B, C, D, 5, 5, 0xD62F105D );
Ф> P( D, A, B, C, 10, 9, 0x02441453 );
Ф> P( C, D, A, B, 15, 14, 0xD8A1E681 );
Ф> P( B, C, D, A, 4, 20, 0xE7D3FBC8 );
Ф> P( A, B, C, D, 9, 5, 0x21E1CDE6 );
Ф> P( D, A, B, C, 14, 9, 0xC33707D6 );
Ф> P( C, D, A, B, 3, 14, 0xF4D50D87 );
Ф> P( B, C, D, A, 8, 20, 0x455A14ED );
Ф> P( A, B, C, D, 13, 5, 0xA9E3E905 );
Ф> P( D, A, B, C, 2, 9, 0xFCEFA3F8 );
Ф> P( C, D, A, B, 7, 14, 0x676F02D9 );
Ф> P( B, C, D, A, 12, 20, 0x8D2A4C8A );
Ф>#undef F
Ф>
Подобный код обычно выношу в CSV-файлы, БД и тд, поэтому в коде с ним работать не приходится (конкретно этот случай похож на что-то криптографическое, поэтому конкретно тут, конечно, по-другому смысла делать нет, я в общем).
Здравствуйте, CreatorCray, Вы писали:
AK>>Благородный дон ни разу не видел компании с "over 9000" разработчиков CC>Я в такой работаю.
И?.. Вы в своей компании можете повесить какую-то задачу другой команде просто потому что они сделают это лучше?
AK>> Для написания фронт-енда нужно было взаимодействовать с другой командой, которая предоставила свою базу исходных кодов и там принято делать отступы табами. CC>А накой самим туда лазать? Выкатывайте им API, они его вам сделают.
Ну на словах-то всё легко звучит. С какой радости другая команда будет тратить несколько человеко-месяцев чтоб пилить UI другого проекта? У всех своей работы хватает.
В одном из проектов нужно сделать web UI. В наличии имеются C# full-stack разработчики, т.е. подразумевается, что вёб они делать умеют, пусть и не так хорошо как специализированные UI-разработчики. Далее, UI-команда предоставляет свой фреймворк с кучей готовых модулей, команде full-stack разработчиков остаётся добавить туда свои странички и прикрутить их к имеющемуся фреймворку. Код-ревью делается UI-архитектором из UI-команды, некоторые удачные модули переходят потом в состав основного UI-фреймворка.
Здравствуйте, ·, Вы писали:
·>Таб тут причём? Та же грустная история произошла бы, если бы был не таб, а два пробела.
Два пробела визуально видны. Таб визуально не отличим от N-го количества пробелов.
·>Мораль одна: пишите юнит-тесты. Без них за рефакторинг лучше не браться, особенно если используется примитивная IDE.
Некоторые вещи практически невозможно покрыть юниттестами. Их покрывают функциональными тестами, но в этом случае трудно убедиться в хорошем покрытии кода тестами.
Здравствуйте, Artem Korneev, Вы писали:
AK>·>Таб тут причём? Та же грустная история произошла бы, если бы был не таб, а два пробела. AK>Два пробела визуально видны. Таб визуально не отличим от N-го количества пробелов.
Ээээ... И?
AK>·>Мораль одна: пишите юнит-тесты. Без них за рефакторинг лучше не браться, особенно если используется примитивная IDE. AK>Некоторые вещи практически невозможно покрыть юниттестами. Их покрывают функциональными тестами, но в этом случае трудно убедиться в хорошем покрытии кода тестами.
Тогда нефиг рефакторинг делать.
Пробелы/табы тут вообще не причем.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Qbit86, Вы писали:
Q>Google: «We use spaces for indentation. Do not use tabs in your code. You should set your editor to emit spaces when you hit the tab key.»
Иначе всё поедет при изменении ширины таба.
Если так важна привязка к конкретной ширине логических отступов — то и используй пробелы 
