Здравствуйте, 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>Я это отдельно оговаривал. Похоже, ты просто не читаешь собощения, лепишь минус по ключевым словам.
Я минус тебе влепил за "Даже в начале строки не стоит использовать табуляцию". Ибо именно в начале строки ее и желательно использовать. Твои дальнейшие оговорки никак не отменяют первое утверждение.
