Я уже больше 10 лет читаю....
Проекты готовят к появлению нового разработчика как раз теми методами, которые ты отрицаешь: жесткими требованиями по форматированию кода
или базовая технология как git
[guest@localhost main]$ git log1 be840
commit be84045f0780b31d4ff08042daf27c9521ccf393
Author: Guido van Rossum <guido@python.org>
Date: Thu Aug 9 14:25:15 1990 +0000
Initial revision
--HG--
branch : legacy-trunk
extra : convert_revision : svn%3A6015fed2-1504-0410-9fe1-9d1591cc4771/python/branches/leg
[guest@localhost main]$вы предлагаете мержить коммиты без просмотра кода, что ли? ;)
Хранит ли ФС информацию о размере файла или каждый раз она заново пересчитывается?
это ядро операционной системы
потому как их делаешь по 2 десятка в день. придумывать задолбаешься.
Веб-инерфейс ГитХаба никакого отношения к работе с кодом не имеет. Работают локально. В своей репе git.
Если бы он портил картину, то возмущались бы толпы. Возмущаешься ты один.
Вы не прониклись проблемой с коммитами. Разжевываю:
3 минуты - форкаешь, ищешь в исходнике табы, заменяешь пробелами, компилируешь вариант под себя.
Если этого мало, то в состав стандартных пакетов Go входит пакет для работы с AST языка Go.
Группе программистов никто не мешает договориться и вместо go fmt использовать другой форматтер. Но он должен быть единым для всех по причине описанной выше проблемы.
На деле так никто не делает. Незачем совершенно.
Ты просто хочешь сделать буферизацию. Сначала всё прочитать в буфер, а потом его обработать. Для этого тебе нужно очень сильно программу переделать. Тебе нужно сделать массив массивов (ты же указатели не знаешь и динамическую память не знаешь), потом его заполнить через getline() и в конце файла (когда getline() вернёт 0) ты должен в цикле этот массив массивов пройти и каждую строку из него проверить на совпадение через strindex().