Знаки табуляции или пробелы: решаем с помощью Visual Studio

Привет, Хабр! Культурные воины продолжаются, люди сражаются по разные стороны баррикад, пытаясь решить: tabs or spaces. На эту же тему мы нашли интересную статью Скотта Хансельмана, в которой он рассказывает про инструмент, решающий это спор, EditorConfig в Visual Studio. Всех интересующихся прошу под кат.



Помните, летом на StackOverflow была статья о том, что на пробелах люди зарабатывают больше.



Разберемся в этом вместе с Джиной Трапани (Gina Trapani). Найдем рабочий код.

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

Откройте проект, создайте новый файл .editorconfig и вставьте в него следующий код. Я воспользуюсь программой «Hello, world!» в новой консоли .NET.

[*.cs]
indent_style = tab
indent_size = tab
tab_size = 4

В моем примере указано только расширение *.cs, но вы также можете указать [*.{cs,js}] или, если хотите, только [*], либо сразу множество разделов.

Убедитесь, что файл введен в систему вместе с проектом, чтобы каждый член команды смог оценить все его преимущества.

Вы можете увидеть в Notepad2, если кто-то, как в каменном веке, использует пробелы в качестве разделителя. Пробелы в этом редакторе отображаются как бледные точки.



Я открываю этот проект в Visual Studio 2017 со встроенной поддержкой EditorConfig. Обратите внимание на отображаемое внизу предупреждение Visual Studio о том, что в проекте имеются обозначения, не совпадающие с нашими.

Команды Visual Studio для форматирования документов в этом проекте будут использовать знаки табуляции, а не пробелы. Вот тот же документ, переформатированный в Visual Studio:



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

Расширения .NET для EditorConfig

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

Вы можете использовать массу удобных опций .NET EditorConfig. Благодаря им члены команды будут применять одинаковые языковые стандарты, соглашения об именовании и правила форматирования.

• Языковые стандарты. Это правила, применяемые в языке C# или Visual Basic, например тип var/explicit, функции и свойства в теле выражений.
• Правила форматирования. Это правила разметки и структурирования кода, используемые для удобочитаемости, например стиль Олмана, пробелы в контрольных блоках.
• Соглашения об именовании. Это правила именования объектов, например методы async должны заканчиваться на «Async».

Вы также можете задать степень важности правил, используя опции типа suggestion, warning или даже error.

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

dotnet_style_predefined_type_for_locals_parameters_members = true:error

В Visual Studio в соответствующей строке появится значок лампочки с предлагаемым исправлением, ведь, скорее всего, мои сотрудники вместо полной формы «System.String» напечатают просто «string».



В EditorConfig для .NET Docs имеется МНОЖЕСТВО отличных настроек, которыми можно пользоваться или игнорировать их. Вот лишь несколько (неоднозначных) примеров:

• csharp_new_line_before_open_brace — оставлять открытые скобки в конце строки или помещать их на отдельной строке?
• csharp_new_line_before_members_in_object_initializers — допускается ли размещение элементов A = 3, B = 4 на одной строке или каждый из них располагается на отдельной строке?
• csharp_indent_case_contents — будут ли все команды switch/case отображаться одинаково в начале строки или все же перед командами case будет стоять отступ, как и было задумано создателем?
• Мы можем даже всячески настраивать регистр Case: pascal_case, camel_case, first_word_upper, all_upper, all_lower

Если вы работаете с Visual Studios 2010, 2012, 2013 или 2015, то можете быть спокойны. Как минимум, имеется базовое бесплатное расширение EditorConfig, с помощью которого можно применять основные правила. Есть также одно расширение для работы с файлами EditorConfig в Visual Studio Code, и установить его можно за считанные секунды. Но вот расширения для С# пока нет — есть только одно для преобразования пробелов.

---

Кстати, летом мы проводили голосование на эту тему в Microsoft Developer. Тогда победил Tabs. Предлагаем повторить здесь.