Как хранить код (C#) в системе хранения версий (git) без форматирования?

Question

[AlenPelin]

Конечная цель: полностью ликвидировать вопрос форматирования кода в проекте таким образом, чтобы каждый член команды:

1. писал код с таким форматированием, как ему нравится (табы/пробелы, пустые строки, порядок методов в классах, многострочные комментарии etc.),
   
2. видел код, написанный другими в соответствии со своими предпочтениями
   

Способ реализации: написать приложение со следующими коммандами:

1. Первый запуск, конвертация форматированного кода в минимизированный (без пробелов/табов, методы отсортированы алфавитно по имени и типам параметров)
   
2. Начало работы, конвертация минимизированного кода из /src в форматированный в /src.tmp с учетом настроек (например, R#)
   
3. Конец работы, конвертация /src.tmp в минимизированный /src
   

Соответстветнно, пункт 3 можно выполнять постоянно после каждого изменения кода.

Вопрос: существует ли уже готовое решение?

P.S. также приложение можно расширить для минимизации .csproj файлов, исключая оттуда очевидные инклюды файлов с целью избавления от конфликтов при мердже и добавляя туда информацию об исключениях (например, изначально MyClass1.cs, ... ,MyClass99.cs включены в .csproj, а OtherClass1.cs, ... , OtherClass99.cs не влючены - при конвертации информация о MyClass1 ... 99 будет убрана, а информация об игнорировании OtherClass1 ... 99 будет добавлена).

Comments

[Espleth]

Да, существует готовое решение, называется единый стайлгайд.
Ваше решение - это костыль. К примеру зачастую ставятся пустые строки внутри методов, чтобы отделить некоторые куски кода друг от друга. Очевидно, что при конвертировании в "минимизированный" код эти пустые строки исчезнут, ну и при восстановлении кода из воздуха тоже не возникнут - ставятся они интуитивно, а не по четкому алгоритму.
И с именованием переменных вполне возможны проблемы, например назовет один программист в классе 3 переменные: public X, private x, private _X, а второй привык, что public с маленькой буквы, а private с нижним подчеркиванием, в итоге все благополучно запутается.

[AlenPelin]

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

[Espleth]

AlenPelin: обращу ваше внимание на ReSharper, если есть возможность его использовать, а именно теоретический вариант решения с ним:
Там можно довольно тонко настраивать стайлгайд. Создается единый "минимизированный" стайлгайд его средствами, используя этот стайлгайд форматируется код. Далее программисты получают код и форматируют его своим стайлгайдом, а перед коммитами форматируют обратно.
Я, правда, пол года назад искал способ переключения между стайлгайдами в ReSharper, и безуспешно, но возможно, что проблема была во мне.
У такого решения есть минусы в виде лишних телодвижений и возможно недостаточной "отвязанностью" внешнего вида кода от изначально написанного.
Но первый минус наверняка можно решить, как-то автоматизировав систему (как - это уж точно не ко мне), а второй - это, пожалуй, плата за легкость решения.

[AlenPelin]

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

[MonkAlex]

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

[AlenPelin]

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

[MonkAlex]

AlenPelin: в таком случае, контрибьюторы обычно пишут в стиле проекта, а не в своем собственном. Никто не ждёт, что пара коммитов от стороннего человека будут прям соответствовать стайлгайду, но писать опытные программисты будут по аналогии с остальным вашим кодом. А остальное могут поправить принимающие\рецензирующие.

[AlenPelin]

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

[Даниил Басманов]

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

[AlenPelin]

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