Ищите настраиваемый симпатичный принтер для кода C # - PullRequest
2 голосов
/ 13 ноября 2008

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

Ответы [ 4 ]

1 голос
/ 07 января 2009

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

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

Для получения дополнительной информации см. Мою статью CodeProject по Использование NArrange для организации кода C # .

1 голос
/ 13 ноября 2008

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

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

ServiceLocator.Logger.WriteDefault(string.format("{0}{1}"
                                                 ,foo
                                                 ,bar)
                                   ,Logging.SuperDuper); 

еще один пример форматирования в visual studio не слишком горячий ...

if( foo
   && ( bar 
       || baz 
       || apples 
       || oranges)
   && IsFoo()
   && IsBar() ){
   }

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

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

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

Что касается значений по умолчанию VS, я могу только сказать: стиль BSD или умри!

Итак, все, что возвращает меня к полному кругу: есть ли настраиваемый симпатичный принтер для C #? Как лексический анализ, так и парсинг, который у меня был, заставили меня заполнить цепочку инструментов YAML C #.

1 голос
/ 13 ноября 2008

Самое простое решение для команды привести к обязательному формату, и все используют его. Значения по умолчанию VS довольно хорошие.

Джефф Этвуд сделал это с нами здесь, на Stack Overflow, и хотя я сначала взбунтовался, я преодолел это :) Делает все намного проще!

0 голосов
/ 13 ноября 2008

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

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

Стандарты кодирования - это просто стандарты. Они не называют их законами кодирования или правилами кодирования, и для этого есть веская причина.

...