Мы рассматриваем возможность введения в нашем проекте единого стандартного формата кода (автоформат с сохранением действий в Eclipse). Причина в том, что в настоящее время существует большая разница в форматах кода, используемых несколькими (> 10) разработчиками, что затрудняет работу одного разработчика над кодом другого разработчика. Один и тот же файл Java иногда использует 3 разных формата.
Поэтому я считаю, что преимущество очевидно (удобочитаемость => производительность), но было бы неплохо навязать это? А если нет, то почему?
ОБНОВЛЕНИЕ
Мы все используем Eclipse, и все знают о плане. Уже существует формат кода, используемый большинством, но он не применяется, поскольку некоторые предпочитают придерживаться своего собственного формата кода. Из-за вышеупомянутых причин некоторые предпочли бы обеспечить его соблюдение.
источник
Ответы:
В настоящее время я работаю в месте, где применяется стандартный формат кода, и код автоматически форматируется при сохранении файла, как вы собираетесь это сделать. Как новый член компании, я обнаружил, что общие правила форматирования дали мне теплое и смутное ощущение, что «эти ребята знают, что они делают», поэтому я не мог быть счастливее. ;) В качестве примечания, касающегося общих правил форматирования, мы также применяем определенные, довольно строгие настройки предупреждений компилятора в Eclipse, для большинства из которых установлено значение «Ошибка», для многих - «Предупреждение», а для большинства - «Игнорировать».
Я бы сказал, что есть две основные причины применения единого формата кода в проекте. Во-первых, это касается управления версиями: если все форматируют код одинаково, все изменения в файлах гарантированно будут значимыми. Больше не нужно просто добавлять или удалять пробелы здесь или там, не говоря уже о переформатировании всего файла как "побочный эффект" фактического изменения только строки или двух.
Вторая причина в том, что это как бы выводит эго программистов из уравнения. Когда каждый форматирует свой код одинаково, вы уже не можете легко сказать, кто что написал. Код становится более анонимным и общим свойством, поэтому никому не нужно беспокоиться об изменении «чужого» кода.
Это основные причины, есть и другие. Мне приятно, что мне не нужно думать о форматировании кода, так как Eclipse сделает это автоматически для меня при сохранении. Он беззаботен, как и при написании документов с помощью LaTeX: он форматируется впоследствии, и вам не нужно беспокоиться об этом во время записи. Я также работал в проектах, где у каждого были свои стили. Затем вы должны подумать о глупых и бессмысленных проблемах, таких как, если все в порядке, изменять чужой код в своем собственном стиле или вместо этого вы должны попытаться подражать их стилю.
Единственный аргумент против общих настроек форматирования кода, который я могу придумать для вашего случая, заключается в том, что это, по-видимому, уже текущий проект, поэтому он вызовет множество ненужных изменений во всех файлах, что приведет к путанице в реальной истории файлов. В лучшем случае, если вы можете начать применять настройки с самого начала проекта.
источник
Каждый профессиональный разработчик программного обеспечения предпочтет принять (хороший) стандарт, а не вступать в евангельские войны за стиль, по тем причинам, которые вы изложили.
Многие разработчики программного обеспечения ведут евангельские войны ......
В зависимости от вашей позиции в команде и динамики команды вы можете решить, что выиграть войну невозможно. В этом случае лучше не начинать ...
источник
if( foo )
" или "if (foo)
". Если вам действительно нужно продать кому-то подобные изменения, вам следует обратиться к факту, что они профессионалы. Они не могут разговаривать, или они будут выглядеть анально сохраняющимися. Если кто-то все равно это сделает, я надеюсь, ради вас они скоро найдут новую работу.Да, это хорошо, если у всех разработчиков есть один стиль кода.
Разработайте форматы стилей кода и импортируйте их для всех разработчиков.
Это поможет, когда мы создадим
merging
код для системы контроля версий.источник
Что вы пытаетесь получить, насколько анальный удерживающий элемент вы будете применять при его соблюдении (и на уровне детализации будут изложены ваши «правила»), будете ли вы пытаться применять его в коде, написанном на разных языках, Собираетесь ли вы попытаться применить его задним числом в существующем коде?
Поэтому, хотя существуют веские причины для навязывания определенного стиля и стандарта, есть и веские причины не делать это (слишком) строго.
источник
Да, последовательность - хорошая идея, по причинам , упомянутым другими .
Я просто хотел добавить пару моментов, которые нигде не использовались:
источник
Я был в команде, которая использовала плагин Checkstyle . Вместо того, чтобы использовать готовые функции, мы сформировали небольшой комитет заинтересованных разработчиков. Мы обсуждали то, что казалось пропавшим, то, что казалось чрезмерным, и решали проблемы. Мы все чему-то научились в процессе и укрепили эти мускулы разработчика.
(Примеры наших решений: ширина 72 символа - это слишком мало, но 120 - лучше; лучше использовать _ALLCAPS для статических финалов; хорошая реализация принудительного выхода из функции.)
Когда у нас были обзоры кода, одним из первых вопросов было: «Вы запускали его через Checkstyle?» Соблюдение стандартов кодирования было в значительной степени автоматизировано, и это отвлекло внимание от придирчивости рецензента. Было замечательно легко, когда Checkstyle выделил сигнатуру метода, щелкнул правой кнопкой мыши и изменил переменную на final. Это также может исправить отступы и скобки, чтобы код каждого человека выглядел одинаково. Отсутствует Javadoc для публичной функции? Checkstyle помечает функцию.
(Удаление запаха кода важнее, чем согласованное форматирование. Это преимущество автоматизированных инструментов.)
Я бы поставил автоматизированные инструменты, такие как Checkstyle, как навязывание одного и того же формата, так и больше, для поощрения подобного внешнего вида. А когда вы пасете кошек, автоматизированный инструмент может помочь оттачивать навыки и уменьшать запах кода, не разрушая хрупких эго.
источник
Если вы собираетесь придерживаться той же среды IDE и использовать некоторые инструменты форматирования, это хорошая идея, потому что вам не нужно слишком много усилий. Сохраняйте правила простыми с акцентом на удобочитаемость, а не на сохранность анального . Это должна быть измерительная палочка.
Хотя постоянно формируемый шарик грязи лучше, чем просто шарик грязи, ваше время лучше потратить на его очистку, а не на то, чтобы разбираться в скобках. Не превращайтесь в менеджера с булавкой, который чувствует, что выполняет свою работу, подсчитывая отступы во время проверки кода, а также следя за тем, чтобы новые титульные листы были в отчетах TPS .
Личные предпочтения как раз и редко улучшают производство: https://stackoverflow.com/questions/249432/whats-the-reasoning-behind-the-different-brace-forms
Если это произойдет, преодолеть это и сделать что-то.
источник
Я настоятельно рекомендую, чтобы люди применяли форматирование кода, и чтобы мелкие нарушения были любезно пропущены или исправлены. Причины этого, вкратце,
Что касается «читабельности => производительности», структура кода (например, классы и функции с одной ответственностью) купит вас гораздо быстрее, чем форматирование кода. Форматирование кода может помочь, но разные умы по-разному разбирают утверждения - не все будут «более продуктивными». Я хотел бы удвоить структуру кода по сравнению с форматированием, потому что это также подтолкнет вас к анализу кода и заставит команду задуматься о том, как работает программа, а не о том, как выглядит один цикл.
Я не большой поклонник домино-ориентированного проектирования, но это одна из последних моделей, которая имеет ОЧЕНЬ четко сформулированную идею о том, как код должен быть структурирован, а соглашения о форматировании кода естественным образом вытекают из структурированной программы доменно-управляемого дизайна. Опять же ... Мне не нравится DDD, но это отличный пример, потому что он так хорошо определен.
Я полагаю, что тема этого ответа такова: делайте рецензирование кода и пусть форматирование вытекает из культуры и процесса рецензирования.
источник
Обычно, если вы нанимаете разумных разработчиков, навязывать универсальный формат кода - плохая идея. Это, однако , хорошая идея , чтобы принять код руководящих принципов .
Я никогда не видел набор правил форматирования кода, который оптимизирует читабельность во всех случаях. Аналогично, на английском языке нет 100% применимых правил грамматики: наш мозг просто не подключен таким образом. Так что используйте рекомендации, но дайте разработчикам свободу переопределять их так, как они считают нужным.
Это, как говорится, более строгое правило "следовать кодексу, который уже существует в файле / проекте".
Но имейте в виду, что форматирование вносит гораздо меньший вклад в удобочитаемость, чем просто логическая организация кода. Я видел много нечитаемого кода спагетти с идеальным форматированием!
источник
Я не думаю, что есть простой ответ на это. Это не вопрос да или нет. Хотя я считаю, что стиль и соглашения об именах важны до некоторой степени, также довольно легко тратить слишком много времени на размышления об этом. Лучше всего ответить на примере.
В одном конкретном проекте, в котором я участвовал, не было никаких соглашений. Каждый разработчик делал вещи по-своему. Из-за относительной неопытности этой команды переход от одного класса к другому был действительно неприятным. Стиль был меньшей проблемой, чем проблема соглашений об именах. Один разработчик будет ссылаться на элементы пользовательского интерфейса с ужасной венгерской нотацией (глупая практика в эпоху современных IDE), один будет называть частных членов одним способом, а другой - другими. Ты просто никогда не знал, на что ты смотришь.
С другой стороны, одна команда использовала StyleCop (это был проект .Net) как часть своего процесса сборки. Что еще хуже, они также использовали большинство правил по умолчанию. Таким образом, вы будете делать что-то совершенно нормальное с точки зрения межстрочного интервала или размещения фигурных скобок, и сборка будет рваться из-за этого. Так много времени было потрачено впустую, просто добавляя пробелы и строки к вещам, и каждый, включая парней, которые настаивали на использовании StyleCop, заканчивали тем, что делали это почти каждый коммит. Это была огромная трата времени и денег.
Поэтому я хочу подчеркнуть, что негибкость - это не ответ, но и присутствие на Диком Западе тоже не значит. Реальный ответ - найти наиболее подходящее место, которое, на мой взгляд, состоит в том, чтобы не иметь автоматических инструментов, проверяющих вещи, но и не выбрасывать соглашение на ветер.
источник
Мой главный аргумент против общего стиля кодирования заключается в том, что опытный программист читает свой собственный стиль. Вы можете научить руку писать определенный стиль, но практически невозможно приучить глаз понимать стиль, который вы ненавидите. Программист пишет один фрагмент кода один раз, а затем снова и снова читает его во время разработки и отладки. Если каждый раз, когда он читает свой собственный код, он изо всех сил пытается понять его, так как он был вынужден написать его в стиле BAD, он будет очень несчастлив и будет менее продуктивным. Это из моего опыта.
Я не слишком знаком с Eclipse, но автоматическое форматирование при сохранении звучит как ужасная идея. Разработчик должен иметь полный контроль над своим кодом независимо от того, навязан ли стиль кодирования или нет. Операция «сохранить» не должна изменять один символ без явного согласия пользователя.
Если ваша компания продает исходный код, то стиль кодирования важнее, но если вы продаете скомпилированный код, то он гораздо менее актуален.
Надежды на то, что стиль кодирования сделает исходный кодер менее различимым и предотвратит эго-войны, в лучшем случае - чушь собачья, а в худшем - просто глупость. Великие программисты всегда будут создавать элегантный код независимо от стиля.
Я также категорически против того, чтобы каждый разработчик владел определенными блоками кода и не позволял всем свободно трогать каждый фрагмент кода. Разработка целых модулей в коде и ответственность за них позволяют разработчику гордиться своей работой и мешают ему создавать дрянной код, зная, что ошибки будут возвращаться, чтобы охотиться за ним.
Наконец, любой, кто является профессиональным стилем кодирования, всегда предполагает, что будет выбран его собственный стиль кодирования, и все остальные последуют его примеру. Представьте, что стиль кодирования, который вам меньше всего нравится из всех ваших соавторов, выбирается в качестве стандартного. Вы все еще поддерживаете стиль кодирования?
источник
Один формат, чтобы управлять ими всеми ... это действительно оптимально?
Это как за рулем чужой машины ...
Конечно, вы можете садиться и водить любой автомобиль, но вам будет безопаснее, удобнее и меньше вероятность столкновения, если вы потратите время, чтобы отрегулировать сиденье, руль и зеркала в соответствии с вашими предпочтениями.
С кодом форматирование влияет на ваш комфорт при чтении и понимании кода. Если это слишком далеко от того, к чему вы привыкли, потребуется больше умственных усилий. Нужно ли это наносить разработчикам?
+1 ко всем упомянутым преимуществам, но ...
Автоматическое правоприменение сопровождается расходами, которые необходимо учитывать
-1 к тому факту, что форматировщики кода не понимают эстетику форматирования кода. Сколько раз вы форматировали код, уничтожая блок комментариев, который был хорошо выровнен в табличной форме? Сколько раз вы намеренно выравнивали сложное выражение определенным способом, чтобы повысить удобочитаемость, чтобы автоматическое форматирование превращало его в нечто, «соответствующее правилам», но гораздо менее читаемое?
Иногда есть обходные пути к этим вещам, но разработчики должны думать о более важных вещах, чем о том, как не допустить искажения кода в автоматическом форматере.
Есть правила форматирования, но дают некоторую свободу применять здравый смысл.
источник
Хорошие разработчики - творческие люди, дают им некоторую художественную лицензию. «Сохраняйте это простым» должно быть заклинанием программистов. У меня есть два правила:
Правило 1: Дайте переменные / курсоры / объекты / процедуры / любые ЧУВСТВИТЕЛЬНЫЕ ИМЕНА. Однозначные имена, которые привносят смысл и понимание в ваш код.
Правило 2: Используйте отступы, чтобы показать структуру вашего кода.
Вот и все.
источник
Для меня главным преимуществом автоматически применяемого общего формата является то, что он помогает отслеживать изменения и проверять код. git (и большинство других инструментов управления исходным кодом) может отображать различия предыдущих версий файлов. Применяя общий стиль, он минимизирует различия в предпочтениях программиста.
источник
Руководства по стилю также упрощают программный анализ кода для различных аналитических целей.
Google опубликовал статью на эту тему под названием «Поиск долгов: опыт управления техническим долгом в Google» .
источник
Это языки, а не коды. У нас, людей, более 6000 языков, поэтому мы их переводим. Поэтому, если вы хотите, чтобы ваши «коды» сообщались, вам придется внести свои коррективы. Вы видите, что мы, пользователи, должны изменить наши форматы данных, чтобы мы не потеряли наши данные.
источник
Я бы сказал, что это не так. Общая структура / формат кода в команде - определенно хорошая вещь, но автоматическое ее применение - нет. Это должно быть сделано людьми, а не компьютером.
Мои самые большие проблемы с концепцией
Теперь я, возможно, склонен сказать, что было бы неплохо запустить автоформатирование в полностью завершенном проекте. Это будет запускать каждого разработчика на одной и той же ноге для проекта, когда вы позже будете исправлять / добавлять функции. Однако во время активной разработки я считаю, что это очень плохой выбор.
В основном: возложите на сотрудника ответственность за изучение стиля компании, не заставляйте их код быть тем, чем он не является.
источник