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
, что приведёт к ошибкам компиляции, билда или же просто предупреждениям в консоли. Всё зависит только от вашего личного отношения и общего уровня тоталитаризма и дисциплины по части кода в вашей компании 🙂
Надеюсь, что был полезен. До следующих встреч!