EditorConfig. Борьба за консистентность

В вечной IT-борьбе бест практик и подходов, фреймворков и языков программирования, также неизбежно возникают и обычные вкусовые разногласия — табуляция против пробелов (конечно же табы!), в каком виде писать фигурные скобки, как именно заканчивать строку и как в целом форматировать код. Здесь сколько людей — столько и мнений. И лучшей фразой, наверное, не начнёшь сегодняшнюю мою статью 🙂

Как правило разработчики языков программирования пишут рекомендательные правила и свои code guide, согласно личных видений правильного и с позиции авторов (имеют право). Но рекомендательные — это не правило и мы легко можем увидеть, к примеру, форматированный С# код в стиле Java.

Перевод строки

Но вкусы отступов — это ещё пол беды. Среда также вносит немаловажные разброд и шатания уже со своим видением на текст и самым важным элементом здесь является интерпретация операционной системы конца строки (также перевод или разрыв; на английском NEL — как next line), т.е. теми действиями, которые сопровождаются во время нажатия клавиши Enter.

И данная проблема стара как мир (цифровой, как минимум). Думаю, что правильным было немного остановиться здесь и разобраться. Итак, возврат строки — это управляющие символы (так сложилось исторически), которые не видны в явном виде, но у них есть своя определённая функция на более низком, чисто компьютерном уровне. Давайте пример рассмотрим. Если сейчас ваша операционная система Windows и вы создадите обыкновенный TXT файл с двумя строчками (к примеру с цифрой «1» на первой строке и цифрой «2» на второй), то получите файл размером 4 байта (не 2). Первый байт будет занят символом ‘1’, второй байт символом CR, третий LF и только четвёртый — символом ‘2’. Тем самым промежуточные два байты сокрыты от глаз (их можно увидеть только при помощи HEX просмотра, либо же включить отображение невидимых символов в вашей IDE, т.е. многие современные редакторы умеют это делать).

CR (carriage return) — возврат каретки. Управляющий символ ASCII под номером 13, соответственно в HEX представлении имеет код 0x0D или же текстовый «сишный» эквивалент в виде строки \r. По сути основная, главная и единственная задача данного управляющего символа — перевод курсора в начало строки.

LF (line feed) — подача\перевод на строку. В таблице ASCII данный символ числится под номером 10, в HEX — 0x0A и в строковом виде \n.

Собственно, этих двух байт хватает для того, чтобы мир погрузился в хаос разнородного понимания текста, т.к. разные операционные системы по-разному работают с строками. LF используется во всех UNIX системах, CR использовался преимущественно на старых системах Apple II, Commodore и MacOS до 9й версии, CR+LF — в операционной системе Windows. Кроме всего прочего, разные текстовые протоколы также вполне могут иметь своё видение данного вопроса, к примеру, HTTP по стандарту солидарен с Windows в своём выборе CR+LF.

Проблеме уже несколько десятков лет и только в последнее время Unicode пытается усреднить разногласия и считать CR, LF, CR+LF — одинаково; что впрочем противоречит ASCII, который и наследует. Получится решить эту проблему и примирить всех — неизвестно и дело это будущего, а решать консистентность нам нужно уже сегодня.

Чем это чревато? Чем плохо отсутствие консистентности?

Стоит оговорить, что в самостоятельной разработке, когда вы единственный человек, вносящий изменения в код — данная проблема имеет место лишь только в том случае, если вы вносите эти изменения за разными операционными системами или, например, поменяли настройки в самой IDE где-то по середине проекта 🙂 Что, по сути, тоже не смертельно. Вы — один.

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

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

Поглядите на этот реальный кусочек кода, открытый в Notepad++ с отображением управляющих символов — табуляции, пробелов, возврата каретки и новой строки. В одном маленьком кусочке мы собрали full house (говоря покерными терминами) всех вариантов: здесь и LF, и CRLF, и табуляция и пробелы.

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

Что же делать?

Существуют специальные программы — линтеры, которые умеют анализировать код и проверять соответствие с правилами. Иногда, такие программки встроены в IDE, иногда устанавливаются как плагины или же доступны с языком (к примеру для языка программирования Go существует в коробке программа gofmt, которая форматирует правильный код).

Сегодня речь пойдёт о маленьком инструменте, который, наверное, нельзя назвать в полном смысле слово линтером — скорее форматом представления настроек и code guide. Лёгкость и простота использования данного подхода помогает решить 99% всех проблем с кодом. И, да, сегодня речь пойдёт об EditorConfig (официальный сайт здесь).

EditorConfig — это файл .editorconfig в слегка изменённом формате INI, в котором описываются эти самые правила. Основные и главные современные IDE поддерживают его либо нативно (т.е. прям из коробки), либо при помощи установки плагина, реализующего данный функционал. Лишь единожды установив правила и «подложив» такой файл в репозиторий вы навсегда избавляете себя от вышеуказанных проблем отсутствия консистентности. Раз и навсегда. Вот список (взят с официального сайта) сред разработки, в которых данная технология поддерживается нативно:

Ниже представлен список сред, для которых существует специальный плагин:

Как вы видите, есть всё — от Visual Studio\Visual Studio Code, Rider/Resharper и до простых текстовых редакторов типа Notepad++.

Как устроен файл .editorconfig?

Это самый обыкновенный текстовый файл в кодировке UTF-8 с переносом строки CRLF или LF без разницы, созданный в формате INI. В самом простом и сокращённом виде он выглядит следующим образом:

# Корневой файл EditorConfig, т.е. данный файл расположен в корне проекта
root = true

[*]
# Используем табы для отступов
indent_size = 4
indent_style = tab

# Все файлы используют windows перенос строки, а также в конце файл будет пустая строка
end_of_line = crlf
insert_final_newline = true

Уже только этого будет достаточно, чтобы добиться единого стиля во всём проекте, т.к. при форматировании, добавлении и изменении IDE будет ориентироваться на данные правила — в первую очередь. Формат — стандартный INI с секциями (маска файлов, к примеру, указанная выше в файле секция [*] определяет правила для всех файлов — с любыми именами и расширениями) и параметрами ключ-значение. И, наконец, всё, что начинается с символа решётки — является комментарием.

Секции

INI-секции EditorConfig немного отличаются от стандарта и спецификации INI, в том смысле, что позволяют не просто указать имя, а хранят также в себе и определённые инструкции. Конкретнее — маска файлов, к которым эти инструкции относятся. Существует своеобразный синтаксис, который немного напоминает регулярные выражения:

• * — шаблон любого символа, за исключением символа /;
• ** — шаблон абсолютно любого символа;
• ? — один любой символ;
• [name] — поиск по полному соответствию;
• [!name] — всё, что не соответствует введённому;
• {str1, str2, str3} — один из вариантов введённых строк;
• {1..10} — числовой диапазон;

Ниже я добавил несколько секций для демонстрации и прокомментировал каждую из них:

# для всех файлов
[*]

# секция для всех файлов с расширением .cs
[*.cs]

# настройки только для двух файлов config.json и config.yml
[{config.json,config.yml}]

# тоже самое:
[config.{json,yml}]

# Все картинки, находящиеся в папке media
[media/*.jpg]

# Все картинки в папке media и во всех вложенных подпапках
[media/**.jpg]

# Правила для трёх файлов a.php, b.php, c.php
[[abc].php]

# Правила для всех остальных файлов .php, к примеру, для z.php, x.php и т.д.
[[!abc].php]

Параметры

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

• root — указывает является ли данный файл корневым и, соответственно, первым и последним в иерархии наследования правил. Параметр данный булевый и принимает лишь два варианта значений: true или false. Если указано true, то дальнейший поиск правил на уровень выше не перейдёт.
• charset — позволяет указать кодировку файла, что позволяет определить будете ли вы везде использовать utf-8 или utf-8-bom.
• indent_style — стиль отступов: пробелы или табуляция. Данный параметр принимает два варианта: tab и space, соответственно;
• indent_size — укажите число пробелов в отступе;
• tab_width — укажите число отступа для табуляции;
• end_of_line — позволяет выбрать один из трёх вариантов переноса строки: cr, lf, crlf.
• insert_final_newline — позволяет добавлять символ конца строки в конце каждого редактируемого файла;
• trim_trailing_whitespace — булевые true или false позволяют «отрезать» лишние пробелы в конце строки.

Как это работает?

Сам по себе .editorconfig не исправит ситуацию в вашем всём проекте, если был добавлен где-то посередине разработки. Поэтому самым правильным вариантом было бы добавление нашего этого файла до создания проекта. И хорошо бы заиметь и закрепить эту привычку, как такое же необходимое и очевидное, как .gitignore или README.md.

Данный файл даёт инструкции IDE и эти инструкции срабатывают, когда вы работаете с текстом — непосредственно в сам момент ввода, редактирования и форматирования. Некоторые инструкции, такие как end_of_line, insert_final_newline и т.д. срабатывают в момент сохранения файла.

.NET C#

Самый простой способ добавить новый EditorConfig — добавить через New Item в ваш solution. После добавления студия автоматически создаст виртуальную подпапку Solution items в проекте. Если же вы просто добавите данный файл, то монитор файловой студии подскажет студии о появлении нового файла и студия предложит добавить данный проект в сам проект\солюшн. Вот таким образом:

Также, стоит заметить, что кроме основных «стандартных» настроек — многие платформы и языки вольны создавать свои правила. И, конечно же, dotnet не стал исключением из правил. Существует огромная масса тонкостей настройки и каждый из подобных параметров может начинаться на префиксы dotnet_, csharp_ или подобные другие. Ниже показан пример официального .editorconfig для .NET и C#:

# Remove the line below if you want to inherit .editorconfig settings from higher directories
root = true

# C# files
[*.cs]

#### Core EditorConfig Options ####

# Indentation and spacing
indent_size = 4
indent_style = space
tab_width = 4

# New line preferences
end_of_line = crlf
insert_final_newline = false

#### .NET Coding Conventions ####

# Organize usings
dotnet_separate_import_directive_groups = false
dotnet_sort_system_directives_first = false
file_header_template = unset

# this. and Me. preferences
dotnet_style_qualification_for_event = false:silent
dotnet_style_qualification_for_field = false:silent
dotnet_style_qualification_for_method = false:silent
dotnet_style_qualification_for_property = false:silent

# Language keywords vs BCL types preferences
dotnet_style_predefined_type_for_locals_parameters_members = true:silent
dotnet_style_predefined_type_for_member_access = true:silent

# Parentheses preferences
dotnet_style_parentheses_in_arithmetic_binary_operators = always_for_clarity:silent
dotnet_style_parentheses_in_other_binary_operators = always_for_clarity:silent
dotnet_style_parentheses_in_other_operators = never_if_unnecessary:silent
dotnet_style_parentheses_in_relational_binary_operators = always_for_clarity:silent

# Modifier preferences
dotnet_style_require_accessibility_modifiers = for_non_interface_members:silent

# Expression-level preferences
dotnet_style_coalesce_expression = true:suggestion
dotnet_style_collection_initializer = true:suggestion
dotnet_style_explicit_tuple_names = true:suggestion
dotnet_style_null_propagation = true:suggestion
dotnet_style_object_initializer = true:suggestion
dotnet_style_operator_placement_when_wrapping = beginning_of_line
dotnet_style_prefer_auto_properties = true:silent
dotnet_style_prefer_compound_assignment = true:suggestion
dotnet_style_prefer_conditional_expression_over_assignment = true:silent
dotnet_style_prefer_conditional_expression_over_return = true:silent
dotnet_style_prefer_inferred_anonymous_type_member_names = true:suggestion
dotnet_style_prefer_inferred_tuple_names = true:suggestion
dotnet_style_prefer_is_null_check_over_reference_equality_method = true:suggestion
dotnet_style_prefer_simplified_boolean_expressions = true:suggestion
dotnet_style_prefer_simplified_interpolation = true:suggestion

# Field preferences
dotnet_style_readonly_field = true:suggestion

# Parameter preferences
dotnet_code_quality_unused_parameters = all:suggestion

# Suppression preferences
dotnet_remove_unnecessary_suppression_exclusions = none

#### C# Coding Conventions ####

# var preferences
csharp_style_var_elsewhere = false:silent
csharp_style_var_for_built_in_types = false:silent
csharp_style_var_when_type_is_apparent = false:silent

# Expression-bodied members
csharp_style_expression_bodied_accessors = true:silent
csharp_style_expression_bodied_constructors = false:silent
csharp_style_expression_bodied_indexers = true:silent
csharp_style_expression_bodied_lambdas = true:silent
csharp_style_expression_bodied_local_functions = false:silent
csharp_style_expression_bodied_methods = false:silent
csharp_style_expression_bodied_operators = false:silent
csharp_style_expression_bodied_properties = true:silent

# Pattern matching preferences
csharp_style_pattern_matching_over_as_with_null_check = true:suggestion
csharp_style_pattern_matching_over_is_with_cast_check = true:suggestion
csharp_style_prefer_not_pattern = true:suggestion
csharp_style_prefer_pattern_matching = true:silent
csharp_style_prefer_switch_expression = true:suggestion

# Null-checking preferences
csharp_style_conditional_delegate_call = true:suggestion

# Modifier preferences
csharp_prefer_static_local_function = true:suggestion
csharp_preferred_modifier_order = public,private,protected,internal,static,extern,new,virtual,abstract,sealed,override,readonly,unsafe,volatile,async:silent

# Code-block preferences
csharp_prefer_braces = true:silent
csharp_prefer_simple_using_statement = true:suggestion

# Expression-level preferences
csharp_prefer_simple_default_expression = true:suggestion
csharp_style_deconstructed_variable_declaration = true:suggestion
csharp_style_inlined_variable_declaration = true:suggestion
csharp_style_pattern_local_over_anonymous_function = true:suggestion
csharp_style_prefer_index_operator = true:suggestion
csharp_style_prefer_range_operator = true:suggestion
csharp_style_throw_expression = true:suggestion
csharp_style_unused_value_assignment_preference = discard_variable:suggestion
csharp_style_unused_value_expression_statement_preference = discard_variable:silent

# 'using' directive preferences
csharp_using_directive_placement = inside_namespace:silent

#### C# Formatting Rules ####

# New line preferences
csharp_new_line_before_catch = true
csharp_new_line_before_else = true
csharp_new_line_before_finally = true
csharp_new_line_before_members_in_anonymous_types = true
csharp_new_line_before_members_in_object_initializers = true
csharp_new_line_before_open_brace = all
csharp_new_line_between_query_expression_clauses = true

# Indentation preferences
csharp_indent_block_contents = true
csharp_indent_braces = false
csharp_indent_case_contents = true
csharp_indent_case_contents_when_block = true
csharp_indent_labels = one_less_than_current
csharp_indent_switch_labels = true

# Space preferences
csharp_space_after_cast = false
csharp_space_after_colon_in_inheritance_clause = true
csharp_space_after_comma = true
csharp_space_after_dot = false
csharp_space_after_keywords_in_control_flow_statements = true
csharp_space_after_semicolon_in_for_statement = true
csharp_space_around_binary_operators = before_and_after
csharp_space_around_declaration_statements = false
csharp_space_before_colon_in_inheritance_clause = true
csharp_space_before_comma = false
csharp_space_before_dot = false
csharp_space_before_open_square_brackets = false
csharp_space_before_semicolon_in_for_statement = false
csharp_space_between_empty_square_brackets = false
csharp_space_between_method_call_empty_parameter_list_parentheses = false
csharp_space_between_method_call_name_and_opening_parenthesis = false
csharp_space_between_method_call_parameter_list_parentheses = false
csharp_space_between_method_declaration_empty_parameter_list_parentheses = false
csharp_space_between_method_declaration_name_and_open_parenthesis = false
csharp_space_between_method_declaration_parameter_list_parentheses = false
csharp_space_between_parentheses = false
csharp_space_between_square_brackets = false

# Wrapping preferences
csharp_preserve_single_line_blocks = true
csharp_preserve_single_line_statements = true

#### Naming styles ####

# Naming rules

dotnet_naming_rule.interface_should_be_begins_with_i.severity = suggestion
dotnet_naming_rule.interface_should_be_begins_with_i.symbols = interface
dotnet_naming_rule.interface_should_be_begins_with_i.style = begins_with_i

dotnet_naming_rule.types_should_be_pascal_case.severity = suggestion
dotnet_naming_rule.types_should_be_pascal_case.symbols = types
dotnet_naming_rule.types_should_be_pascal_case.style = pascal_case

dotnet_naming_rule.non_field_members_should_be_pascal_case.severity = suggestion
dotnet_naming_rule.non_field_members_should_be_pascal_case.symbols = non_field_members
dotnet_naming_rule.non_field_members_should_be_pascal_case.style = pascal_case

# Symbol specifications

dotnet_naming_symbols.interface.applicable_kinds = interface
dotnet_naming_symbols.interface.applicable_accessibilities = public, internal, private, protected, protected_internal, private_protected
dotnet_naming_symbols.interface.required_modifiers =

dotnet_naming_symbols.types.applicable_kinds = class, struct, interface, enum
dotnet_naming_symbols.types.applicable_accessibilities = public, internal, private, protected, protected_internal, private_protected
dotnet_naming_symbols.types.required_modifiers =

dotnet_naming_symbols.non_field_members.applicable_kinds = property, event, method
dotnet_naming_symbols.non_field_members.applicable_accessibilities = public, internal, private, protected, protected_internal, private_protected
dotnet_naming_symbols.non_field_members.required_modifiers =

# Naming styles

dotnet_naming_style.pascal_case.required_prefix =
dotnet_naming_style.pascal_case.required_suffix =
dotnet_naming_style.pascal_case.word_separator =
dotnet_naming_style.pascal_case.capitalization = pascal_case

dotnet_naming_style.begins_with_i.required_prefix = I
dotnet_naming_style.begins_with_i.required_suffix =
dotnet_naming_style.begins_with_i.word_separator =
dotnet_naming_style.begins_with_i.capitalization = pascal_case

Здесь вы можете более тонко установить формат, стиль кода и даже подход к неймингу переменных, классов, свойств и локальных полей. Также, в значений параметров можно указать уровень важности правила (подобно логам): warning или error, что приведёт к ошибкам компиляции, билда или же просто предупреждениям в консоли. Всё зависит только от вашего личного отношения и общего уровня тоталитаризма и дисциплины по части кода в вашей компании 🙂

Надеюсь, что был полезен. До следующих встреч!