Является ли навязывание одинакового формата кода всем разработчикам хорошей идеей?

88

Мы рассматриваем возможность введения в нашем проекте единого стандартного формата кода (автоформат с сохранением действий в Eclipse). Причина в том, что в настоящее время существует большая разница в форматах кода, используемых несколькими (> 10) разработчиками, что затрудняет работу одного разработчика над кодом другого разработчика. Один и тот же файл Java иногда использует 3 разных формата.

Поэтому я считаю, что преимущество очевидно (удобочитаемость => производительность), но было бы неплохо навязать это? А если нет, то почему?

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

Stijn Geukens
источник
2
все ваши разработчики используют Eclipse? ты говорил с ними об этом плане? Не зная этого, на ваш вопрос сложно ответить, нужно было бы слишком много угадать
комнат
9
Есть ли на самом деле сделать это тяжелее для одного разработчика для работы над кодом другого, или разработчики просто быть аллергия на чтение немного другой код?
Йорис Тиммерманс
27
Когда вы используете систему управления исходным кодом (например, svn), убедитесь , что изменения в форматировании кода обрабатываются отдельно от семантических изменений - в противном случае будет трудно найти эти семантические изменения.
Восстановите Монику - М. Шредер
4
Я не согласен с Мартином здесь, ну вроде. Мое эмпирическое правило: если вы делаете логическое / семантическое изменение, тогда вам разрешается изменять формат линий, которые вы изменили, в противном случае вам не разрешено изменять формат строк только потому, что вам это нравится. Не забивайте свой журнал контроля версий мелкими переформатированными изменениями.
Бенедикт
3
С другой стороны: если все используют один и тот же формат, им будет засорен только первый коммит для переформатирования всего. Все остальное будет касаться только локальных изменений, что, на мой взгляд, приемлемо.
Йерун Ванневел

Ответы:

107

В настоящее время я работаю в месте, где применяется стандартный формат кода, и код автоматически форматируется при сохранении файла, как вы собираетесь это сделать. Как новый член компании, я обнаружил, что общие правила форматирования дали мне теплое и смутное ощущение, что «эти ребята знают, что они делают», поэтому я не мог быть счастливее. ;) В качестве примечания, касающегося общих правил форматирования, мы также применяем определенные, довольно строгие настройки предупреждений компилятора в Eclipse, для большинства из которых установлено значение «Ошибка», для многих - «Предупреждение», а для большинства - «Игнорировать».

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

Вторая причина в том, что это как бы выводит эго программистов из уравнения. Когда каждый форматирует свой код одинаково, вы уже не можете легко сказать, кто что написал. Код становится более анонимным и общим свойством, поэтому никому не нужно беспокоиться об изменении «чужого» кода.

Это основные причины, есть и другие. Мне приятно, что мне не нужно думать о форматировании кода, так как Eclipse сделает это автоматически для меня при сохранении. Он беззаботен, как и при написании документов с помощью LaTeX: он форматируется впоследствии, и вам не нужно беспокоиться об этом во время записи. Я также работал в проектах, где у каждого были свои стили. Затем вы должны подумать о глупых и бессмысленных проблемах, таких как, если все в порядке, изменять чужой код в своем собственном стиле или вместо этого вы должны попытаться подражать их стилю.

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

ZeroOne
источник
20
+100 к выводу эго программистов и их собственности из уравнения. Заявление программистов о «претензиях» к частям кода не способствует повышению производительности, поскольку препятствует обмену знаниями и означает, что есть сигнал, что не все программисты могут работать над одним и тем же фрагментом кода.
Марко
Трудно было решить, какой ответ принять, но я нашел, что этот ответ лучше аргументирован, а также лучше всего отвечает на реальный вопрос.
Stijn Geukens
«означает, что есть сигнал, что не все программисты могут работать с одним и тем же фрагментом кода»: ну, но на самом деле это то, что вам может понадобиться: если вы недостаточно знакомы с фрагментом кода, вам следует не работать над этим / изменить его. Чрезмерное владение общим кодом может привести к тому, что каждый будет работать над всей базой кода, и никто не сможет освоить какую-либо его часть.
Джорджио
У меня было бы намного больше времени для такого рода вещей, если бы код автоматически форматировался в моем стиле при загрузке. Когда Roslyn перейдет на C #, я надеюсь увидеть всю загрузку, сохранение, управление версиями и т. Д. Вместо текста.
Марк Рендл
Более строгие предупреждения и ошибки - это хорошо.
Кристоф Русси
37

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

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

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

mattnz
источник
Tx, я точно знаю, что вы имеете в виду
Stijn Geukens
15
Непрофессионально вести войны за форматирование кода. Профессиональный разработчик программного обеспечения будет делать то же самое, независимо от того, читается ли его код " if( foo )" или " if (foo)". Если вам действительно нужно продать кому-то подобные изменения, вам следует обратиться к факту, что они профессионалы. Они не могут разговаривать, или они будут выглядеть анально сохраняющимися. Если кто-то все равно это сделает, я надеюсь, ради вас они скоро найдут новую работу.
ZeroOne
7
Профессиональный разработчик также будет писать читаемый код и сможет легко читать код других профессиональных разработчиков, в первую очередь устраняя необходимость в обширном стандарте. Я бы беспокоился, что здесь «стандарт» - плохое решение для неправильной проблемы (вы не исправляете неаккуратных разработчиков со стандартом кодирования).
Йорис Тиммерманс
2
Лучший способ обойти большинство этих священных войн - это принимать языковые настройки по умолчанию, когда это возможно. Да, это означает, что ваш стиль кодирования будет варьироваться в зависимости от языка (например, код C # будет иметь {в отдельных строках, java будет иметь их в предыдущей строке, а то, что PascalCased или camelCased будет отличаться); но каждый отдельный источник языков будет выглядеть «нормально», когда вы будете привлекать новых разработчиков в проект.
Дан Нили
1
@ruakh Посмотрите на примеры кода MSDN C #, посмотрите, как Visual Studio переформатирует C # по умолчанию: {находится в отдельной строке. Повторите упражнение для Java в документации Oracle и настройках Eclipse по умолчанию при переформатировании кода: {находится на строке выше.
Дэн Нили
30

Да, это хорошо, если у всех разработчиков есть один стиль кода.

Разработайте форматы стилей кода и импортируйте их для всех разработчиков.

Это поможет, когда мы создадим mergingкод для системы контроля версий.

NPKR
источник
5
+1 за упоминание инструментов слияния и сравнения. Это настоящая боль - пытаться определить различия между двумя версиями кода, когда форматирование не согласовано между разработчиками.
pgras
1
+1, я высоко второй аргумент системы контроля версий. (но это в основном из-за правил отступа. Такие вещи, как соглашения об именах, не оказывают такого большого влияния)
BiAiB
Соглашения об именах помогают, когда вам нужно выяснить, какой метод, который, как вы знаете, существует в классе, вызывается.
Дэн Нили,
1
@ Джорджио Есть действительно разработчики, которые делают это. При смешивании с другими изменениями (например, исправления критических ошибок). Некоторые вещи отправлены, чтобы испытать нас…
Донал Феллоуз
1
@Donal Fellows: Вы правы. Я следую принципу, согласно которому каждый символ, который вы вводите в исходном файле, (1) является потенциальной ошибкой (2), вносит изменения, которые впоследствии затрудняют распознавание кода. Поэтому, на мой взгляд, каждое изменение должно быть как можно меньше. Но, да, есть разработчики, которые меняют код, не слишком задумываясь. Интересно, может ли автоматическое переформатирование кода решить проблему? Я предпочел бы в пользу владения кодом (см., Например, пункт 7 на paulgraham.com/head.html ).
Джорджио
16

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

  1. общий взгляд на код действительно может помочь сделать код более читабельным, но также может ухудшить ситуацию, если он выглядит неправильно. _hUngarian_lpfstr нотация является ярким примером :)
  2. Я видел «стандарты кода», обеспечивающие количество пробелов между блоками комментариев, алфавитный порядок имен методов и прочую чепуху. Не делай этого.
  3. У разных языков разные стандарты, к которым привыкли люди, имеющие опыт их использования. Некоторые даже предписывают эти стандарты (например, Python, Cobol, Visual Studio автоматически устанавливают соглашения о стиле C ++, в то время как Java использует стиль C по соглашению и т. Д. И т. Д.).
  4. Никогда не меняйте существующий код ради его изменения, вы только таким образом вводите новые проблемы. А это означает, что разделы кода, а также целые исходные файлы. Поэтому не нужно переформатировать существующий код, когда кто-то изменяет одну строку в файле из 1000 строк.
  5. Опытные программисты могут быть намного более продуктивными, если им не придется вдумчиво думать, будет ли то, что они пишут, «правильным» для системы автоматического утверждения или для рецензента. У них также будет привычка писать чистый код просто потому, что это работает, даже если между их естественными стилями есть небольшие различия.



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

jwenting
источник
1
1-2-3: это Java и формат кода от Sun; это просто форматирование, а не упорядочивание методов или имен переменных; 4-5: ну, идея заключается в том, чтобы автоматически форматировать при сохранении (действия по сохранению в Eclipse), чтобы не было лишней работы (вам даже не нужно думать о формате во время кодирования), но, конечно, также существующие файлы будут переформатированы ( первый раз).
Stijn Geukens
1
+1 за поцелуй. @Stijn Зачем переформатировать старый код? Просто нажмите его, когда вам нужно изменить его.
Эрик Реппен
3
На самом деле, мы планируем некоторые основные рефакторинги и переформатируем весь код в это время, так как слияние будет практически невозможно из-за рефакторинга. Если мы переформатируем только изменения, мы все равно столкнемся с проблемами слияния из-за изменения формата через год.
Stijn Geukens
4
Я в целом согласен с @StijnGeukens; не только по причинам слияния, но и потому, что любая крупномасштабная очистка форматирования затруднит отслеживание истории изменений в инструменте обвинения. Если все ваши шумовые изменения находятся в одном месте, вы всегда можете просто обвинить в том, что он начался до этой точки, а затем сделать второй раунд перед ним, если вам нужно взглянуть на более старую историю.
Дан Нили
2
Вы забыли другую причину, Дэн: крупномасштабные изменения форматирования могут легко привести к появлению новых ошибок в неожиданных местах.
jwenting
11

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

Я просто хотел добавить пару моментов, которые нигде не использовались:

  • Oracle опубликовала ряд соглашений для Java, которые являются стандартом де-факто.
    • Их использование должно помочь вам избежать споров о том, какому стилю следовать.
    • Многие публичные библиотеки и проекты с открытым исходным кодом, как правило, используют эти соглашения, поэтому, когда вам нужно взглянуть на них, форматирование должно быть знакомым.
    • Форматировщик Eclipse имеет встроенные правила, соответствующие этим соглашениям, что также должно помочь.
  • Возможно, вы захотите встроить хук в настройку управления исходным кодом, чтобы код автоматически форматировался до того, как он попадет в основную ветку.
    • Вы можете избежать сражений с особенно упрямыми программистами, которые отказываются следовать стандарту. Они могут даже использовать свое собственное форматирование во время работы, которое будет стандартизировано позже!
    • Если вы в конечном итоге используете пользовательские настройки форматирования (например, многие люди игнорируют соглашение «максимум 80 символов на строку»), вам придется вносить изменения только в одном месте.
vaughandroid
источник
9

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

(Примеры наших решений: ширина 72 символа - это слишком мало, но 120 - лучше; лучше использовать _ALLCAPS для статических финалов; хорошая реализация принудительного выхода из функции.)

Когда у нас были обзоры кода, одним из первых вопросов было: «Вы запускали его через Checkstyle?» Соблюдение стандартов кодирования было в значительной степени автоматизировано, и это отвлекло внимание от придирчивости рецензента. Было замечательно легко, когда Checkstyle выделил сигнатуру метода, щелкнул правой кнопкой мыши и изменил переменную на final. Это также может исправить отступы и скобки, чтобы код каждого человека выглядел одинаково. Отсутствует Javadoc для публичной функции? Checkstyle помечает функцию.

(Удаление запаха кода важнее, чем согласованное форматирование. Это преимущество автоматизированных инструментов.)

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

rajah9
источник
5
Единственная точка выхода? Есть определенные принципы стиля, с которыми я действительно не согласен. (Если множественные выходы являются проблемой, функция / метод, во-первых, слишком длинные…)
Donal Fellows
@DonalFellows, Checkstyle дал нам ориентир, из которого мы могли бы перейти к предпочтениям комитета. Было много восклицаний о природе: «Я не понимаю, почему они внедрили этот стандарт!» В то время как ОП спрашивал о последовательном форматировании, я думаю, что автоматизированный инструмент дает гораздо больше без дополнительной боли.
rajah9
6

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

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

Личные предпочтения как раз и редко улучшают производство: https://stackoverflow.com/questions/249432/whats-the-reasoning-behind-the-different-brace-forms

Если это произойдет, преодолеть это и сделать что-то.

оборота Джеффо
источник
6

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

  1. Машина ошибается в самое неподходящее время, и обычно, когда вы используете новую языковую функцию. Как он будет обрабатывать замыкания в Java и т. Д.? У Jalopy есть проблемы с перечислениями с функциями-членами.
  2. Я думаю, что это очень разумное бремя для программиста - создавать код для компании, который выглядит как код компании. Я считаю полезным упомянуть, что именно так код отформатирован «здесь», а не как весь код должен быть отформатирован везде. Их предыдущая компания, возможно, выбрала другой путь, и это нормально. В отличие от местного языка, есть идиомы, специфичные для вашей культуры кода, которые вы хотите вывести.
  3. Внедрение синтаксиса кода лучше всего делать с обзорами кода:
    1. Если форматирование важно, то это привлекает вашу организацию к проверке кода. Это огромная выгода.
    2. Если правило форматирования нарушено, человек может смотреть на него и судить лучше, чем машина, если намерение передается более четко. Это очень редко, но иногда случается.

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

Я не большой поклонник домино-ориентированного проектирования, но это одна из последних моделей, которая имеет ОЧЕНЬ четко сформулированную идею о том, как код должен быть структурирован, а соглашения о форматировании кода естественным образом вытекают из структурированной программы доменно-управляемого дизайна. Опять же ... Мне не нравится DDD, но это отличный пример, потому что он так хорошо определен.

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

Сэм
источник
Тх, не плохая точка зрения такая. Но опять же, это дополнительная работа, если во время каждой рецензии рецензент должен также проверять формат.
Stijn Geukens
3
Это дополнительный щелчок, чтобы вызвать строку в чем-то вроде Fisheye as, «несовместимый отступ» или «открытая скобка на линии», так что да, это больше, чем ноль усилий. Однако, если это увеличивает количество проверок кода более чем на 1 минуту, возникает серьезная проблема. После недели, когда команда пересматривает свой собственный код, все они должны очень быстро заметить «неправильный» код и исправить его.
Сам
4

Обычно, если вы нанимаете разумных разработчиков, навязывать универсальный формат кода - плохая идея. Это, однако , хорошая идея , чтобы принять код руководящих принципов .

Я никогда не видел набор правил форматирования кода, который оптимизирует читабельность во всех случаях. Аналогично, на английском языке нет 100% применимых правил грамматики: наш мозг просто не подключен таким образом. Так что используйте рекомендации, но дайте разработчикам свободу переопределять их так, как они считают нужным.

Это, как говорится, более строгое правило "следовать кодексу, который уже существует в файле / проекте".

Но имейте в виду, что форматирование вносит гораздо меньший вклад в удобочитаемость, чем просто логическая организация кода. Я видел много нечитаемого кода спагетти с идеальным форматированием!

keredson
источник
2

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

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

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

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

Джефф Путц
источник
2

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

Я не слишком знаком с Eclipse, но автоматическое форматирование при сохранении звучит как ужасная идея. Разработчик должен иметь полный контроль над своим кодом независимо от того, навязан ли стиль кодирования или нет. Операция «сохранить» не должна изменять один символ без явного согласия пользователя.

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

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

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

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

Гур
источник
2

Один формат, чтобы управлять ими всеми ... это действительно оптимально?

Это как за рулем чужой машины ...

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

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

+1 ко всем упомянутым преимуществам, но ...

Автоматическое правоприменение сопровождается расходами, которые необходимо учитывать

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

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

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

swpalmer
источник
2
Я абсолютно согласен! Автоформаторы тупые.
Лукаш Виктор
1

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

Правило 1: Дайте переменные / курсоры / объекты / процедуры / любые ЧУВСТВИТЕЛЬНЫЕ ИМЕНА. Однозначные имена, которые привносят смысл и понимание в ваш код.

Правило 2: Используйте отступы, чтобы показать структуру вашего кода.

Вот и все.

Jonesi
источник
1
Не могли бы вы объяснить, почему это так? Как позволить каждому разработчику иметь некоторую художественную лицензию (различающуюся у разных разработчиков одного проекта) для лучшей идеи, чем если бы все они имели одинаковый формат? Есть ли какие-то проблемы, которые вы решаете, а альтернатива - нет? И наоборот?
Я предполагаю, что смысл, который я пытаюсь (и не могу) сделать, состоит в том, что использование разумных имен и правильное выделение кода значительно важнее с точки зрения читаемости / удобства сопровождения, чем другие правила, которые вы можете придумать. Я не говорю, что у всех в команде должен быть свой собственный стиль, просто если они это сделают, то и что.
Джонси
Подумайте, есть ли у меня форматировщик кода в eclipse, настроенный одним способом, и я всегда переформатирую свой код ... а у вас его настроили немного по-другому ... и мы продолжаем модифицировать один и тот же код. Вызывает ли эта «художественная лицензия» какие-либо проблемы в разнице?
Хотя я понимаю, что вы делаете, я думаю, что проблема с вашей точкой зрения заключается в том, что у вас очень разные стили (заметьте, не неправильно, просто разные). Это может вызвать реальные проблемы и задержки при объединении этих разных стилей.
Даниэль Холлинрейк
1
Да, я понял вашу точку зрения, Даниэль. Я должен добавить третье правило: изменяя существующий код, адаптируйтесь к стилю кода, который вы редактируете. Это то, что я, естественно, сделал бы, если бы исправлял старую программу.
Джонси
0

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

Кристиан Х
источник
-1

Это языки, а не коды. У нас, людей, более 6000 языков, поэтому мы их переводим. Поэтому, если вы хотите, чтобы ваши «коды» сообщались, вам придется внести свои коррективы. Вы видите, что мы, пользователи, должны изменить наши форматы данных, чтобы мы не потеряли наши данные.

vic belleli
источник
-2

Я бы сказал, что это не так. Общая структура / формат кода в команде - определенно хорошая вещь, но автоматическое ее применение - нет. Это должно быть сделано людьми, а не компьютером.

Мои самые большие проблемы с концепцией

  1. Если я пишу код в одном формате, и он автоматически переформатируется, какой стимул есть для изучения этого формата?
  2. После этого предыдущего пункта, если вы не изучите формат, весь смысл автоформатирования (чтобы сделать код более легким для чтения и изменения) полностью теряется. Вам все еще нужно время, чтобы выяснить форматирование, когда вы читаете код, потому что вы не узнали этот формат
  3. Я думаю, что для разработчика было бы очень неприятно написать один день, закрыть его и вернуться на следующий день, чтобы увидеть, что он совершенно другой. Это означает, что не только другие должны изучать ваш код, вы должны изучать ваш код.
  4. Это также может способствовать ленивому кодированию. Вместо того, чтобы подталкивать разработчика к изучению формата, они могут писать в любом формате под солнцем, и это будет выглядеть автоматически так, как этого хотят все остальные. Это восходит к # 2, где вы не изучаете стиль и все еще не можете прочитать его правильно.

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

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

Джош Януш
источник
+1: Хорошие моменты, хотя я не уверен, что они перевешивают причины в пользу автоматического переформатирования. Почему даунвот (ы)?