Зачем комментировать исходный код и как это делать правильно

С чем связано такое неприятие комментариев?

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

“Комментарии — это не список Шиндлера. Не стоит относиться к ним, как к “абсолютному добру”.На самом деле комментарии в лучшем случае являются неизбежным злом”,— Роберт С. Мартин, “Чистый код: создание, анализ и рефакторинг. Библиотека программиста”.  

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

Плохие комментарии

Новички склонны использовать комментарии, чтобы объяснять, «что делает код». Например, так:

Но в хорошем коде количество «объясняющих» комментариев должно быть минимальным. Серьёзно, код должен быть таким, чтобы его можно было понять без комментариев.

Про это есть хорошее правило: «Если код настолько запутанный, что требует комментариев, то, может быть, его стоит переделать?»

Иногда выгодно заменить часть кода функцией, например, в таком случае:

Лучший вариант – использовать отдельную функцию :

Теперь код легче понять. Функция сама становится комментарием. Такой код называется самодокументированным.

И если мы имеем такой длинный кусок кода:

То будет лучше отрефакторить его с использованием функций:

Здесь комментарии тоже не нужны: функции сами говорят, что делают (если вы понимаете английский язык). И ещё, структура кода лучше, когда он разделён на части. Понятно, что делает каждая функция, что она принимает и что возвращает.

В реальности мы не можем полностью избежать «объясняющих» комментариев. Существуют сложные алгоритмы. И есть хитрые уловки для оптимизации. Но в целом мы должны стараться писать простой и самодокументированный код.

Комментарии в сложном коде и рефакторинг

В сложной и запутанной программе не обойтись без поясняющих комментариев. Но иногда лучше упростить сам код: разбить на отдельные функции, уменьшить размеры элементов, упростить циклы и так далее. А самим функциям, константам и переменным дать «говорящие» имена, объясняющие их назначение.

Например, есть метод, который сравнивает числа a и b. Если a > b, он возвращает true, a если a < b — false:

Весь этот громоздкий кусок кода можно значительно упростить, просто убрав блок if-else:

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

Форматирование

Длина строк

ЗаПротивВердикт

• комментарий при разделении потеряет в понятности или лёгкости копирования. Например, комментарий с примером команды или URL-ссылкой, длиннее 80 символов.
• строковый литерал/имя, длиной более 80 символов. Исключением является тестовый код, который желательно размещать в начале файла.
• выражения с include.
• Блокировка от повторного включения
• using декларации

Объявления и определения функций

• Выбирайте хорошие имена для параметров.
• Имя параметра можно опустить, если он не используется в определении функции.
• Если тип возвращаемого значения и имя функции не помещаются в одной строке, тип оставьте на одной строке, имя функции перенесите на следующую. В этом случае не делайте дополнительный отступ перед именем функции.
• Открывающая круглая скобка всегда находится на одной строке с именем функции.
• Не вставляйте пробелы между именем функции и открывающей круглой скобкой.
• Не вставляйте пробелы между круглыми скобками и параметрами.
• Открывающая фигурная скобка всегда в конце последней строки определения. Не переносите её на новую строку.
• Закрывающая фигурная скобка располагается либо на отдельной строке, либо на той же строке, где и открывающая скобка.
• Между закрывающей круглой скобкой и открывающей фигурной скобкой должен быть пробел.
• Старайтесь выравнивать все параметры.
• Стандартный отступ — 2 пробела.
• При переносе параметров на другую строку используйте отступ 4 пробела.

Ee

{}

ifelseпоследовательны

if

else

else

if

Циклы и switch-и

continuecaseswitchdefault

ABSL_FALLTHROUGH_INTENDED;absl/base/macros.hABSL_FALLTHROUGH_INTENDED;

continue

• ‘.’ и ‘->’ используются без пробелов.
• Операторы * или & не отделяются пробелами.

&&&&~andcompl

returnreturn expr;x = expr;

Инициализация переменных и массивов

=(){}=(){}

{…}std::initializer_liststd::initializer_listсписка в фигурных скобках{}std::initializer_list

#

Форматирование классов

publicprotectedprivate

• Имя базового класса пишется в той же строке, что и имя наследуемого класса (конечно, с учётом ограничения в 80 символов).
• Ключевые слова public:, protected:, и private: должны быть с отступом в 1 пробел.
• Перед каждым из этих ключевых слов должна быть пустая строка (за исключением первого упоминания). Также в маленьких классах пустые строки можно опустить.
• Не добавляйте пустую строку после этих ключевых слов.
• Секция public должна быть первой, за ней protected и в конце секция private.
• См. Порядок объявления для выстраивания деклараций в каждой из этих секций.

Шаблоны и приведение типов

• Пустая строка в начале или в конце функции не улучшит читабельность.
• Пустые строки в цепочке блоков if-else могут улучшить читабельность.
• Пустая строка перед строкой с комментарием обычно помогает читабельности кода — новый комментарий обычно предполагает завершение старой мысли и начало новой идеи. И пустая строка явно на это намекает.

Закомментировать код

Закомментировать код — это конвертировать одну или несколько строк кода в комментарии. Таким образом, вы можете (временно) исключить часть кода из компиляции.

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

Не закомментировано:

std::cout << 1;

1	std::cout<<1;

Закомментировано:

//    std::cout << 1;

1	//    std::cout << 1;

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

Не закомментировано:

std::cout << 1;
std::cout << 2;
std::cout << 3;

1 2 3

std::cout<<1; std::cout<<2; std::cout<<3;

Закомментировано символами однострочного комментария:

//    std::cout << 1;
//    std::cout << 2;
//    std::cout << 3;

1 2 3

//    std::cout << 1; //    std::cout << 2; //    std::cout << 3;

Закомментировано символами многострочного комментария:

/*
std::cout << 1;
std::cout << 2;
std::cout << 3;
*/

1 2 3 4 5

/*      std::cout << 1;      std::cout << 2;      std::cout << 3; */

Есть несколько причин, почему следует использовать «закомментирование»:

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

   Причина №2: Вы написали код, который компилируется, но работает не так, как нужно и сейчас у вас нет времени с этим возиться. Закомментируйте код, а затем, когда будет время, исправьте ошибки.

   Причина №3: Поиск корня ошибки. Если вас не устраивают результаты работы программы (или вообще происходит сбой), полезно будет поочерёдно «отключать» части вашего кода, чтобы понять какие из них рабочие, а какие — создают проблемы. Если вы закомментируете одну или несколько строчек кода и программа начнёт корректно работать (или пропадут сбои), шансы того, что последнее, что вы закомментировали, является ошибкой — очень велики. После этого вы сможете разобраться с тем, почему же этот код не работает так, как нужно.

   Причина №4: Тестирование нового кода. Вместо удаления старого кода, вы можете его закомментировать и оставить для справки, пока не будете уверены в том, что ваш новый код работает так, как нужно. Как только вы будете уверены в новом коде, то сможете без проблем удалить старые фрагменты кода. Если же новый код у вас будет работать не так, как нужно, то вы сможете его удалить и откатиться к старому коду.

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

Синтаксис комментариев

Комментарии в Python начинаются с хеша (символа #), после которого ставится пробел.

Общий вид комментария:

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

В простейшей программе «Hello, World!» комментарий может выглядеть так:

В цикле for, который итерирует списки, могут быть такие комментарии:

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

Для примера рассмотрим функцию again() из руководства Написание простейшего калькулятора в Python 3:

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

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

Блочные комментарии

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

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

Следующий блочный комментарий описывает действия функции main().

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

Хорошие комментарии

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

Юридические тонкости 

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

Волшебные выражения 

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

Объяснение намерения 

В некоторых ситуациях комментарий необходим для объяснения намерения, заложенного в каком-либо конкретном решении. Например, пояснение внутри набора тестов, позволяющее выявить прием, который был использован для снижения вероятности взаимной блокировки. 

Предупреждение о последствиях 

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

Комментарии TODO 

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

Комментарий может принять форму просьбы с пожеланием обратить внимание на какую-то проблему или придумать более подходящее имя.  

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

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

Переменные C#

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

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

• string — текстовая строка
• int — целое число (от -2 147 483 648 до 2 147 483 647)
• double — дробное число с плавающей запятой
• bool — логическое значение (истина/ложь)
• char — буквенный символ
• decimal — дробное число с фиксированной запятой
• byte — маленькое целое число (от 0 до 255)
• long — большое целое число (от 9 223 372 036 854 775 808 до 9 223 372 036 854 775 807)
• object — базовый тип всего языка

Стоить заметить, что это далеко не полный список всех типов данных. Здесь перечислены только самые часто используемые. Существуют также модифицированные типы данных, такие как uint, которые позволяют задать значения больше нуля, но большего диапазона (в данном случае будет от 0 до 65535). Или наоборот sbyte (от -128 до 127). Но давайте рассмотрим примеры.

Перечислим особенности переменных некоторых типов данных: для отделения дробной части от целой используется символ точки, а не запятой. Строки задаются только в двойных кавычках, а символы только в одинарных. Для типа данных decimal при не пустой дробной части обязательно использование постфикса M. Логический тип принимает одно из двух логических значений true — истина, false — ложь. Отрицательные числа задаться с помощью символа минус перед числом.

Нотации в языке C#

Одну из основных рекомендаций которую я могу дать, это всегда используйте понятные и лаконичные называния для переменных. Имя переменной всегда должно подробно и однозначно описывать собственное содержимое. Лучше всего вообще отказаться от использования односимвольных переменных в коде, иначе отладка ад. В Microsoft docs есть подробная статья о рекомендациях по именованию в языке, но если говорить очень коротко, то можно выделить три популярных стиля именования (нотация):

• Pascal casing — Все первые буквы в имени переменной пишутся с заглавными. Слова соединяются без разделителя.
• Camel casing — Первые слова в имени переменной пишутся с большой буквы, за исключением первого, который тоже пишется с маленькой. Слова соединяются без разделителя.
• Snake casing — Все буквы пишутся строчными. Слова соединяются через символ подчеркивания (_)

В соответствии для этого можно сделать следующие рекомендации:

Pascal для имен классов, свойств, конструкторов, методов, делегатов, событий.

Camel для локальных переменных, аргументов методов.

Snake вообще лучше не использовать. Или только для констант.

Как автоматизировать создание комментариев

В различных IDE есть возможность автоматизировать создание комментариев. Это делается с использованием тегов — дескрипторов, которые начинаются с символа @. Вот самые популярные:

• @author — идентифицирует автора исходного кода;
• @param — определяет параметр метода;
• @see — ссылка;
• @since — версия программного обеспечения;
• @return — тип возвращаемых процедурой или функцией данных.

Из таких комментариев автоматически формируется документация программы. Для этого используют генераторы документации, например, javadoc для языка Java, phpDocumentor для PHP, doxygen для C и C++, Epydoc для Pithon и другие.

Принцип работы прост. Генератор обрабатывает файл с исходным текстом, находит там имена классов, их членов, свойств, методов, процедур и функций, а затем связывает их с данными из наших комментариев с тегами. Из этой информации формируется документация в формате HTML, PDF, RTF или других.

При разработке библиотек и фреймворков обычно создается документация для API. Со временем она устаревает — в неё не успевают или просто забывают вносить изменения.

В различных языках и средах программирования

• 1С

  однострочный комментарий

• Ада

однострочный комментарий

Ассемблер

однострочный комментарий

Многострочный комментарий.

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

Бейсик

однострочный комментарий> — поддерживается не во всех диалектах

однострочный комментарий

BLITZ PLUS

однострочный комментарий

BAT-файлы и команды DOS

однострочный комментарий

однострочный комментарий

пакетный файл Linux, QNX

однострочный комментарий

C, C++, PHP, C#, Java и JavaScript

многострочный комментарий

однострочный комментарий

однострочный комментарий (для PHP)

Способ комментирования больших кусков кода в C/C++. Используется не для написания комментариев к программе, а для временного сокрытия части функциональности (в Java и JavaScript невозможен):

Кобол

 — однострочный комментарий

Delphi (Object Pascal)

однострочный комментарий

Форт

стандартный однострочный комментарий

Фортран

HTML, XML, XHTML, XAML, wiki-разметка

Конфигурационные (ini) файлы

неиспользуемый ключ либо другой комментарий

Файлы реестра Windows (REG)

неиспользуемый ключ либо другой комментарий

Система аналитических вычислений Mathematica

Система аналитических вычислений Maple

Pascal, Modula-2, Modula-3, Oberon и ML

Perl

однострочный комментарий

аналог многострочного комментария, используется для написания документации

PowerShell

однострочный комментарий

многострочный комментарий

Python, различные варианты командных оболочек UNIX, AWK, sed, Tcl

однострочный комментарий

PL/SQL

однострочный комментарий

Ruby

многострочный комментарий

однострочный комментарий

Smalltalk

TeX, LaTeX, PostScript

однострочный комментарий

Visual Basic

однострочный комментарий

однострочный комментарий

Lua

Комментирование кода перед тестированием

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

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

• Циклы while в Python 3
• Циклы for в Python 3

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

Как получить ответ на свой комментарий

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

Вконтакте тоже есть подобный раздел. Называется он Мои Ответы.

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

Как правило, в таких случаях после отправки появляется примерно такое уведомление:

Так что Ваше сообщение может быть вообще не опубликовано. Например, администратор счел его оскорбительным или бессмысленным.

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

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

Возьмем, к примеру, сайт, на котором Вы сейчас находитесь. На нем опубликовано около двухсот разных статей. Вы читаете одну из них. Ее адрес написан вверху браузера (программы для интернета).

Если Вы сейчас оставите на этой странице какое-нибудь сообщение, то оно будет опубликовано именно здесь. Значит, для получения ответа нужно будет снова зайти на этот адрес через какое-то время (лучше через день-два).

Другими словами, для поиска своего сообщения и ответа на него нужно будет вернуться на эту самую страницу.

Когда нужны пояснения в коде, а когда — нет

Бывает, что одних документирующих комментариев недостаточно и нужно добавить пояснения внутри процедур или функций. Такие комментарии облегчают понимание кода — рассказывают, почему автор программы сделал что-то так, а не иначе.

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

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

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

После отладки их лучше удалить, оставив строки:

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

Но бывают исключения. Допустим, разработчик попробовал несколько вариантов решения и выбрал один, не самый очевидный. Потом забыл ход своих мыслей, открыл код и решил использовать «более правильный и оптимальный вариант». И тут он понимает, что новое решение хуже старого; более того, раньше он уже это пробовал делать. Приходится откатывать всё назад. Чтобы не попасть в такую ситуацию, пишите поясняющие комментарии.

Пример на языке JavaScript:

Здесь и сам метод Number.isFinite (), и глобальная функция isFinite () проверяют, является ли параметр value конечным числом (то есть не ± ∞). Но если value = null, то isFinite (value) возвращает true, а Number.isFinite (value) возвращает false. Поэтому Number.isFinite (value) нельзя менять на isFinite (value).

Обязательно комментируйте код, если в нём есть какие-то тонкости и неочевидные вещи. Например:

Это неудачный комментарий: непонятно, зачем количество умножать на 2.

Правильно будет так:

Как находить примеры в тексте?

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

Примеры-иллюстрации в публицистическом тексте

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

Для этого нужно обратить внимание на:

• мнение известных людей по проблеме, если автор приводит такие мнения;
• события, факты или явления, описанные автором в ходе собственных рассуждений.

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

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

Например, в статье «Комментарий в сочинении по тексту В.П. Астафьева (№18)» дан образец комментария проблемы отношения к родному дому.

Из исходного текста выбраны два примера-иллюстрации: «два оставленных деревенскими жителями дома, в которых описан порядок в доме у хороших хозяев (предложения 10 — 13)» и «беспорядок в доме у плохих хозяев (предложения 20 — 26)».

Выявлена смысловая связь между примерами — противопоставление.

Оба примера подкрепляют позицию автора, которая прямо высказана в тексте, в 14-16 предложениях.

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

Примеры-иллюстрации в художественном тексте

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

Для этого нужно обратить внимание на:

Все примеры-иллюстрации, которые выпускник найдёт в тексте для понимания авторской позиции по проблеме, могут стать основой комментария по проблеме.

Из найденных в тексте примеров необходимо выбрать два основных, которые более ярко раскрывают сформулированную проблему, и написать пояснение к ним. (См. статью «Что такое проблема текста?«.

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

Например: в статье «Комментарий в сочинении по тексту К.Г. Паустовского (№22)» дан образец комментария проблемы истинной и ложной порядочности, проблема хамства.

Из исходного текста выбраны два примера-иллюстрации: «разговор профессора с женой (предложения 27 — 37)» и «описание поведения членов семьи профессора у двери своей квартиры, когда они ругают солдата-рассказчика (предложения 50 — 58)».

Выявлена смысловая связь между примерами — примеры дополняют друг друга в описании хамского поведения профессорской семьи.

Позицию автора мы можем понять, проанализировав поведение и речь героев.

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