Коды ошибок линтер

console.log('Hodor'

console.log(8/2+5 - -3 / 2); // => 10.5

console.log(((8 / 2) + 5) - (-3 / 2)); // => 10.5

console.log(70 * (3 + 4) / (8 + 2));

Открыть доступ

Наши выпускники работают в компаниях:

V. Внутренние языковые средства (SQL, хранимые процедуры, триггеры)

A. Язык запросов SQL

Язык SQL-ЛИНТЕР реализует международный стандарт языка SQL — ANSI/ISO SQL-92.

В SQL-ЛИНТЕР пользователь найдет такие мощные языковые средства, как предложение UNION, полный набор операций соединения — JOIN, все описанные в указанном стандарте возможности по реализации ограничений целостности и пр.

Для совместимости с некоторыми СУБД других производителей (Oracle, DB2, Informix, Microsoft SQL Server и др.) в язык запросов ЛИНТЕР введены специальные встроенные функции, языковая работа по управлению контролем доступа к информации, иерархические запросы к таблицам, последовательности и т.д.

Для удобства пользователей в SQL-ЛИНТЕР включены так же следующие расширения указанного стандарта:
1. Языковая работа с BLOB-столбцами.
2. Языковая работа с событиями в ЛИНТЕР.
3. Разрешено использование нескольких таблиц во FROM в операциях UPDATE и DELETE. Например,

   DELETE FROM таблица JOIN список_таблиц WHERE ...

   	UPDATE таблица JOIN список_таблиц WHERE ...

4. Разрешена конструкция INTO в SELECT-операторе для совместимости с некоторыми диалектами языка SQL. Например,

   	SELECT список_выражений INTO список_параметров FROM ...

5. Разрешена конструкция CAST NULL AS тип.
6. Введены следующие предложения для установки режимов работы каналов:
   SET TRANSACTION READ ONLY — перевод канала в режим read-only;
   SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED — перевод канала в режим грязного чтения.
7. Введены предложения для работы с правилами репликации:
   CREATE REPLICATION RULE правило FOR таблицa TO таблица ON NODE имя_узла USER пользователь PASSWORD ‘пароль’ [ENABLE |DISABLE];
   ALTER REPLICATION RULE правило [PASSWORD ‘пароль’] [ENABLE |DISABLE];
   DROP REPLICATION RULE правило;
8. Разнообразные возможности ALTER TABLE по модификации структуры таблицы – от изменения имен (таблицы, её столбцов) до изменений важнейших характеристик самой таблицы и её столбцов (например, размеров, числа файлов, места их расположения, а для столбцов – длины данных, значений по умолчанию и т.д.).

Ещё один немаловажный штрих – возможность поиска отдельных слов и словосочетаний в больших текстовых значениях, что очень важно при организации больших полнотекстовых информационных баз.

B. Язык хранимых процедур СУБД ЛИНТЕР

Наличие механизма хранимых процедур в СУБД ЛИНТЕР позволяет существенно расширить возможности языка SQL, организуя процедурную обработку данных на сервере согласно алгоритму пользователя.

По функциональной мощности хранимые процедуры ЛИНТЕР в некоторых аспектах даже превышают стандарт ANSI/ISO SQL-92/PSM (Persistent Stored Modules).

Есть множество важных моментов, не отраженных в стандарте, например:
• использование оттранслированных запросов и запросов с параметрами (динамически изменяемых запросов),
• управление транзакциями.

Хранимые процедуры ЛИНТЕР могут использовать как обычные, так и оттранслированные запросы с параметрами и без параметров, кроме того процедуры имеют возможность возвращать курсор, что очень удобно для программирования.

Язык хранимых процедур предоставляет мощный синтаксис выражений включающий все необходимые операции с переменными и значениями каждого типа данных, вызовы разнообразных стандартных функций (таких, как преобразование типов, работа со строчными данными и т.д.) операцию присваивания (тот факт, что присваивание является операцией, а не отдельным оператором, позволяет строить, например, такие конструкции: a := b := c := 0;).

Язык хранимых процедур позволяет работать со всеми стандартными типами данных ЛИНТЕР (Integer, Smallint, Char, Byte, Numeric, Real, Double, Date), а также дополнительным типом BOOL (логический). Тип CHAR рассматривается как строки с заданной максимальной длиной, и для него определены удобные в использовании строковые константы и операции конкатенации.

Все операции со всеми типами данных реализуют трехзначную логику, то есть поддерживается значение NULL для любого типа данных, которое означает состояние “значение не определено”.

Последовательность операторов позволяет закодировать линейный алгоритм. Для организации ветвящихся алгоритмов может использоваться оператор типа IF..ELSEIF…ELSEIF…ELSE..ENDIF, оператор выбора CASE, оператор перехода на метку GOTO. Циклические алгоритмы организуются при помощи оператора цикла WHILE.

Для вызова из одной процедуры других используется оператор CALL. Допустимы рекурсивные вызовы процедур.

Процедуры могут получать входные параметры и возвращать результат работы через механизм возвращаемого значения (оператор RETURN) и/или выходные параметры. Результатом работы процедуры может являться не только скалярное значение, но и курсор (выборка).

Для обработки результатов SELECT-запросов в процедурах используются курсоры (CURSOR), тип которых объявляется в соответствии со структурой ответа. Цикл работы с курсором может включать его открытие оператором OPEN (как результат запроса или выполнения другой процедуры), выборку данных оператором FETCH (в любом направлении) и закрытие (CLOSE) или, если процедура возвращает курсор, возврат (RETURN).

Процедуры могут работать со столбцами типа BLOB. Для этого используются стандартные функции чтения/записи в BLOB, который ассоциируется с текущей строкой курсора.

Понятие “курсор” используется исключительно для выборки данных. Для выполнения любых DML и DDL запросов (запросов отличных от SELECT-запроса) используется оператор EXECUTE.

Все операции процедур по модификации данных входят в пользовательскую транзакцию. Завершением транзакции управляет пользователь, однако, процедура также может зафиксировать или откатить изменения, сделанные в ее теле (и теле ее дочерних процедур) операторами COMMIT и ROLLBACK.

Для упрощения обработки ошибок в языке хранимых процедур предусмотрен механизм работы с исключительными ситуациями, в качестве которых могут рассматриваться ошибки выполнения SQL — запросов, ошибки времени исполнения (вызов несуществующей процедуры, деление на ноль и т.д.) или пользовательские исключения.

В момент возникновения исключения управление сразу автоматически передается на соответствующую ветку блока обработки исключений (EXCEPTIONS), что избавляет от необходимости “засорения” кода процедуры многочисленными условными операторами, проверяющими результат завершения каждого оператора. Процедура может обработать исключение, либо завершиться и передать исключение на верхний уровень (оператор RESIGNAL).

Для организации работы с хранимыми процедурами и триггерами СУБД ЛИНТЕР содержит транслятор хранимых процедур, преобразовывающий исходный текст процедуры/триггера в оттранслированный код, позволяющий быстро выполнять процедуру в исполняющей подсистеме.

Этот код хранится в специальной системной таблице $$$PROC, описания входных/выходных параметров процедур хранятся в таблице параметров $$$PRCD. Обе эти таблицы должны быть созданы перед началом работы с процедурами/триггерами (для триггеров так же необходимо наличие таблицы $$$TRIG).

В поле типа BLOB таблицы $$$PROC сохраняются оттранслированный код и исходный текст процедуры или триггера (последнее позволяет пользователю получать исходный текст в целях редактирования). Процедуры и триггеры создаются с помощью соответствующих запросов SQL типа CREATE/ALTER PROCEDURE, CREATE TRIGGER.

В случае ошибки в тексте процедуры/триггера возвращается специальный код ошибки ЛИНТЕР и интерактивные утилиты выдают подробную расшифровку в какой строке и какая ошибка произошла. В этом случае в таблице $$$PROC создается только одна запись, содержащая исходный текст, что в последствии позволяет пользователю получить его и исправить ошибки.

Возможно использование хранимых процедур как функций, расширяющих язык SQL.

Для запуска процедур используется запрос
EXECUTE <процедура>(<параметры>)
в котором указывается имя и параметры процедуры. При передаче параметров можно использовать механизм передачи значений по умолчанию, когда указывается не весь список, а лишь интересующие значения.

Разрешение сообщений линтера документации

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

Анатомия сообщения линтера документации

Это пример сообщения,выдаваемого линтером документации.

Линтерное сообщение документации содержит следующие элементы.Начиная с верхней строки:

• Серьезность.Один из этих значков указывает на серьезность сообщения:
• Сообщение правила стиля. Сообщение правила стиля в этом примере: Вы действительно имели в виду ‘sdfdsfsdfdfssd’? В нашем словаре его не было.
• Ссылка на стиль. Некоторые ссылки связаны с разделом руководства по стилю, в котором объясняется правило. Ссылка на стиль в этом примере: Vale(Angular.Angular_Spelling) .
• Расположение проблемного текста в документе определяется исходной строкой и столбцом как можно точнее. В некоторых сообщениях может не быть точного местоположения текста, вызвавшего сообщение. Расположение в этом примере: [Ln 8, Col 1] .
• Файл определения теста стиля, создавший сообщение, связанное с файлом. Определение теста стиля в этом примере: Angular_Spelling.yml[Ln 1, Col 1]: View rule .

Стратегии улучшения документации

Эти советы помогут вам улучшить документацию и удалить сообщения об ошибках в документации.

Обратитесь к руководствам по стилю

Инструмент lint проверяет стили,содержащиеся в этих руководствах по стилю.Большинство тестов стиля включают ссылки на соответствующие разделы этих документов для получения дополнительной информации.

• Руководство по стилю угловой документации
• Руководство по стилю документации для разработчиков Google

Не каждый стиль,упомянутый в руководствах по стилю,имеет тест.Руководства по стилю и тесты стиля могут меняться.

Разделяйте длинные предложения

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

Подумайте о том,чтобы перестроить длинное предложение и разбить отдельные идеи на отдельные предложения или пункты.

Используйте списки и таблицы

Предложения,содержащие списки,разделенные запятыми,могут быть более понятными,если представить их в виде маркированного списка или таблицы.

Рассмотрите возможность замены списка элементов в предложении,разделенных запятыми,на список буллитов,чтобы эти элементы списка было легче читать.

Используйте более распространенные слова

Короткие,более распространенные слова обычно читаются легче,чем длинные.Это не означает,что вы должны писать,обращаясь к аудитории.Технические документы все равно должны быть точными.Документацию по Angular читает множество людей по всему миру,поэтому следует использовать язык,понятный большинству людей.

Если вы считаете,что определенный термин необходим,даже если он был отмечен как необычный,постарайтесь включить краткое объяснение этого термина.Также попробуйте добавить некоторый контекст вокруг его первого упоминания.

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

Используйте меньше слов

Если вы можете убрать слово и не потерять смысл предложения,оставьте его.

Одним из распространенных мест,где удаление слов может помочь,является список примеров,состоящий более чем из двух или трех пунктов.Прежде чем поместить элементы в маркированный список,подумайте,может ли только один из них передать нужный смысл.Другим вариантом может быть замена списка элементов одним термином,который описывает все элементы вашего списка.

Подробнее о конкретных сообщениях линтера документации

Большинство сообщений по ссылке на документацию не требуют пояснений и содержат ссылку на дополнительную документацию.Некоторые сообщения определяют области,в которых документация может нуждаться в более тщательной проработке.Следующие типы сообщений часто встречаются в тех местах текста,которые следует пересмотреть и переписать,чтобы улучшить текст и убрать сообщение.

Слово too-wordy или должно быть заменено другим

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

Angular.WriteGood_TooWordy-Проверьте,сможете ли вы переписать предложение…

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

В следующей таблице приведены некоторые распространенные слова,обнаруживаемые этим типом сообщений,и более простые слова,которые можно попробовать вместо них.

WordList messages

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

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

Proselint messages

Тесты стиля Proselint проверяют наличие слов,которые являются жаргонными или могут быть оскорбительными для некоторых людей.

Перепишите текст,заменив жаргонные или оскорбительные выражения на более инклюзивные.

Starting a sentence сообщения предложения

Некоторые слова, такие как so и there is/are , не обязательны в начале предложения. Предложения, которые начинаются со слов, обозначенных этим сообщением, обычно можно сделать короче, проще и яснее, переписав их без этих окончаний.

Cliches

Клише следует заменить более буквальным текстом.

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

Если все остальное не помогает

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

Линтер документации проверяет только то содержимое,которое отображается как текст.Он не проверяет текст,отформатированный в виде кода.Одним из распространенных источников ложных проблем являются ссылки на код,которые не отформатированы как код.

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

При необходимости вы можете применить эти исключения к своему контенту.

1. General exception

   Общее исключение позволяет исключить указанный текст из всех проверок на ворсинки.

   Чтобы применить общее исключение, окружите текст, который вы не хотите, чтобы линтер тестировал, элементами comment HTML , показанными в этом примере.

   
   Text the linter does not check for any style problem.
   
   

   Не забудьте оставить пустую строку перед и после каждого комментария.

2. Style exception

   Исключение стиля позволяет исключить текст из отдельного теста стиля.

   Чтобы применить исключение стиля, окружите текст, который вы не хотите, чтобы линтер тестировал, этими элементами HTML- comment Между этими комментариями линтер игнорирует проверку стиля в комментарии, но по-прежнему проверяет все другие используемые стили.

   Замените Style.Rule в комментариях ссылкой на правило стиля из сообщения о проблеме, отображаемого в среде IDE. Например, представьте, что вы получили это сообщение о проблеме и хотите использовать слово, обозначенное как проблема.

   Did you really mean 
   Angular_Spelling.yml[Ln 1, Col 1]: View rule

   Style.Rule для этого сообщения — это текст в круглых скобках: Angular.Angular_Spelling данном случае Style.Rule Чтобы отключить этот тест стиля, используйте комментарии, показанные в этом примере. Angular.Angular_Spelling

   
   'inlines' does not display a problem because this text is not spell-checked.
   Remember that the linter does not check any spelling in this block of text.
   The linter continues to test all other style rules.
   
   

---

Angular

15.0

• Руководства для разработчиков Angular

  Как фреймворк для приложений,Angular включает в себя коллекцию хорошо интегрированных библиотек,которые охватывают широкий спектр возможностей.

• DevTools Overview

  Angular DevTools-это расширение для браузера,которое предоставляет возможности отладки и профилирования приложений.

• Руководство по стилю угловой документации

  Это руководство по стилю охватывает стандарты написания документации по Angular angular.io.

• Отображение части файла кода

  Чтобы включить фрагмент кода в образец файла, а не целиком, используйте атрибут региона <code-example>.

Термин linting применяется для обозначения процесса обнаружения ошибок в исходных файлах программ, скриптов или документов. Программа такого рода должна иметься в инструментарии каждого разработчика, так как с помощью таких программ можно обнаруживать ошибки в процессе написания кода. Популярный редактор кода Sublime Text не имеет встроенных возможностей для обнаружения ошибок; однако такую ситуацию легко исправить.

При помощи linting‘а можно обнаруживать небольшие ошибки кода “на лету”, в процессе написания этого кода — например, пропущенную точку с запятой в JavaScript-коде. Возможность обнаружения ошибок в редакторе Sublime Text осуществляется с помощью плагина SublimeLinter, который необходимо установить прежде всего.

Если в какой-либо строке кода этот редактор обнаружит ошибку, то данная строка будет подсвечена в gutter редактора Sublime. Более того, если поместить курсор мыши в строку с ошибкой, то в status bar редактора Sublime Text отобразится краткое описание ошибки, что поможет принять меры для ее правильного устранения.

Ниже представлен наглядный пример подсветки ошибок в Sublime Text с помощью плагина SublimeLinter:

Плагин SublimeLinter сам по себе не выполняет процесса “отлавливания” ошибок в коде, так как является всего-лишь фреймворком, основой для других плагинов (linter), каждый из которых создан для обнаружения ошибок в каком-то определенном языке — JavaScript, PHP, Ruby, Python, HTML, CSS и так далее.

SublimeLinter в Sublime Text

Как уже упоминалось ранее, плагин SublimeLinter является фреймворком, основой для более маленьких плагинов (linter), которые осуществляют непосредственный поиск синтаксических ошибок в программном коде.

Поэтому первоначально необходимо установить этот фреймворк (как плагин) в редактор Sublime Text и самый простой способ это сделать — воспользоваться менеджером пакетов Package Control. Для этого нажимаем сочетание клавиш Shift+Ctrl+P (Linux \ Windows) или Shift+Cmd+P (Mac OSX). В поле поиска вводим название устанавливаемого пакета — SublimeLinter. Далее — производим установку.

Теперь необходимо определиться с тем, в каких языках программирования необходимо “отлавливать” ошибки. Другими словами, на каких языках программирования вы пишете и в каких из них вам необходима поддержка SublimeLinter.

Допустим, это серверный язык PHP. Тогда для включения возможности обнаружения ошибок в Sublime Text необходимо установить плагин Sublime​Linter-php, так же через менеджер пакетов Package Control. Стоит оговориться, что дополнительной зависимостью этого плагина является язык PHP, который предустановлен в операционных системах Linux\MacOSX, но который необходимо заранее установить отдельно в операционной системе Windows.

Примером работы связки Sublime​Linter + Sublime​Linter-php в редакторе Sublime Text может послужить нижеследующее изображение:

Рассмотрим другой случай, когда в редакторе Sublime Text используется язык программирования JavaScript. Тогда для возможности отлавливания ошибок в JS-коде необходимо установить плагин Sublime​Linter-jshint. В этом случае вопрос зависимостей этого пакета выглядит несколько сложнее. Плагин Sublime​Linter-jshint основывает свою работу на JSHint, который необходимо установить в виде пакета под Node.js и устанавливается с помощью менеджера пакетов npm. Поэтому в операционной системе заранее должны быть установлены Node.js, npm и JSHint.

Примером работы плагина Sublime​Linter-jshint может послужить нижеследующее изображение:

Рассмотрим еще один случай, когда в редакторе Sublime Text используется язык таблиц каскадных стилей CSS (куда же без него?). Тогда необходимо доустановить в Sublime Text плагин Sublime​Linter-csslint.

Рассмотрение подобных плагинов (linter) можно продолжать еще долго. Поэтому ограничимся только тремя вышеприведенными. Стоит сказать, что для поиска какого-либо конкретного плагина (linter) удобно воспользоваться online-сервисом Package Control, в поисковой строке которого достаточно ввести начало названия искомого пакета, например, так — “SublimeLinter-“. Система автоматически выдаст список все плагинов под фреймворк SublimeLinter.

Как нетрудно заметить, окончание (суффикс) в названии каждого из плагинов является подсказкой, для поддержки какого языка был создан этот плагин. Например, для языка Ruby существует плагин Sublime​Linter-ruby, для препроцессора Haml имеется плагин Sublime​Linter-haml.

Также стоит сказать, что необходимо внимательно читать описание к каждому из тех плагинов, которые планируется установить, так как каждый из них имеет разные зависимости. Наглядный пример зависимостей у плагинов Sublime​Linter-php и Sublime​Linter-jshint был приведен выше.

Настройка SublimeLint

В плагине SublimeLint имеется большое количество настроек. Однако, с большинством из них не составит труда разобраться. Ниже приведено краткое описание некоторых из них.

Linting Modes

Эта настройка отвечает за поведение плагина SublimeLinter — когда плагин должен оповещать об обнаруженной ошибке в коде программы или документа.

• Background — это поведение по умолчанию плагина SublimeLinter. Сообщения об обнаруженных ошибках будут появляться по мере их обнаружения (другими словами — по мере написания строк кода) и будут обновляться каждый раз, когда будет производиться исправление обнаруженных ошибок. Такой режим может показаться излишне назойливым, так как иногда сообщение об ошибке может появиться прежде, чем будет дописана до конца инструкция, в которой вкралась ошибка.
• Load\Save — в этом случае сообщения об ошибках будут отображаться плагином только после сохранения или загрузки сохраненного документа.
• Save Only — сообщения об обнаруженных ошибках будут отображаться только при сохранении документа.
• Manual — ручной вызов проверки на ошибки, из командной панели редактора Sublime Text.

Лично я предпочитаю режим Load\Save, так как в этом случае плагин SublimeLinter не мешает работать с кодом до тех пор, пора не будет выполнено сохранение этого кода в файле. Режим Background может показаться излишне назойливым, так как сообщения об ошибках будут появляться постоянно, мешая работе.

Для того, чтобы изменить поведение плагина SublimeLinter через настройку Linting Modes, необходимо зайти в командную панель редактора Sublime Text с помощью сочетания клавиш (Shift+Ctrl+P или Shift+Cmd+P) и ввести в строке поиска следующее:

sublimelinter lint mode

… откроется выпадающий список со всеми настройками плагина SublimeLinter, из которого необходимо выбрать SublimeLinter: Choose Lint Mode:

Mark Style

Настройка Mark Style отвечает за внешний вид выделения ошибки в строке кода. Значением по умолчанию является outline. Но можно выбрать любое другое значение из предустановленных настроек.

В соответствии с официальной документацией SublimeLinter имеются несколько вариантов выделения ошибок в строке кода:

• fill
• outline
• solid underline
• squiggly underline
• stippled underline

Аналогично с режимом Linting Modes, режим Mark Style настраивается через командную панель редактора Sublime Text — Shift+Ctrl+P (Linux \ Windows) или Shift+Cmd+P (Mac OSX). В выпадающм списке нужно выбрать строку Sublime Linter: Choose Mark Style.

Ниже представлены скриншоты всех пяти режимов выделения ошибок в строке, чтобы можно было сравнить и выбрать наиболее подходящий вариант.

Fill

Outline

Solid Underline

Squiggly Underline

Stippled Underline

Gutter Themes

В дополнение к настройке выделения ошибок в строке кода, можно выполнить настройку иконок, который помещаются в области gutter редактора Sublime Text напротив строки с обнаруженной ошибкой. Такое выделение строки служит для большей информативности.

В плагине SublimeLinter имеется набор предустановленных иконок, наглядное изображение которых представлено ниже.

Blueberry – cross

Blueberry – round

Circle

Danish Royalty

Hands

Knob – simple

Knob – symbol

Koloria

ProjectIcons

Изменить настройки отображения иконок можно, зайдя в командную панель редактора Sublime Text и выбрав в выпадающем списке строку Sublime Linter: Choose Gutter Theme.

Заключение

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

Рассмотренные в этой статье возможности плагина SublimeLinter являются далеко не исчерпывающими. На официальной странице документации вы всегда найдете для себя что-то новое. Для этого нужно только периодически просматривать эту документацию.

---