Проблемы с отступами в команде с разными IDE

Question

Я использую emacs + slime для разработки clojure.Недавно у нас появился новый член команды, и он не любит emacs, поэтому он установил intellij с плагином la clojure.

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

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

Итак, теперь у нас есть проблема сотрудничества.Интересно, есть ли другие команды clojure, которые используют разные IDE?Как вы решаете эти проблемы?

Опции, которые я вижу:

1. Принудительное использование одной IDE (emacs).Это решит проблему, но мне не нравится такой авторитетный подход.

2. Каким-то образом настроить обе среды на одинаковый отступ (не уверен, если это возможно)

3. Согласитесь всегда делать отступ в одной IDE.Это громоздко и подвержено ошибкам.

Answer 1

Вы можете попробовать попросить его уважать остальных членов команды и не переформатировать автоматически код каждого.

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

Удачи.

Answer 2

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

Однако параметры конфигурации для отступа находятся в: Настройки> Стиль кода

Answer 3

Номер 2): одна команда, один стандарт кодирования.

Answer 4

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