Для чего в программах используются комментарии
Комментарии (программирование)
Коммента́рии — пояснения к исходному тексту программы, находящиеся непосредственно внутри комментируемого кода. Синтаксис комментариев определяется языком программирования. С точки зрения компилятора или интерпретатора, комментарии — часть текста программы, не влияющая на её семантику. Комментарии не оказывают никакого влияния на результат компиляции программы или её интерпретацию. Помимо исходных текстов программ, комментарии также применяются в языках разметки и языках описания.
Содержание
Назначение комментариев
Большинство специалистов сходятся во мнении, что комментарии должны объяснять намерения программиста, а не код; то, что можно выразить на языке программирования, не должно выноситься в комментарии — в частности, надо использовать говорящие названия переменных, функций, классов, методов и пр., разбивать программу на лёгкие для понимания части, стремиться к тому, чтобы структура классов и структура баз данных были максимально понятными и прозрачными и т. д. Есть даже мнение (его придерживаются в экстремальном программировании и некоторых других гибких методологиях программирования), что если для понимания программы требуются комментарии — значит, она плохо написана.
Концепция грамотного программирования настаивает на включение в текст программы настолько подробных и продуманных комментариев, чтобы она стала исходным текстом не только для исполняемого кода, но и для сопроводительной документации.
Комментарии часто используются для временного отключения части кода. В языках C и C++, некоторые рекомендуют использовать с той же целью директивы препроцессора ( #if 0 … #endif ).
Однострочные и многострочные комментарии
С точки зрения синтаксиса, существуют два вида комментариев. Многострочный комментарий может иметь любую длину, он отмечается специальными символами в начале и конце (например, /* */ ). Некоторые языки позволяют вложение многострочных комментариев, другие — нет.
Однострочный комментарий отмечается специальным символом в начале (например, // ) и продолжается до конца строки. Обычно допускается вложение однострочных комментариев в другие, как одно- так и многострочные комментарии. Способы записи можно чередовать, с точки зрения семантики они одинаковы.
Аннотации
Другой вид комментариев — аннотации — применяется в набросках доказательств правильности программ. Такие комментарии описывают состояние компьютера, когда программа в процессе выполнения достигнет точки, где расположен комментарий. Программа, снабжённая комментариями-аннотациями, называется аннотированной программой.
Автоматическая генерация документации
Документирующие комментарии как правило оформляются как многострочные комментарии в стиле языка Си. В каждом случае комментарий должен находиться перед документируемым элементом. Первым символом в комментарии (и вначале строк комментария) должен быть *. Блоки разделяются пустыми строками.
В некоторых средах программирования (например, Eclipse, NetBeans, Python, Visual Studio) документирующие комментарии используются в качестве интерактивной подсказки по интерфейсу классов и функций.
Трансляция программ
Во время трансляции комментарии распознаются на стадии лексического анализа (и, соответственно, считаются лексемами). Распознавание на стадии препроцессирования накладно и даже чревато ошибками; включение комментариев в синтаксические диаграммы практически невозможно.
В различных языках и средах программирования
Специальные комментарии
Комментарии должны игнорироваться транслятором, но на практике это не всегда так. Некоторые специальные команды транслятору, сильно зависящие от реализации языка программирования, часто оформляются как комментарии.
Например в диалекте Турбо Паскаль псевдокомментарии <$I->и <$I+>используются для отключения и включения стандартного контроля ошибок ввода-вывода. Похожие специальные комментарии используются в языке разметки HTML для указания типа SGML-документа, «экранирования» таблиц стилей и сценариев на языках JavaScript и VBScript:
Некоторые комментарии программисты используют в ходе своей работы. Подобные комментарии особенно полезны, когда над одним кодом работает несколько разработчиков. Так, комментарием TODO обычно помечают участок кода, который программист оставляет незавершённым, чтобы вернуться к нему позже. Комментарий FIXME помечает обнаруженную ошибку, которую решают исправить позже. Комментарий XXX обозначает найденную критическую ошибку, без исправления которой нельзя продолжать дальнейшую работу.
Комментарии в языке C#
Только в простейшем случае исходная программа может состоять из одного файла, гораздо чаще приходится иметь дело с несколькими файлами – программными модулями (см. примеры консольного и оконного приложений).
Комментариями называются те части программных модулей, которые при компиляции игнорируются.
Зачем же тогда даже опытные программисты вставляют их в тексты своих программ?
Первая причина – сохранение выходных данных программы (наименование, назначение, версия, связь с другими модулями, авторские права, время создания или последнего изменения).
Вторая причина – обеспечение понимания структуры и логики программы, так как даже ее автор спустя некоторое время, когда потребуется анализ или корректировка программы, забывает их.
Третья причина – обеспечение понимания программы другими программистами – коллегами, руководителями и учениками.
Можно сказать, что разумные комментарии являются простейшим способом документирования процесса разработки программного обеспечения.
Комментарии являются немаловажной частью любого языка программирования, т.к. позволяют удобно пояснять различные участки кода.
Очевидно, что в многострочном комментарии не может присутствовать комбинация */, поскольку она будет трактоваться как конец комментария.
Многострочный комментарий можно помещать в одну строку кода:
Console.WriteLine (/* Здесь идет комментарий! */ «Это скомпилируется»);
Встроенные комментарии вроде этого нужно применять осторожно, потому что они могут ухудшить читабельность кода. Однако они удобны при отладке, скажем, когда необходимо временно попробовать запустить программу с указанным другим значением:
DoSomethingMethod (Width, /*Height*/ 100);
Символы комментария, включенные в строковый литерал (между кавычками), трактуются как обычные символы:
string s = «/* Это просто нормальная строка */»;
Пример комментирования (несколько избыточного) вашей первой программы:
Далее обращайте внимание на комментарии к примерам, решайте сами, помогают ли они, по сути, понять программы.
Перейдем к важнейшей теме Типы данных в языке C#
Зачем комментировать исходный код и как это делать правильно
Как не забыть о том, что вы имели ввиду полгода назад, когда писали этот программный код? Разбираемся с использованием комментариев.
Комментарии — поясняющие строки в программном коде, которые позволяют понять смысл написанного. Они пишутся для людей, но игнорируются компиляторами и интерпретаторами.
Знакомый, наверно, каждому пример со словами на русском или английском языке после двух слешей — так обычно выглядят комментарии:
Программист, консультант, специалист по документированию. Легко и доступно рассказывает о сложных вещах в программировании и дизайне.
Чем комментарии могут помочь программисту
Комментарии, в зависимости от ситуации, делают сразу несколько полезных вещей:
Как комментарии оформляют в коде
Комментарии бывают совсем короткими, длиной не более строки, и большими, многострочными.
Однострочные выделяют одиночным символом в начале и продолжают до конца строки, а многострочные могут иметь любую длину, но поддерживаются не всеми языками. Их отмечают специальными символами в начале и конце текста, например, /* и */.
Для выделения комментариев в коде используют разные символы:
Правила, которых принято придерживаться
У разработчиков принято использовать при комментировании несколько простых правил. Так легче работать — больше пользы и не нужно плодить лишние строки кода.
1. Комментарии помещаются прямо над кодом, к которому они относятся. Так проще понять, о чём речь, не вникая в содержание каждой строчки. Совсем короткие пояснения можно писать справа.
2. Комментируют все основные элементы кода: модули, функции, константы, глобальные переменные, интерфейсы, классы и их составные элементы (методы, свойства, константы).
3. Пишут коротко и по делу. Комментарии без смысловой нагрузки страшно раздражают. Не нужно писать комментарии типа «это гениальный код», «таблица1», «! №; %:? *» и подобные.
4. Нельзя, чтобы комментарии оскорбляли кого-то или содержали слова, которые не поймёт технарь. В поддержку движения Black Lives Matter Twitter в своем коде решил не использовать слова slave, master и blacklist. Кто-то из россиян, возможно, улыбнётся, но стандарт есть стандарт.
Документирующие и поясняющие комментарии
В зависимости от того, для чего нужны комментарии, их условно делят на два вида:
Пример на языке Java:
Из такого комментария сразу ясно, что делает программа. Не нужно вникать в исходный текст и изучать техническую документацию. Это особенно важно, если вы работаете в команде и хотите сэкономить время коллег.
Комментарии-описания иногда мешают разработчикам и отвлекают внимание от основного кода. Поэтому в большинстве современных редакторов есть возможность свернуть или скрыть комментарии.
Как комментируют функции и библиотеки
В комментариях к файлам и библиотекам указывают информацию о проекте, назначении модуля, заносят в них имя разработчика, номер версии продукта и лицензию на программное обеспечение.
Например, документирующий комментарий из заголовка библиотеки Lodash для JavaScript выглядит так:
Кроме этого, в заголовочных комментариях к функциям указывают стандартный набор сведений:
Пример из той же библиотеки Lodash:
Главное здесь — избегать бессмысленных комментариев. Вот пример плохого описания процедуры на языке 1С:
К прикладным процедурам, функциям и классам делайте информативные и понятные заголовки с описанием всех входных и выходных параметров.
Как автоматизировать создание комментариев
В различных IDE есть возможность автоматизировать создание комментариев. Это делается с использованием тегов — дескрипторов, которые начинаются с символа @. Вот самые популярные:
Из таких комментариев автоматически формируется документация программы. Для этого используют генераторы документации, например, javadoc для языка Java, phpDocumentor для PHP, doxygen для C и C++, Epydoc для Pithon и другие.
Принцип работы прост. Генератор обрабатывает файл с исходным текстом, находит там имена классов, их членов, свойств, методов, процедур и функций, а затем связывает их с данными из наших комментариев с тегами. Из этой информации формируется документация в формате HTML, PDF, RTF или других.
При разработке библиотек и фреймворков обычно создается документация для API. Со временем она устаревает — в неё не успевают или просто забывают вносить изменения.
Если данные об изменениях в коде отражены в комментариях, с помощью генераторов документацию можно регулярно обновлять.
Когда нужны пояснения в коде, а когда — нет
Бывает, что одних документирующих комментариев недостаточно и нужно добавить пояснения внутри процедур или функций. Такие комментарии облегчают понимание кода — рассказывают, почему автор программы сделал что-то так, а не иначе.
Но иногда эти пояснения только ухудшают наглядность кода, бывают бессмысленны и даже вредны. Например, совершенно не нужны комментарии, просто пересказывающие действия программы:
Если вы вставили промежуточные комментарии для отладки или объяснения результатов, после окончания работы их нужно убрать. Иначе они будут захламлять код.
Например, функция вычисляет окончательную сумму, прибавляя проценты к основной. Для проверки программист вывел на экран промежуточный результат, а после закомментировал ненужный фрагмент.
После отладки их лучше удалить, оставив строки:
Простой код, без многочисленных циклов, ветвлений и переходов, пишут и структурируют так, чтобы никаких дополнительных пояснений к нему не требовалось.
Но бывают исключения. Допустим, разработчик попробовал несколько вариантов решения и выбрал один, не самый очевидный. Потом забыл ход своих мыслей, открыл код и решил использовать «более правильный и оптимальный вариант». И тут он понимает, что новое решение хуже старого; более того, раньше он уже это пробовал делать. Приходится откатывать всё назад. Чтобы не попасть в такую ситуацию, пишите поясняющие комментарии.
Пример на языке JavaScript:
Здесь и сам метод Number.isFinite (), и глобальная функция isFinite () проверяют, является ли параметр value конечным числом (то есть не ± ∞). Но если value = null, то isFinite (value) возвращает true, а Number.isFinite (value) возвращает false. Поэтому Number.isFinite (value) нельзя менять на isFinite (value).
Обязательно комментируйте код, если в нём есть какие-то тонкости и неочевидные вещи. Например:
Это неудачный комментарий: непонятно, зачем количество умножать на 2.
Правильно будет так:
В любом случае, старайтесь писать поясняющие комментарии как можно реже.
Комментарии в сложном коде и рефакторинг
В сложной и запутанной программе не обойтись без поясняющих комментариев. Но иногда лучше упростить сам код: разбить на отдельные функции, уменьшить размеры элементов, упростить циклы и так далее. А самим функциям, константам и переменным дать «говорящие» имена, объясняющие их назначение.
Например, есть метод, который сравнивает числа a и b. Если a > b, он возвращает true, a если a
Весь этот громоздкий кусок кода можно значительно упростить, просто убрав блок if-else:
Теперь метод выглядит намного проще и элегантнее, хотя его суть не изменилась. Подобные преобразования называются рефакторингом.
Рефакторинг меняет структуру кода, оставляя неизменной его суть. Он повышает читаемость кода и облегчает процесс его доработки. Рефакторинг не заменяет комментирование, но с ним комментариев нужно намного меньше.
Что в итоге
Комментарии — отличная штука. Они помогают команде разработчиков работать над общим проектом. А если программист один, позволят ему даже через много лет вспомнить ход своих мыслей. Но комментариев должно быть мало, иначе они превратятся во флуд.
Комментировать нужно основные элементы кода, неочевидные решения, сложные бизнес-процессы, тонкости решений и тому подобное. Не пишите комментарии, объясняющие, что и как делает процедура или функция, — это бессмысленно.
И помните, что комментарий — не панацея, он не спасёт плохой код, даже если сделает его понятнее. Сложные и запутанные фрагменты сокращайте и делайте рефакторинг, а комментируйте по минимуму.
Научиться использовать комментарии, верно документировать исходный код, писать его понятным для коллег и читабельным даже через много лет вы можете на наших курсах по программированию. Выбирайте любой и становитесь профессионалом.
Quality Assurance дословно означает «обеспечение качества» — специалисты отвечающие за функциональное тестирование программного обеспечения на этапе разработки.
Агоритмический язык, который разработан и используется в ПО для управления оборудованием «Буран», «Морской старт», «Фрегат», «Протон-М» и других космических программ РФ.
Встроенный язык программирования, который используется в семействе программ «1С: Предприятие». Является интерпретируемым языком высокого уровня.
Б иблиотека JavaScript, которая предоставляет вспомогательные функции для общих задач программирования с использованием парадигмы функционального программирования.
Интегрированная среда разработки, (Integrated development environment) — комплекс программных средств, используемый программистами для разработки программного обеспечения.
Лучшие практики написания комментариев к коду
Известный профессор МТИ Гарольд Абельсон сказал: «Программы нужно писать для того, чтобы их читали люди, и лишь случайно — чтобы их исполняли машины». Хотя он намеренно преуменьшил важность исполнения кода, однако подчёркивает, что у программ две важные аудитории. Компиляторы и интерпретаторы игнорируют комментарии и с одинаковой лёгкостью воспринимают все синтаксически корректные программы. У людей всё иначе. Одни программы нам воспринимать легче, чем другие, и мы ищем комментарии, которые помогут нам разобраться.
Есть множество источников информации, помогающих программистам писать более качественный код — книги, сайты, статические анализаторы. Но гораздо меньше источников посвящено повышению качества комментариев. Легко измерить их количество в программе, но качество оценить сложно, и два этих параметра не обязательно взаимосвязаны. Плохой комментарий хуже отсутствия комментария. Вот несколько правил, которые помогут вам найти золотую середину.
Как писал Питер Фогель:
Первое правило: комментарии не должны дублировать код
Многие начинающие программисты пишут слишком много комментариев, потому что их к этому приучили. Я видел, как старшекурсники на факультете информатики добавляют комментарии к каждой закрывающей скобке, чтобы показать закрытие блока:
Я слышал о преподавателях, которые требуют от студентов комментировать каждую строку кода. Для совсем новичков это может быть оправдано, однако такие комментарии как боковые колёсики на детском велосипеде, которые по мере роста надо снять.
Неинформативные комментарии вредны, потому что:
Комментарий не добавляет полезной информации и требует усилий по поддержке.
Требования комментировать каждую строку справедливо высмеяли на Reddit:
Второе правило: хорошие комментарии не оправдывают непонятный код
Ещё один способ некорректного использования комментариев — предоставление информации, которая должна содержаться в коде. Например, когда кто-то назвал переменную одной буквой и добавил комментарий с объяснением:
Комментарий был бы не нужен, если дать переменной правильное название:
Как написали Керниган и Плогер в книге «The Elements of Programming Style»: «Не комментируйте плохой код, а переписывайте его».
Третье правило: если не можете написать понятный комментарий, то проблема может быть в коде
Самый известный комментарий в исходном коде Unix звучит так: «Вряд ли вы это поймёте». Его вставили перед запутанным кодом переключения контекста. Дэннис Ричи позднее объяснил, что это был не наглый вызов, а высказывание в духе «На экзамене такого не будет». Но похоже, что он сам и его соавтор Кен Томпсон сами не поняли свой код, и позднее переписали его. Всё это напоминает о законе Кернигана:
Отладка вдвое труднее первоначального написания кода. Поэтому если вы пишете код как можно умнее, то вы по определению не настолько умны, чтобы его отладить.
Предупреждение читателям, чтобы они держались подальше от вашего кода, сродни включению аварийных огней: признание в том, что вы делаете что-то незаконное. Лучше перепишите код так, чтобы вы сами понимали его достаточно, чтобы объяснить другим. Или ещё лучше, чтобы его вообще не требовалось объяснять.
Четвёртое правило: комментарии должны исключать путаницу, а не вносить её
Ни одно обсуждение плохих комментариев нельзя считать полным без этой истории из «Hackers: Heroes of the Computer Revolution» Стивена Леви:
[Питер Самсон] особенно усложнял ситуацию тем, что отказывался добавлять в свой исходный код комментарии с пояснением, что он делает в каждом конкретном случае. Одна из распространённых программ, написанных Самсоном, состояла из сотен инструкций на ассемблере с единственным комментарием после инструкции под номером 1750. Комментарий был такой: RIPJSB, и люди ломали головы над тем, что это означает, пока кто-то не догадался, что в 1750-м году умер Бах, и что Самсон написал аббревиатуру фразы “Rest In Peace Johann Sebastian Bach”.
Хотя я ценю хороший хак, но это не пример для подражания. Если ваш комментарий вносит путаницу, а не устраняет, то удалите его.
Пятое правило: объясняйте в комментариях не идиоматический код
Лучше комментировать код, который кто-нибудь может счесть ненужным или избыточным, вроде этого кода из App Inventor (источника всех моих положительных примеров):
Без комментария кто-нибудь может «упростить» код или счесть его таинственным, но необходимым заклинанием. Сэкономьте время и нервы будущих читателей и напишите, для чего нужен этот код. Необходимо оценивать, нуждается ли код в объяснении. Когда я изучал Kotlin, я столкнулся в руководстве по Android с подобным кодом:
Я рекомендую не добавлять комментарии к распространённым идиомам, если только вы не пишете руководство для новичков.
Шестое правило: добавляйте ссылки на исходный код, который вы скопировали.
Если вы такой же, как и большинство программистов, то иногда вы используете найденный в сети код. Добавляйте ссылку на исходник, чтобы будущие читатели имели полный контекст, например:
Если перейти по ссылке, то вы обнаружите, что:
Любой, кто захочет разобраться в коде, вынужден будет искать эту формулу. А если бы вставили ссылку, то можно было бы гораздо быстрее найти источник.
Некоторые программисты могут не захотеть указывать, что они не сами написали код, но повторное использование кода может быть разумным шагом, экономящим время и дающим вам преимущество в виде большего количества проверяющих. Конечно, никогда не вставляйте код, который не понимаете. Люди копируют со StackOverflow много кода, который попадает под лицензирование Creative Commons, требующее указания авторства. Для этого достаточно указать ссылку на первоисточник.
Вы также можете ссылаться на оказавшиеся полезными руководства в качестве благодарности их авторам и ради экономии времени читателей:
Седьмое правило: добавляйте ссылки на внешние примеры в тех случаях, когда это полезнее всего
Конечно, не все ссылки ведут на Stack Overflow.
Ссылки на стандарты и другую документацию помогут читателям понять проблему, которую решает ваш код. Хотя эта информация может храниться в проектной документации, однако удачно размещённый комментарий станет своевременным указателем. В приведённом примере ссылка подсказывает, что RFC 4180 обновили на RFC 7111, это полезная информация.
Восьмое правило: исправляя баги, добавляйте комментарии
Комментарии следует добавлять не только при первичном написании кода, но и при его изменении, особенно при исправлении багов. Взгляните:
Комментарий не только помогает понять код в конкретных методах, но и определить, нужен ли ещё этот код и как его тестировать. Также комментарий может ссылаться на систему отслеживания ошибок:
Конечно, можно с помощью git blame найти коммит, в котором была добавлена или изменена строка. Однако пояснения к коммитам обычно краткие, и самые важные изменения (например, исправление бага №1425) могут не содержаться в последнем коммите (который, скажем, переместил метод из одного файла в другой).
Девятое правило: помечайте комментариями незаконченные реализации
Иногда необходимо проверять код, даже несмотря на его ограничения. Хотя может быть заманчиво не рассказывать о недостатках своего кода, лучше сделать это явно, например, в комментарии TODO:
Стандартный формат для таких комментариев помогает оценить и адресовать технический долг. Ещё лучше, если добавите задачу в систему отслеживания ошибок и вставите ссылку в комментарий.
Комментарии
Многие сегодня хотят стать программистами. Хотят. Но ничего не делают для этого. Не делают даже простых вещей. Не хотят даже прочитать книжку из 10 страниц. В итоге так и остаются никем. Потому что мечты не сбываются никогда. Сбываются только планы… Подробнее.
Вы наверняка уже знаете, что такое комментарии. Но, быть может, знаете об этом вы ещё не всё.
Зачем нужны комментарии?
Во-первых, в начале каждого модуля или программы программист обычно указывает автора, версию, дату создания и т.п.
Во-вторых, в больших программах довольно сложно ориентироваться. Поэтому комментарии в исходных текстах очень помогают разобраться с тем, где кончается один блок кода и начинается другой.
В-третьих, есть сложные алгоритмы, разобраться в которых без комментариев трудно не только другому человеку, но и самому автору через пару недель, а тем более лет.
Комментарии Free Pascal могут быть такими:
<Это комментарий в фигурных скобках>
(* И это тоже комментарий, но уже в круглых скобках со звёздочками *)
// А это комментарий в стиле С++
Как видите, Free Pascal поддерживает несколько видов комментариев. Последний пример – это комментарии в стиле С++ (в обычном Паскале такие комментарии не предусмотрены).
Комментарий в стиле С++ начинается двумя косыми чертами и продолжается до конца строки. То есть комментарии Паскаля открываются и закрываются скобками, а комментарий в стиле С++ открывается двумя косыми чертами и действует до конца строки. А это значит, что если вы используете комментарии в стиле С++, то в начале каждой строки с комментарием вам нужно ставить две косые черты.
В каком стиле писать комментарии – это личное дело каждого. Однако лучше привыкать писать их с первых шагов в изучении программирования. Очень часто бывает, что приходится отложить работу над программой на какой то срок, либо адаптировать старую программу к новым условиям. Вернувшись к своей программе через месяц, вы уже вряд ли будете помнить ход своих мыслей в момент работы над программой, и придётся заново разбираться с исходными кодами. В некоторых случаях бывает проще написать новую программу, чем разбираться с исходными кодами старой (особенно если она плохо документирована).
Что ещё нужно знать о комментариях?
Комментарии могут быть вложенными. Например,
Как видите, вложенный комментарий ничем не отличается от обычного комментария, за исключением того, что он находится внутри другого комментария
В классических компиляторах Паскаля (например, в Turbo Pascal и Delphi), тип вложенных комментариев ОБЯЗАТЕЛЬНО должен отличаться от типа комментария, в который вложен комментарий.
То есть такой комментарий
Вызовет ошибку во время компиляции.
Free Pascal допускает вложенные комментарии одинакового типа. Хотя при компиляции в таком случае будет выдано предупреждение. Однако не следует этим злоупотреблять, так как это плохо скажется на переносимости кода.
Кроме комментариев в фигурных скобках также могут быть директивы компилятора. Выглядят они примерно так:
То есть директива компилятора начинается со знака доллара. Поэтому никогда не начинайте свои комментарии со знака доллара. Это может привести к проблемам.
Ну и напоследок привожу текст программы с разными видами комментариев.
program comment; <$mode objfpc> <$H+>//Это директива компилятора uses <$IFDEF UNIX> <$IFDEF UseCThreads>//Это тоже директива cthreads, <$ENDIF> <$ENDIF>//Это тоже директива Classes < you can add units after this >; //Это комментарий begin //Это однострочный комментарий < Этот комментарий может занимать несколько строк>(* Это тоже многострочный комментарий *) < А вот так < делать нельзя в режиме Turbo Pascal и Delphi>потому что вложенные комментарии могут быть только разных видов > < Правильный (* Вложенный комментарий *) лучше делать так >end.
Создайте программу из листинга 17.1. Откомпилируйте её и убедитесь, что всё работает без ошибок.
В директиве компилятора, которая определяет режим компиляции, замените режим objfpc на режим tp или delphi. Попробуйте откомпилировать программу. Объясните, почему возникает ошибка во время компиляции.