LINUX.ORG.RU

Tabs vs. Spaces

 , ,


1

2

По мотивам этого треда

Tabs - только табуляция.
Spaces - пробелы или табуляция в виде 2 и более пробелов.

  1. Tabs 537 (42%)

    ********************************************************************************************************************************************************************************************************************************************************************************************************************************

  2. Spaces 457 (35%)

    ********************************************************************************************************************************************************************************************************************************************************************************

  3. Пофиг 297 (23%)

    ********************************************************************************************************************************************************************************

Всего голосов: 1291

Ответ на: комментарий от yoghurt

В 80 символов надо влезать не за счёт индентации. Если надо, конечно. Сейчас мониторы у всех широкие, хотя да, 120 символов на строку выглядят страшно.

Вот есть люди, пользующиеся Eclipse, ты о них подумал? Или ты думаешь только о себе? :)

Потому что пробелы они и в африке пробелы, а вот табы у всех свои.

Мы это уже проходили — это достоинство, а не недостаток.

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

Примерно в таком же стиле.

Aceler ★★★★★
()
Ответ на: комментарий от unsigned

Кстати, я на днях наткнулся на прекрасное в libstdc++: отступы пробелами, выравнивание - табами.

Накосячить можно в любом стиле :)

Aceler ★★★★★
()
Ответ на: комментарий от Aceler

Отлично. А размеры табов, при которых эти аккуратные столбики превратятся в частокол, сам подберешь? :)

yoghurt ★★★★★
()
Ответ на: комментарий от yoghurt

размеры табов, при которых эти аккуратные столбики превратятся в частокол, сам подберешь? :)

Т.е. сам ты подобрать такие размеры не можешь?

tailgunner ★★★★★
()
Ответ на: комментарий от yoghurt

В 80 символов надо влезать не за счёт индентации. Если надо, конечно. Сейчас мониторы у всех широкие

дело не в мониторе, а в мозгах. Если у тебя строка в Over9000 символов, это конечно круто, но найти начало следующей нереально. Ну и про трёхпутёвое слияние...

Я боюсь даже представить, как выглядела бы эта няшненькая функция в произвольном редакторе, будь код отформатирован табами.

if ((length = g_queue_get_length (&pick_up_fds_queue)) != 0)
{
	gpointer fdp = NULL;
	kevents_extend_sz (events, length);

	while ((fdp = g_queue_pop_head (&pick_up_fds_queue)) != NULL)
	{
		struct kevent *pevent = &events->memory[events->kq_size++];
		EV_SET (pevent,
			GPOINTER_TO_INT (fdp),
			EVFILT_VNODE,
			EV_ADD | EV_ENABLE | EV_ONESHOT,
			KQUEUE_VNODE_FLAGS,
			0,
			0);
	}
}
emulek
()
Ответ на: комментарий от mihalych

Вообще табы изначально использовались потому, что все редакторы были сказочно тупыми и никакого форматирования кроме табов не поддерживали. Все что вы перечислили относится именно к случаю тупого редактора и, кстати, вы забыли самую мякотку: если в начале строки ставится номер строки или метка, то таб все равно перемещает на фиксированную позицию на экране, а не просто вставляет N пробелов. При изменении названия метки или номера отступ кода не меняется. Для бородатых годов и древних фортранов это было супер круто, но в 21 веке совершенно не актуально.

no-such-file ★★★★★
()
Ответ на: комментарий от tailgunner

Настраиваемость актуальна всегда

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

no-such-file ★★★★★
()
Ответ на: Вы путаете, что я путаю. от yoghurt

Винегрет.

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

У каждого своё «правильно отформатировать»

Вы понимаете, что «одинаково отформатирован» и «одинаково смотрелся» разные вещи?

Camel ★★★★★
()
Ответ на: комментарий от no-such-file

Вы все еще пользуетесь тупыми редакторами, где нет ничего кроме настройки позиции табов?

Нет, но спасибо за вопрос.

tailgunner ★★★★★
()
Ответ на: комментарий от no-such-file

Как раз то, что все текстовые редакторы прекрасно справлялись с табами для отступов и 50 лет назад и будут ещё через 50 лет, делает табы актуальными/предпочтительными и для нашего века, со всеми 14-ю или более аргументами в их пользу.

Как раз проблема в заумных текстовых редакторах, которые навязывают плохие стили форматирования кода. Посмотрите на код лиспа в том же emacs. По мне так как прыгание уровней случайным образом выглядит неакуратным, неудобным и плохо читабельным. Я за один отступ одним табом даже для лиспа (хоть в лиспе с его неумоверным количеством вложений, лучше сжимать уровни, то есть один таб может выражать несколько уровней). Но попробуй о таком сказать программисту лиспа, который никаким другим редактором не пользовался и привык что строка может начинаться со случайного числа пробелов.

Или вот пример кода из того же drivers/gpu/vga/vga_switcheroo.c:

static int register_client(struct pci_dev *pdev,
			   const struct vga_switcheroo_client_ops *ops,
			   int id, bool active, bool driver_power_control);

int vga_switcheroo_register_client(struct pci_dev *pdev,
				   const struct vga_switcheroo_client_ops *ops,
				   bool driver_power_control)
{
	return register_client(pdev, ops, -1,
			       pdev == vga_default_device(), driver_power_control);
}

Уверен, что для большинства (пользующихся заумными редакторами, заставляющими так форматировать) этот скачущий стиль не кажется диким. Хотя недостатков в нём с десяток. Код быстро лезет вправо. Непредсказуемая позиция начала кода в строках. При переименовании, например «register_client» на «set_client» придётся весь сопутствующий код во всех файлах переформатировать (и неудобно и diff в пролёте). Для некоторых это даже менее читабельно, потому как текст скачет. Просто так скопировать аргументы для другой похожей функции не выйдет, потому как надо переформатировать для её имени. И так далее.

И не важно уже, выравнивать такой код табами (как в ядре) или пробелами (конечно же нужно пробелами, всё что не логический отступ). Сам-то стиль с десятком проблем. А ведь можно просто использовать беспроблемный стиль, и не знать горя.

static int register_client(
	struct pci_dev *pdev, const struct vga_switcheroo_client_ops *ops, int id,
	bool active, bool driver_power_control);

int vga_switcheroo_register_client(
	struct pci_dev *pdev, const struct vga_switcheroo_client_ops *ops,
	bool driver_power_control)
{
	return register_client(
		pdev, ops, -1,
		pdev == vga_default_device(), driver_power_control);
}
mihalych ★★★
()
Ответ на: комментарий от mihalych

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

Но попробуй о таком сказать программисту лиспа

Зачем говорить? Вы сами попробуйте писать на лиспе как вы советуете. Застрелитесь через 5 минут.

этот скачущий стиль не кажется диким

Да, не кажется.

При переименовании, например «register_client» на «set_client» придётся весь сопутствующий код во всех файлах переформатировать

Нет, не придется. IDE сама и переименует и переформатирует.

diff в пролёте

Хотите сказать, что patch на таком коде не работает?

Просто так скопировать аргументы для другой похожей функции не выйдет, потому как надо переформатировать для её имени

Выйдет, все само переформатируется.

конечно же нужно пробелами, всё что не логический отступ

А ведь можно просто использовать беспроблемный стиль

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

no-such-file ★★★★★
()
Ответ на: комментарий от mihalych

При переименовании, например «register_client» на «set_client» придётся весь сопутствующий код во всех файлах переформатировать (и неудобно и diff в пролёте).

Нормальный diff покажет, что изменения в whitespace.

Просто так скопировать аргументы для другой похожей функции не выйдет, потому как надо переформатировать для её имени.

Вообще не проблема.

А ведь можно просто использовать беспроблемный стиль, и не знать горя.

Он проблемный, ибо уродский и нелогичный.

tailgunner ★★★★★
()
Ответ на: 4.2 от Camel

Нет, это не 4.2, тут спорить не о чем. А вы пишите как угодно, меня это не касается.

A-234 ★★★★★
()
Ответ на: комментарий от no-such-file

Вы сами попробуйте писать на лиспе как вы советуете. Застрелитесь через 5 минут.

Все мои лисп программы написаны так, что строки начинаются исключительно на таб-стопах. Для меня реально красиво и удобно, потому как все преимущества отступов табами сохранены.

(setq mode-line-format '("-"
	mode-line-modified
	"{%*}"
	mode-name mode-line-process minor-mode-alist "%n"  
	(which-func-mode
		("" which-func-format "--")
	)
	(line-number-mode "L%l--") (column-number-mode "C%c--")
))

Дело вкуса и привычки. И тот, кто кричит про «уродство», пусть в зеркало и на свой скачущий код посмотрит. :)

Хотите сказать, что patch на таком коде не работает?

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

Да да, параметры функций нужно отбивать пробелами, это-же не логический отступ.

Дело определения логического отступа. Если (как и в лиспе) любое заключённое в скобки/кавычки/whatever (будь-то параметры функции или прочее, даже неявные скобки) назвать мини-блоком, то и оно заслужит отступ табом. Я уже писал, что никаких выравниваний по *имени* в предложенном стиле нет. Все строки начинаются на таб-стопах, для continuation используется N+1 таб. И, следовательно, никаких начальных пробелов (корень всех проблем и данного флейма) нет. :)

mihalych ★★★
()
Ответ на: комментарий от tailgunner

2 чая этому господину. Пробелы - лишняя сущность в данном случае. Предлагаю одинаково штрафовать и тех, кто делает отступы пробелами и тех, кто выравнивает табами.

zink ★★
()
Ответ на: комментарий от yoghurt

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

zink ★★
()
Ответ на: комментарий от zink

Действительно, не нужна. Двери обычно закрывают одной рукой.

fmap
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.