Работа со стандартами кодирования на работе (я не начальник)

Я работаю в небольшой команде, около 10 разработчиков. У нас вообще нет стандартов кодирования. Есть определенные вещи, которые стали нормой, но некоторые способы ведения дел совершенно разные. Мой большой - отступ. Некоторые используют вкладки, некоторые используют пробелы, другие используют другое количество пробелов, что создает огромную проблему. Я часто сталкиваюсь с конфликтами при слиянии, потому что кто-то использует свою IDE для автоматического форматирования, и они используют другой символ для отступа, чем я. Мне все равно, какие мы используем, я просто хочу, чтобы мы все использовали один и тот же.

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

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

Кто-нибудь из вас сталкивался с подобной ситуацией на работе? Если так, как ты справился с этим? Какие были бы хорошие моменты, чтобы помочь продать моего босса по стандартам? Будет ли хорошей идеей начать массовое движение за создание стандартов кодирования среди тех, кто в этом заинтересован? Я слишком конкретен, я должен просто отпустить?

Спасибо всем за ваше время.

Примечание: Спасибо всем за отличную обратную связь! Чтобы было ясно, я не хочу диктовать один стиль, чтобы управлять ими всеми. Я готов признать свой предпочтительный способ сделать что-то в пользу того, что подходит всем лучше всего. Я хочу последовательности и хочу, чтобы это была демократия. Я хочу, чтобы это было групповое решение, с которым все согласны. Правда, не все добьются своего, но я надеюсь, что все будут достаточно зрелыми, чтобы идти на компромисс для улучшения группы.

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

У нас с коллегой была похожая проблема в нашей команде, когда мы впервые присоединились (я присоединился к команде первым, он присоединился около года спустя). Там не было никаких реальных стандартов кода. Мы магазин MS, и даже стандарты кодирования MS не использовались. Мы решили привести пример. Мы сели вместе и составили документ, в котором были все наши стандарты: стандарты IDE, стандарты именования, все, что мы могли придумать. Тогда он и я согласились следовать стандарту в явном виде. Я отправил электронное письмо команде (от нас обоих) и уведомил их, что мы нашли недостаток, и мы собирались устранить недостаток с нашим документом. Мы приглашали критику, идеи, комментарии, мнения. Мы получили очень мало обратной связи и лишь немного отодвинулись назад. Он и я сразу начали использовать стандарты, и когда мы привлекли младших разработчиков к нашим проектам, мы познакомили их со стандартом, и они начали его использовать. У нас есть несколько лидеров, которые поначалу неохотно, но постепенно начали использовать стандарт для очень многих вещей.

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

Если вы хотите стандарты, проложите путь. Придумайте список стандартов, которые, по вашему мнению, пойдут на пользу вашей команде. Отправить его коллегам и ведет для обратной связи. Я уверен, что у других людей в вашей команде есть подобные идеи, но им, вероятно, не хватает решимости что-либо с этим сделать. Как сказал Ганди: «Вы должны быть тем изменением, которое хотите увидеть в мире».

Стандарты не должны определяться и соблюдаться менеджером. Команда в целом должна согласиться со стандартами. Если они не могут договориться об общем наборе стандартов, заставить менеджера навязать им стандарты не удастся.

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

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

Можете ли вы показать доказательства того, сколько времени вы потратили из-за проблем, которые это вызывает?

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

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

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

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

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

Относительно стандартов кодирования: я почти со всеми скажу, что стандарты кодирования - это «хорошая вещь» (а не стандарты).

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

Простое решение: предоставьте разработчикам ограниченный набор вариантов фигурных скобок и отступов, но при этом диктуйте, что стиль фигурных скобок и отступы должны быть единообразными для всего модуля. (Вы хотите, чтобы foo.h и foo.cpp следовали одному и тому же стилю, не так ли?) Сопровождающие должны адаптироваться к существующему стилю; они не могут переписать модуль в соответствии со своим причудливым стилем. Несколько стилей внутри модуля просто сбивают с толку и являются признаком небрежности. Когда я вижу эту глупость, это заставляет меня задуматься, что еще не так.

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

Учитывая все вышесказанное, я думаю, что у вас может быть более глубокая проблема в вашем проекте. Вы упомянули проблемы со слиянием. Если вам нужно много слияния, это может быть признаком плохого разделения проекта. Подобно тому, как слишком много поваров портят бульон, слишком много программистов, работающих с одним файлом, портят проект. Почему каждый из Джо, Сьюзи, и вы касаетесь foo.cpp?

Это одна из областей, в которой проводятся некоторые исследования. По сути, основной вопрос заключается в том, проводите ли вы проверки кода. Обзоры кода, без сомнения, являются наиболее эффективным средством улучшения качества кода. (Источник: Институт программной инженерии, КМУ). Это, безусловно, более эффективно, чем дополнительный тестер.

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

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

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

Если после того, как у вас возникнет такой недостаток, вы почувствуете, что можете все согласиться с базовым стилем написания нового кода, это хорошее дополнение. Фокус на вещах, которые действительно влияют на ремонтопригодность; проблемы с именами были бы в моем личном списке, потому что, если у вас есть полдюжины различных стилей именования в одном продукте любой заметной сложности, это очень быстро станет головной болью, но опять же, сфокусируйтесь на том, что вы и ваша команда считаете важным , Составьте короткий документ, по которому каждый может, по крайней мере, согласиться следовать (даже если у них может быть другой стиль работы с домашними животными) и отправьте его всем членам команды. Сделайте это «живым» документом, не забудьте обновить его со временем, но не делайте его слишком жестким и конкретным.

Если ваш начальник не занимается написанием кода, он не должен слишком беспокоиться о том, какой именно стиль принят (при условии, что он сосредоточен на удобочитаемости и удобстве обслуживания), но он должен видеть преимущества для всех в команде, следуя общему стилю при написании кода.

Есть некоторые вещи, которые являются болезненными. Наиболее болезненным является IDE, который автоматически переформатирует код в сочетании с разработчиками, которые настраивают свои IDE различными способами. Каждый раз, когда вы сравниваете код, у вас есть сотни изменений после того, как кто-то с разными настройками отредактировал код. Это недопустимо. Здесь вам нужно объединить все усилия, согласовать набор настроек и отклонить любые проверки, выполненные кем-либо с использованием других настроек. Если я изменяю одну строку кода, в diff-файлах должна отображаться одна измененная строка кода, а не сотни.

Все остальное либо безвредно, либо есть лучшие способы сделать то, в чем другие могут убедиться. Здесь должно быть правило: не связывайтесь с чужим кодом, если вы действительно не улучшаете его. И сочетание стиля A и стиля B всегда хуже, чем стиль A или стиль B.

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

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

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

Где стандарты действительно очень полезны, так это с именами и уменьшением сложности. Как называть идентификаторы, классы, куда их помещать и т. Д. Поддержание согласованности имен чрезвычайно важно, особенно в большом проекте. Правила уменьшения сложности включают в себя сохранение функций под определенным количеством строк (разбить их на более мелкие функции) или сохранение списков параметров под определенным количеством аргументов (возможно, вам следует объединить их в объект и передать их вокруг).

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

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

конфликтует, когда я объединяюсь, потому что кто-то использовал свою IDE для автоматического форматирования, и они используют другой символ для отступа, чем я

Похоже, это ваша проблема, не форматирование, а переформатирование. Это огромная проблема для СКМ, и совет прост: не делайте этого. Поэтому в следующий раз, когда кто-то переформатирует все пробелы во вкладки или изменит фигурные скобки в соответствии с их предпочтительным стилем, вам нужно будет сложить их. Вместо этого заставьте их сделать слияние; стоять над ними, глядя не одобряя трату времени, вызванную их безрассудством.

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

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

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

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

Не пытайся это!

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

Если ваши коллеги не линчуют вас (!!), у вас может получиться стандарт кодирования.

Очевидно, это стратегия высокого риска ... :-)