A>>>Походил по папкам, почитал исходники. Этот код smells.
ОК>>Жестко ты. Да этот код (минус странности в виде дефайнов для логических операторов плюс еще что-то) даст фору тем "сеньйорам" с которыми мне довелось поработать.

A>Ощущение того, что код smells не зависит от того, написан он начинающим или сеньйором, а зависит исключительно от самого кода. Конкретно этот код не прошел бы code review в моей команде по куче причин, которые я не буду здесь расписывать, потому что многое уже сказали, да и не имеет смысла. Ну а то, что ваши сеньйоры пишут код еще хуже, говорит об уровне команды/проекта/руководителя, да и об общем обесценивании всякого рода титулов.

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

T>>> Забей, "идеальный код" — понятие очень субьективное.
T>>> Как бы тут его не вылизывали, интервьювер всеравно найдет кчему докапаться.
М>>давайте определим "идеальный код" как "код, который нельзя улучшить", т.е. к нему ни прибавить, ни отнять.
A>+1
A>

A>по этому если в код можно добавить фичу языка, или код содержит что-то лишнее, типа if (x != 0), этот код не идеален.

Ну так ты ты и есть упомянутый интервьюер. Смотри здесь.

Автор: Abyx
Дата: 29.04.13

Здравствуйте, Олег К., Вы писали:

IT>>Это ты не понял. Код по разному смотрится на разных мониторах. Если ты мне прижал свой код к краю МОЕГО экрана ТВОИМИ двумя пробелами индентации, то нафиг мне такой твой код.
ОК>Нет, это ты не понимаешь и забудь ты про разные размеры мониторов. Допустим у нас мониторы одного размера.

Не-не-не. Допустим у нас разные мониторы. В отличиие от твоей гипотетической ситуации ниже это реально произошедший факт. Немерлисты, особенно при поездках на дачу, очень сильно любят использовать два пробела для отступов на своих микроскопических мониторах лаптопов. Я с таким кодом на моём мониторе работать не смог.

ОК>Ты выставил табы в четыре спейса и сделал индентацию в два тэба, т.е. ты у себя видишь восемь спейсов. А мне нравятся табы в 8 спейсов. То есть получается у меня уровень индентации будет 16 спейсов и в зависимости от того сколько у тебя уровней вложенности, то у меня код начнет "уплывать" вправо в то время как у тебя он будет смотреться нормально. Я, конечно, могу уменьшить табы до четырех спейсов чтобы у меня смотрелось как у тебя, но почему я это должен делать? Так что получается палка о двух концах. А если еще представить другого программиста который выставляет табы в два спейса, то это вообще ужас начинается...

Это всё какой-то высосанный из пальца пример. Зачем мне выставлять у себя табуляцию на 4 пробела и использовать их две вместо того, чтобы сразу поставить одну табуляцию на 8 пробелов? Что за чушь?

ОК>Так что самое лучше решение это делать так, чтобы код выглядел как задумал начальный автор, т.е. иметь везде спейсы. Или иметь соглашение о том каким должен быть выставлен таб но как инфорсить его я не представляю. Все равно код перекосится вопреки всем стараниям; я это постоянно вижу.

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

ОК>Так что все зло от табов.

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

IT>>Так в том то и дело, что если отбивать код табами, то каждый сам сможет настроить свой размер табов. Даже сможет его настроить для себя на разных компьютеровх, например, на лаптопе с экраном 14" и на десктопе с экраном 30". А размер пробелов не настроишь.

ОК>Настраиваешь не размер пробелов а их количество.

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

A>Или может Вам нравятся
A> табы длиной 8 пробелов, особенно когда
A>есть ограничение в ширину?

Ну мне нравятся табы в 8 спейсов и они должны быть такой длины как минимум по исторической причине. И потом, что значит ограничение в ширину? Если в коде небольшая вложенность, то код с индентацией в восемь спейсов будет посередине экрана. Как раз нормально читать такой код потому что 1) нет нагромождения слева и 2) такая индентация контролирует уровень вложенности, т.е. заставляет думать как разбить код на функции.

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

Да, еще Линукс и FreeBSD написаны с такими табами.

Здравствуйте, Abyx, Вы писали:

IT>>А за пробелы повбывав бы.

A>Вы что,
A> никогда не видели
A> свой код в нарисованный
A> чем-то что не умеет
A>настраивать длину таба?
A>Всякие веб-интерфейсы к VCS, pastebin'ы, форумы
A>и т.п.?
A>Или может Вам нравятся
A> табы длиной 8 пробелов, особенно когда
A>есть ограничение в ширину?

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

Здравствуйте, IT, Вы писали:

IT>Я свой код вижу прежде всего по мильёну раз в день в моём повседневном иструменте.

тогда не приставай к людям которые используют другие инструменты

IT>>>Это ты не понял. Код по разному смотрится на разных мониторах. Если ты мне прижал свой код к краю МОЕГО экрана ТВОИМИ двумя пробелами индентации, то нафиг мне такой твой код.
ОК>>Нет, это ты не понимаешь и забудь ты про разные размеры мониторов. Допустим у нас мониторы одного размера.

IT>Не-не-не. Допустим у нас разные мониторы. В отличиие от твоей гипотетической ситуации ниже это реально произошедший факт. Немерлисты, особенно при поездках на дачу, очень сильно любят использовать два пробела для отступов на своих микроскопических мониторах лаптопов. Я с таким кодом на моём мониторе работать не смог.

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

Ну не смог так не смог. Это их проблемы что к их проекту не смог из-за этой причины подключиться толковый разработчик. Либо пусть делают приемлимый уровень индентации либо пусть сами делают свой проект.

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

ОК>>Ты выставил табы в четыре спейса и сделал индентацию в два тэба, т.е. ты у себя видишь восемь спейсов. А мне нравятся табы в 8 спейсов. То есть получается у меня уровень индентации будет 16 спейсов и в зависимости от того сколько у тебя уровней вложенности, то у меня код начнет "уплывать" вправо в то время как у тебя он будет смотреться нормально. Я, конечно, могу уменьшить табы до четырех спейсов чтобы у меня смотрелось как у тебя, но почему я это должен делать? Так что получается палка о двух концах. А если еще представить другого программиста который выставляет табы в два спейса, то это вообще ужас начинается...

IT>Это всё какой-то высосанный из пальца пример. Зачем мне выставлять у себя табуляцию на 4 пробела и использовать их две вместо того, чтобы сразу поставить одну табуляцию на 8 пробелов? Что за чушь?

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

ОК>>Так что самое лучше решение это делать так, чтобы код выглядел как задумал начальный автор, т.е. иметь везде спейсы. Или иметь соглашение о том каким должен быть выставлен таб но как инфорсить его я не представляю. Все равно код перекосится вопреки всем стараниям; я это постоянно вижу.

IT>Включи у себя в редакторе Visible White Spaces, покрась их в ненавязчивый цвет, заставь это сделать своих коллег и эта проблема исчезнет навсегда. Проверено.

А зачем лишний раз напрягаться по поводу табов? Сохраняй спейсы вместо табов и будет тебе счастье. Только сделай приемлимый уровень индентации чтобы было видно что чему подчиняется.

ОК>>Так что все зло от табов.

IT>Всё зло от попыток доказать, что твои предпочтения самые лучшие.

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

     DoSomething(arg1,
                 arg2,
                 arg3,
                 arg4);

Название функции индентированно тэбом а вот аргументы 2 — 4 не получается индентировать табами. Поэтому люди еще добавят спейсов и код поплывет. Только не говори что такого стиля не бывает!

IT>>>Так в том то и дело, что если отбивать код табами, то каждый сам сможет настроить свой размер табов. Даже сможет его настроить для себя на разных компьютеровх, например, на лаптопе с экраном 14" и на десктопе с экраном 30". А размер пробелов не настроишь.

ОК>>Настраиваешь не размер пробелов а их количество.

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

Другие потом мучаются из-за табов разных размеров.

Здравствуйте, Abyx, Вы писали:

IT>>Я свой код вижу прежде всего по мильёну раз в день в моём повседневном иструменте.
A>тогда не приставай к людям которые используют другие инструменты

IT>Я свой код вижу прежде всего по мильёну раз в день в моём повседневном иструменте. Это меня волнует прежде всего. Вожность остальных случаев по сравнению с этим трудно разглядеть даже в микроскоп.

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

Здравствуйте, Олег К., Вы писали:

ОК>Ты вообще призадумайся. Ты утверждаешь что табы призваны решить данную проблему на разных мониторах, но на деле табы только усиливают ее! И над разными мониторами и над одинаковыми. Подумай над этим.

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

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

Я не понимаю как на одной машине в одном проекте табы могут быть одновременно в два, четыре, пыть и восемь пробелов.

ОК>Нет, это не мои предпочтения. Это просто понимание что табы большее зло. Потом, представь такой фрагмент кода:

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

IT>>Ты их не настраиваешь, а гвоздями вбиваешь в каждую строчку своего кода. И другие потом с этим поделать ничего не смогут. В отличие от табуляций.
ОК>Другие потом мучаются из-за табов разных размеров.

Ещё раз предлагаю включить Visible White Space и больше не выключать и все муки сразу прекратятся.

Здравствуйте, Олег К., Вы писали:

IT>>Я свой код вижу прежде всего по мильёну раз в день в моём повседневном иструменте. Это меня волнует прежде всего. Вожность остальных случаев по сравнению с этим трудно разглядеть даже в микроскоп.

ОК>Какой у тебя размер табов и какой у тебя максимальный уровень вложенности от начала функции?

4 и фиг его знает.

ОК>Если пишешь на Си шарпе, то добавь сюда еще как минимум два — один уровень вложенности для класса, другой для неймспейса. Так ведь?

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

Всё зло от пробелов! Tabs rock, spaces suck!

ОК>Я никогда не поверю что вы там мыслите все одинакого и не поверю что все сразу же в команде бросаются переписывать свой код только потому что кому-то что-то не нравится. В коде тс есть странности но он не настолько плох.

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

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

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

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

Это как раз та ситуация, где табы — это решение проблемы. На самом деле все зло у вас не из-за табов или пробелов, а из-за индентации, идиотской попытки выравнивать строчки. Если отказаться от индентации, все становится легко и просто. А после некоторого привыкания, еще и красиво.

ОК>Или иметь соглашение о том каким должен быть выставлен таб но как инфорсить его я не представляю. Все равно код перекосится вопреки всем стараниям; я это постоянно вижу.

Для C# есть StyleCop, который прекрасно энфорсит это дело.

ОК>Нет, это не мои предпочтения. Это просто понимание что табы большее зло. Потом, представь такой фрагмент кода:
ОК>

ОК>     DoSomething(arg1,
ОК>                 arg2,
ОК>                 arg3,
ОК>                 arg4);
ОК>

ОК>Название функции индентированно тэбом а вот аргументы 2 — 4 не получается индентировать табами. Поэтому люди еще добавят спейсов и код поплывет. Только не говори что такого стиля не бывает!

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

ОК>

ОК>(tab)DoSomething(arg1,
ОК>(tab)(tab)arg2,
ОК>(tab)(tab)arg3,
ОК>(tab)(tab)arg4);
ОК>

Пробелы после лидирующих табов должны рассматриваться как build error.

ОК>>Ты вообще призадумайся. Ты утверждаешь что табы призваны решить данную проблему на разных мониторах, но на деле табы только усиливают ее! И над разными мониторами и над одинаковыми. Подумай над этим.

IT>Ну так и призадумайся. Пробелы — это разметка кода прибитая гвоздями к предпочтениям разработчика. И это хорошо заметно на разных мониторах. Табы эту проблему решают как два пальца. Подумай над этим.

Да я давно над этим подумал и вот что тебе скажу. Ты боишься "разметки кода прибитой гвоздями к предпочтениям разработчика" но не боишься самого кода? Что-то тут не то. Считай что эта прибитая разметка и есть часть самого кода/стиля.

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

IT>Я не понимаю как на одной машине в одном проекте табы могут быть одновременно в два, четыре, пыть и восемь пробелов.

Что тут непонятного? Писали разные люди в разное время разные файлы с разными установками, потом же правили эти файлы и о том что происходило — ну в общем имеем то что имеем. И это не впервой так!

ОК>>Нет, это не мои предпочтения. Это просто понимание что табы большее зло. Потом, представь такой фрагмент кода:

IT>Ну есть такая мелкая проблемка. Для её решения можно использовать другой стиль, только и всего.

Мелкая? Я тебе привел еще одну причину по которой стоит от табов отказаться!

IT>>>Ты их не настраиваешь, а гвоздями вбиваешь в каждую строчку своего кода. И другие потом с этим поделать ничего не смогут. В отличие от табуляций.
ОК>>Другие потом мучаются из-за табов разных размеров.

IT>Ещё раз предлагаю включить Visible White Space и больше не выключать и все муки сразу прекратятся.

Это ничего не даст существующему коду! Да и новому тоже если каждый будет ставить табы как ему нравится. Пример я уже привел.

Здравствуйте, Олег К., Вы писали:

IT>>Ну так и призадумайся. Пробелы — это разметка кода прибитая гвоздями к предпочтениям разработчика. И это хорошо заметно на разных мониторах. Табы эту проблему решают как два пальца. Подумай над этим.
ОК>Да я давно над этим подумал и вот что тебе скажу. Ты боишься "разметки кода прибитой гвоздями к предпочтениям разработчика" но не боишься самого кода? Что-то тут не то.

Не понял логики.

ОК>Считай что эта прибитая разметка и есть часть самого кода/стиля.

В случае с пробелами всё обстоит именно так. Табуляции оставляют свободу выбора разработчику.

ОК>>>Это реальный пример! Я вижу в проекте табы в два, четыре, пять и восемь спейсов. Код везде поплывший. Ты, видимо, просто не представляешь о чем тебе говорят и поэтому продолжаешь утверждать на счет табов.
IT>>Я не понимаю как на одной машине в одном проекте табы могут быть одновременно в два, четыре, пыть и восемь пробелов.
ОК>Что тут непонятного? Писали разные люди в разное время разные файлы с разными установками, потом же правили эти файлы и о том что происходило — ну в общем имеем то что имеем. И это не впервой так!

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

IT>>Ну есть такая мелкая проблемка. Для её решения можно использовать другой стиль, только и всего.
ОК>Мелкая? Я тебе привел еще одну причину по которой стоит от табов отказаться!

Да это полная фигня. К тому же показатель плохого стиля.

IT>>Ещё раз предлагаю включить Visible White Space и больше не выключать и все муки сразу прекратятся.
ОК>Это ничего не даст существующему коду! Да и новому тоже если каждый будет ставить табы как ему нравится. Пример я уже привел.

Ты привёл плохой пример.

ОК>Да я давно над этим подумал и вот что тебе скажу. Ты боишься "разметки кода прибитой гвоздями к предпочтениям разработчика" но не боишься самого кода? Что-то тут не то. Считай что эта прибитая разметка и есть часть самого кода/стиля.

Не надо смешивать код и оформление. Корявый код может быть отлично оформлен, но речь не о нем.

ОК>Что тут непонятного? Писали разные люди в разное время разные файлы с разными установками, потом же правили эти файлы и о том что происходило — ну в общем имеем то что имеем. И это не впервой так!

Если бы команда позаботилась об автоматическом энфорсменте coding style во время билда, такого не случилось бы. В противном случае я не вижу разницы между "каждый выбирает себе размер отступа в пробелах, и наплевав на остальные сабмитит такие файлы" и "каждый выбирает свой собственный стиль во всем — скобках, пробелах, именовании, комментариях и т.д."

ОК>Мелкая? Я тебе привел еще одну причину по которой стоит от табов отказаться!

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

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

A>Это как раз та ситуация, где табы — это решение проблемы. На самом деле все зло у вас не из-за табов или пробелов, а из-за индентации, идиотской попытки выравнивать строчки. Если отказаться от индентации, все становится легко и просто. А после некоторого привыкания, еще и красиво.

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

ОК>>Или иметь соглашение о том каким должен быть выставлен таб но как инфорсить его я не представляю. Все равно код перекосится вопреки всем стараниям; я это постоянно вижу.

A>Для C# есть StyleCop, который прекрасно энфорсит это дело.

И что? Кому-то нравится два спейса, кому-то четыре, кому-то восемь. Каждый будет настраивать полицая как ему угодно. Что дальше?

ОК>>Нет, это не мои предпочтения. Это просто понимание что табы большее зло. Потом, представь такой фрагмент кода:
ОК>>

ОК>>     DoSomething(arg1,
ОК>>                 arg2,
ОК>>                 arg3,
ОК>>                 arg4);
ОК>>

ОК>>Название функции индентированно тэбом а вот аргументы 2 — 4 не получается индентировать табами. Поэтому люди еще добавят спейсов и код поплывет. Только не говори что такого стиля не бывает!

A>За такой стиль нужно бить по рукам.

Кто сказал?

A>Код должен выглядеть так:

ОК>>

ОК>>(tab)DoSomething(arg1,
ОК>>(tab)(tab)arg2,
ОК>>(tab)(tab)arg3,
ОК>>(tab)(tab)arg4);
ОК>>

Кто сказал?

A>Пробелы после лидирующих табов должны рассматриваться как build error.

А еще проще делать билд эрроры по наличию тэбов.

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

IT>>>Ну так и призадумайся. Пробелы — это разметка кода прибитая гвоздями к предпочтениям разработчика. И это хорошо заметно на разных мониторах. Табы эту проблему решают как два пальца. Подумай над этим.
ОК>>Да я давно над этим подумал и вот что тебе скажу. Ты боишься "разметки кода прибитой гвоздями к предпочтениям разработчика" но не боишься самого кода? Что-то тут не то.

IT>Не понял логики.

Что тут непонятного? Я всего лишь сказал что наличие спейсов, тэбов и тэбов и спейсов это предпочтения разработчика точно также как и предпочтения разработчика называть идентификаторы, писать сложные выражения и т.д. Это все часть стиля. В случае тэбов, ты говоришь, что ты можешь что-то поделать. Во втором случае ты уже просто не сможешь поменять весь код так как тебе нравится. Так понятнее?

ОК>>Считай что эта прибитая разметка и есть часть самого кода/стиля.

IT>В случае с пробелами всё обстоит именно так. Табуляции оставляют свободу выбора разработчику.

Это современный костыль придуманный пропонентами табов.

ОК>>>>Это реальный пример! Я вижу в проекте табы в два, четыре, пять и восемь спейсов. Код везде поплывший. Ты, видимо, просто не представляешь о чем тебе говорят и поэтому продолжаешь утверждать на счет табов.
IT>>>Я не понимаю как на одной машине в одном проекте табы могут быть одновременно в два, четыре, пыть и восемь пробелов.
ОК>>Что тут непонятного? Писали разные люди в разное время разные файлы с разными установками, потом же правили эти файлы и о том что происходило — ну в общем имеем то что имеем. И это не впервой так!

IT>Подождика. В одном проекте нельзя задать разный размер табуляции в один и тот же момент. Или в твоём случае это не так

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

IT>>>Ну есть такая мелкая проблемка. Для её решения можно использовать другой стиль, только и всего.
ОК>>Мелкая? Я тебе привел еще одну причину по которой стоит от табов отказаться!

IT>Да это полная фигня. К тому же показатель плохого стиля.

Кто сказал про плохой стиль?

IT>>>Ещё раз предлагаю включить Visible White Space и больше не выключать и все муки сразу прекратятся.
ОК>>Это ничего не даст существующему коду! Да и новому тоже если каждый будет ставить табы как ему нравится. Пример я уже привел.

IT>Ты привёл плохой пример.

Кто сказал? Или тебе нужен "хороший" пример который бы был удобен тебе?

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

A>>Для C# есть StyleCop, который прекрасно энфорсит это дело.
ОК>И что? Кому-то нравится два спейса, кому-то четыре, кому-то восемь. Каждый будет настраивать полицая как ему угодно. Что дальше?

Правила StyleCop выбираются один раз, применяются для всех проектов, и изменяются только по особым поводам. Весь смысл StyleCop — это иметь единый и общий стандарт.
Если там будет сказано "все используем только табы" или "только 4 пробела", то никаких проблем не будет. Хотя табы и в этом случае предпочтительнее.

ОК>Кто сказал?
Опыт работы на проектах с большим количеством людей и исходников, а также большим количеством бранчей и параллельной разработке в них.

A>>Пробелы после лидирующих табов должны рассматриваться как build error.
ОК>А еще проще делать билд эрроры по наличию тэбов.

И то, и другое делается элементарно — включением соответствующего правила. Это не имеет отношения к предмету обсуждения.

ОК>Кстати, ты выше написал слово тэб и предлагаешь использовать инструменты чтобы их увидеть.

Если бы редактор сообщений RSDN позволял наглядно отобразить таб, я бы использовал эту фичу. В Visual Studio и других редакторах такой проблемы нет.

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

Какую путаницу? Наоборот, все становится исключительно просто, вплоть до того, что пишет автоматический реформаттер для StyleCop/Resharper, и о поддержке пробелов забывается навсегда. Где здесь добавленная путаница?

ОК>>Да я давно над этим подумал и вот что тебе скажу. Ты боишься "разметки кода прибитой гвоздями к предпочтениям разработчика" но не боишься самого кода? Что-то тут не то. Считай что эта прибитая разметка и есть часть самого кода/стиля.

A>Не надо смешивать код и оформление. Корявый код может быть отлично оформлен, но речь не о нем.

И что бы ты не говорил, это все часть кода. Ты не читаешь код в отдельности от оформления и наоборот.

ОК>>Что тут непонятного? Писали разные люди в разное время разные файлы с разными установками, потом же правили эти файлы и о том что происходило — ну в общем имеем то что имеем. И это не впервой так!

A>Если бы команда позаботилась об автоматическом энфорсменте coding style во время билда, такого не случилось бы. В противном случае я не вижу разницы между "каждый выбирает себе размер отступа в пробелах, и наплевав на остальные сабмитит такие файлы" и "каждый выбирает свой собственный стиль во всем — скобках, пробелах, именовании, комментариях и т.д."

Читай мои ответы выше.

ОК>>Мелкая? Я тебе привел еще одну причину по которой стоит от табов отказаться!

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

Ты опять приплетаешь сюда инструменты... Ну раз так, пусть инструменты умеют также и переформатировать код при автоматическом рефакторинге!