Indent with tabs, align with spaces

Наверное стоит так писать, чтобы не требовалось часто прибегать к такому разбиению? Макросы иногда для этого применяют. Чужой код можно прогнать через «ident». А редкие случаи и руками можно красиво разбить без всякого раздражения.

Посмотри в сторону clang-format.

пробелы и табы смешивают только мудаки.

Кажется, нашёл то, что искал:

:set noet sts=0 sw=4 ts=4
:set cindent
:set cinoptions=(0,u0,U0

Только мудаки делают отступы пробелами, а выравнивание табами. Соответственно чтобы не быть мудаком, только смешивать и остаётся.

Я предпочитаю так писать:

   ->   for ( uint64_t counter = some_struct_var->some_field<cr>
   ->   ....; counter < some_struct_var && some_other_condition<cr>
   ->   ....; ++counter) {

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

Делай автозамену табов на пробелы и все фигач пробелами

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

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

Это мудачество, потому что при изменении ширины таба выравнивание поедет.

Я аргументы привёл. Какие аргументы у тебя? Нельзя смешивать потому что нельзя смешивать?

Потому что открывает твой код человек, у которого ширина табов в редакторе отличается от твоей и все уехало. Я уж молчу про языки вроде haskell и python которые по отступам считают блоки кода. Единственный вариант при котором ничего никуда никогда не уезжает это пробелы.

Потому что открывает твой код человек, у которого ширина табов в редакторе отличается от твоей и все уехало.

Ты вообще читать умеешь? Весь тред про то, как использовать табы так, чтобы выравнивание не уезжало.

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

Ложь. Второй такой вариант — это indent with tabs, align with spaces.

Вы в команде с более чем 0 человек работали?

Вот если бы работали, то знали бы что в цивилизованном обществе за табы п-дят палками по е-лу с вертушки.

Нет ничего хуже такого «цивилизованного общества» из некомпетентных бездарей. Кушайте сами.

С ident with tabs, align with spaces ничего никуда не уезжает.

Это мудачество, потому что при изменении ширины таба выравнивание поедет.

Что за наркомания? Куда оно «поедет», если сделано одними и теми же табами?

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

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

https://opensourcehacker.com/2012/05/13/never-use-hard-tabs/

Никогда. Не. Используй. Табы. В. Коде.

Включи мозг, пожалуйста.

for (my_very_long_initialization;
.....my_very_long_condition;
.....my_very_long_increment)

Куда ты тут впихнёшь табы?

for (my_very_long_initialization;
--->my_very_long_condition;
--->my_very_long_increment)

for (my_very_long_initialization;
------->my_very_long_condition;
------->my_very_long_increment)

Поэтому align только with spaces.

Куда ты тут впихнёшь табы?

Во все отступы.

Включи мозг, пожалуйста.

Кончай тупить:

/*
'===>' - Tab character
*/

for (very_long_blah-blah-blah;
===>very_long_foo > very_very_long_bar;
===>somehow_shorter_just_a_bit_bar++)
{
===>for_cycle_body_starts...
...
===>for_cycle_body_ends...
}

align только with spaces.

Какой ещё, нахер, «align»? Отступ = «таб», и никаких «align"ов и мешанины из табов и пробелов.

И без разницы, чему равен таб - 4, 8 или трём с половиной пробелам.

То есть, вы считаете, что выравнивание не нужно? Даже если улучшается читаемость?

Кончай тупить:

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

struct mystruct {
--->int........................foo;
--->std::string................bar;
--->std::vector<std::string>...baz;
};

одно переименование типа и ваше выравнивание превращается в тыкву

Что значит «переименование типа»? При изменении структуры обновляется выравнивание, по-другому никак.

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

Проблемы «жмякальщиков в IDE» меня мало не волнуют.

Ложь. Второй такой вариант — это indent with tabs, align with spaces.

А можно для танкистов, чем отличается indent от align?

Бгг, продолжай закатывать солнце вручную, «нежмякальщик»

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

Форматирование с выравниванием или без делается тулзами с прицепленным корпоративным стилевиком (е.g. clang-format) и времени отнимает совершенно одинаково (то есть 0). А что в 2017 ещё остались чудаки, форматирующие код вручную?

А можно для танкистов, чем отличается indent от align?

indent это кратные отступы для областей видимости. align это некратные отступы для продолжений длинных сигнатур, которые не вмещаются на строку.

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

void long_function_name(long_argument_name,
.......alignment........another_argument_name)
{
<-indent->statement;
<-indent->another_statement;
}

табы устарели вместе с дискетами и матричными принтерами

А она не улучшается. Хохлома из аскиарта никогда не улучшает читаемость. Легко читается код, формально отформатированный по строгим правилам самого синтаксиса языка.

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

Вот другой пример

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

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

Как хорошо, что мы живём не в твоей деревне.

Пробелами верстают только секретутки и одноклеточные.

void long_function_name(long_argument_name,

Кстати, это тоже не очень правильно, особенно для длинных имён. Лучше:

void 
long_function_name(long_argument_name,

Это уже не имеет отношения к вопросу о выравнивании.

Это уже не имеет отношения к вопросу о выравнивании.

Потому это было отвечено вам, на ваш комментарий, и начинался он со слова «Кстати», что в русском языке и означает — дополнительное замечание, возможно не по теме.

Прочитал. Из аргументов против табов серьёзным показался разве что аргумент про питон. Но я не пишу на питоне. Специально добавил тег си и пример в си стиле.

Аргументы? Ну кроме питона.

Какие аргументы у тебя? Нельзя смешивать потому что нельзя смешивать?

открывает твой код человек, у которого ширина табов в редакторе отличается от твоей и все уехало.

Если грамотно смешивать - уехало отнюдь не всё. Собственно, только '\' в макросах могут поехать.

Поэтому вы из своей деревни с пидерастами и не вылезли.

Нет, поэтому у нас на деревне не осталось пидарасов.

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

Предложите, пожалуйста, ваш вариант.

Ты уже его читал, и даже ответил на него.

как я вижу улучшение читаемости за счёт выравнивания.

Еще раз - тут нет улучшения читаемости.

Ты вместо привычного и всем понятного отступа (хоть табом, хоть восьмью, хоть четырьмя пробелами - это без разницы) используешь какой-то свой, особый непонятно чем вызванный отступ в пять пробелов.

Фигурная резьба пробелами по коду - это практически 100% признак либо школьника / начинающего программиста, либо неадеквата. Первые просто не привыкли оперировать большими объёмами кода, для них файл в полторы тыщи строк - это «много» и «его надо делить на части». Они могут тупить смотреть на цикл «сам по себе» в отрыве от остального кода несколько минут.

При обычной разработке, когда у тебя в небольшом в общем-то проекте от нескольких десятков до сотни файлов, в среднем под 1K SLOC, никто не читает код по строчке. Проматывают сразу экранами. Пробельная бахрома при такой работе мало того, что выглядит неряшливо, так еще и несколько сбивает с толку, так как несчастные отступы - это по сути визуализация AST-дерева «для бедных».

Мне понятна ваша мысль, однако аргумент я считаю неубедительным. Если взять пример из первого поста и применить ваш подход без выравнивания, вторая строчка условия цикла будет смещена на один уровень относительно первой и будет сливаться с телом цикла, что, как мне кажется, будет гораздо сильнее сбивать с толку читателя при беглом прочтении. Так что для AST-дерева «для бедных» как раз лучше использовать выравнивание, там где это осмысленно, конечно.

https://opensourcehacker.com/2012/05/13/never-use-hard-tabs/

Windows text editors <…> prefer that a hard tab is 4 spaces.

В первом же пункте брехня. Дальше не читал.

Не надо быть мудаком, не смешивай табы с пробелами. YOUR ARGUMET IS WRONG.

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