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

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

Использовать будем си-подобный синтаксис, то есть подобный языку си, но не будем вникать в заголовочные файлы, указатели и другие особенности относительно низкоуровневых языков, перейдём на синтаксис более высокоуровневых языков, которые сделают рутинную работу за нас. А конкретно, будем использовать синтаксис языка Java. Добро пожаловать под кат.

Двоичная система счисления

Числа в двоичной системе счисления состоят всего из двух знаков. Нуля и единицы. 00000001 – число один. 00000010 – число два. 00000100 – число 4. Как вы можете заметить, когда единица смещается влево, число увеличивается в два раза. Чтобы получилось число 3, необходимо написать 00000011. Таким образом можно составить все необходимые числа. В данном примере мы использовали двоичное число с восемью знаками, иначе говоря число восьмиразрядное. Чем больше у числа разрядов, тем большее оно может вместить значение. Например, восьмиразрядное число вмещает максимальное значение 255, если считать ноль, тогда 256, а в программировании ноль считается всегда. Если увеличить разряд на один, получится девятиразрядное число и его вместимость увеличится в два раза, то есть станет 512. Но так в программировании никогда не делается и обычно каждая следующая разрядность увеличивается вдвое. Один разряд, потом 2 разряда, потом 4 разряда, потом 8 разрядов, потом 16 разрядов, потом 32 разряда и далее.

Шестнадцатеричная система счисления

Всё аналогично двоичной, только вместо нулей и единиц участвуют цифры от 0 до 15. 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F, где A – 10, B – 11, C – 12, D – 13, E – 14, F – 15.

Знак минус в программировании

Знак минус в двоичной системе счисления обозначается единицей в самом старшем разряде. Конечно же если число может быть минусовым (да, да, в программировании типы цифр бывают неминусовыми и включающим числа со знаком минус). 10000000 – число -1. Это не число -0, потому что минус нулей не бывает, то есть отрицательные числа смещаются влево на один. А вообще, в разных языках программирования может быть разное представление отрицательных чисел, но вам это знание вряд ли пригодится, поэтому пока что думайте, что всё так, как я объяснил.

Буквы и знаки

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

Типы данных

В программировании есть типы данных. Числовые, такие как 233, которые разобрали выше. Называются почти везде int, от слова integer. С плавающей запятой, такие как 198,76, называются почти везде float. У букв тип char, у строк тип String. Тип bool имеет два значения – истина (true) и ложь (false). У этого типа реализация в разных языках разная, но самая простая, когда ноль — значит ложь, а любое другое число истину. Нестандартные типы данных, такие как числа с фиксированной запятой, рассматривать не будем.

Применение

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

int value;

Это стандартное объявление примитивного типа.

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

value = 112;

Здесь мы присвоили переменной значение. В отличии от математики в программировании = значит взять значение справа и присвоить переменной слева. = — это знак/оператор присвоения.

Можно объединить объявление и присвоение, то есть сразу инициализировать переменную.

int value0 = 113;
char a = ‘a’;
String line = “line”;

Буквы выделяются одинарными кавычками, строки выделяются двойными кавычками. Числа типа int не выделяются.

float b = 3.14f;

К числам с плавающей запятой одинарной точности в конце добавляется f.

double c = 1.2;

К числам с плавающей запятой двойной точности ничего не добавляется.

Операторы

С помощью операторов можно складывать, вычитать и делать много других операций с переменными. Операторами являются +, -, *, / и другие. Да даже; является оператором, говорящим, что выражение завершено.

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

int a = 127;
int b = -12;
a + b;

получается значение. Но так как оно ни одной переменной не присваивается, оно исчезает. Чтобы присвоить значение переменной используется специальный оператор присвоения, который коротко описан выше.
Повторим ещё раз. Он берёт значение со своей правой стороны и присваивает его переменной в левой стороне. Это оператор =, и он не имеет ничего общего со знаком равно из математики.

int c = 12;
int d = 14;
int e = c + d;

Также у нас есть логические операторы, такие как < (меньше), > (больше), <= (меньше либо равно), == (равно), && (и), || (или) и другие.

Они сравнивают значения или выражения слева и справа, а после выдают истинность в виде типа bool, то есть true или false, и это значение также можно присвоить.

int f = 1;
int g = 4;
bool isTrue = g > f;

Оператор && (и) сравнивает два значения типа bool. Если слева true и справа true, тогда этот оператор возвращает значение true. В других случаях false.

Оператор || (или) возвращает истинность, если хоть одно значение истинно (true).

Комментарии

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

//Комментарий.
int maxCount;

Вторая строка уже не комментарий.

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

Операторы ветвления

Оператор ветвления if

if(a < 154) {
a = a + 1;
}

Если переменная a меньше 154, то есть выражение истинно, выполняет код в фигурных скобках, потом программа выполняется дальше. Код в фигурных скобках называется блоком кода. Он нужен для того, чтобы сказать программе, что этот код принадлежит оператору и именно его нужно выполнить.

Оператор ветвления if можно расширить.

if(isTrue && isFalse){
    b = b – 1;
    } else {
    b = b + 1
}

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

Оператор ветвления switch

switch(value){
    case 0:
        a = a + 1;
        break;
    case 1:
	a = a + b;
	break;
    case 6:
	b = b – a;
	b = b – 1;
	break;
    default:
	b = b + 1;
	break;
}

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

switch(value){
    case 0:
	a = a + 1;
        break;
    case 1:
	a = a + b;
	break;
}

Циклы

Цикл for

Циклы выполняют блок кода по кругу, пока определённое действие их не остановит.

for(int i = 32; i >=0; i = i – 1){
    a = b + c + d;
}

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

Цикл while

while(i > 3){
    i = i – 2;
}

Цикл while выполняется до тех пор, пока условие в круглых скобках истинно.

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

do{
    i = i – 2;
} while(false);

Область видимости

int a = 4;
{ 
    int b = 0;
    b = a + b;
}

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

Ключевые слова

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

Массивы

Массивы – это набор значений одного типа. Они удобны, когда нам нужно что-то перечислить.

int[] items = new int[7];

Так выглядит обычное объявление массива. Сначала указываем нужный тип. Потом ставим квадратные скобки, этим говорим языку программирования, что объявляем массив. Далее вписываем его имя. После знака присвоения вписываем выражение инициализации, то есть создания массива. Там мы видим новый оператор new, который используется при создании массива. Если сказать проще, мы создаём семь переменных типа int и присваиваем их нашему массиву под именем items.

Мы создали массив с семью элементами, но обращаться к первому начинаем с 0. Поэтому последний элемент будет под индексом 6. Не забывайте об этом смещении.

Обращение к элементу массива и присвоение его переменной выглядит так

int a = items[0];

Вход в программу

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

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

int addAndMultiplyByTwo(int a, int b){
    return (a + b) * 2;
}

А это простейший метод, который сейчас разберём. В круглых скобках указываются входные параметры. Можете их представить, как уже объявленные переменные в блоке кода, которым мы можем присвоить значения извне. Внутри фигурных скобок первый оператор, который мы видим, это return. Он берёт значение справа, которое получается из выражения, и передаёт его вовне. Тип передаваемого вовне значения должен быть таким же, как указанный перед именем метода, то есть int.

int g = 6;
int z = addAndMultiplyByTwo(7, g);

Так метод вызывается и результат его выполнения передаётся в переменную z.

class HelloWorld {
    public static void main(String args []) {
        System.out.println("Hello World");
    }
}

В этом примере сначала создаётся класс HelloWorld. Пока что думайте, что класс – это файл, в который мы записываем текст программы.

Далее идёт объявление метода main. По словам слева от его имени мы можем понять, что метод публичный (слово public), то есть мы можем вызвать его не только из этого класса, но и извне. По слову static мы можем понять, что метод статичный, то есть можно его вызвать без разных манипуляций, которые мы рассмотрим позже. Слово void говорит, что метод ничего не возвращает. В круглых скобках есть аргумент args[]. Этот аргумент является пустым массивом строк. Можно добавить забитый чем-то массив строк, но нам это не нужно, потому что использовать его мы не будем, а программа запустится и так.

Следующим мы видим вызов метода println, в параметр которого помещена строка Hello World. Перед ним мы видим перечисление через точки System.out. Если кратко, слово System означает, что метод println находится в классе System, а слово out – это выходной поток PrintStream, который нужен, чтобы выдать информацию вовне. В этом примере вовне — это консоль. Выходной поток out мы рассматривать не будем. Разбор потоков может вылиться в отдельную статью. Нам важно только знать, что out (объект класса PrintStream) находится в классе System, а метод println находится в объекте out. Все эти перечисления через точку просто указывают путь языку программированию к методу println, чтобы он знал откуда его вызывать.

Этот метод выводит строку Hello World в консоль и переводит курсор на новую строку. На этом программа заканчивается.

Компиляция и выполнение

Синтаксис простой программы мы рассмотрели, но не запустили её. Этим мы сейчас и займёмся.
Для начала скачайте JDK и установите его. Потом в переменных средах вашей операционной системы пропишите в переменной Path путь к папке bin вашего установленного JDK. Это нужно, чтобы операционная система могла найти из консоли программы JDK для компиляции и запуска. Теперь поместите текст программы в текстовый файл с именем HelloWorld. С именем HelloWorld, потому что имя файла и класса должны совпадать. Сохраните и измените расширение файла на java. Перейдите в консоли в папку с файлом и введите javac HelloWorld.java. Программа скомпилируется и поместится в файл HelloWorld.class. Чтобы запустить её напишите java HelloWorld. В выводе вы увидите Hello World. Что мы и хотели.

Импорт

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

import java.util.Random;

После слова import идёт название пакета java.util. Он назван так из-за назначения и, собственно, из-за папок java и util, в которых находится класс Random. Путь javautilRandom.class
Вместо java.util.Random можно вписать любой необходимый нам класс.

Классы и объекты. Статические и динамические реализации

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

Есть ещё множество способов, чтобы классы могли найти друг друга. Это пакеты, внешние библиотеки, внутрипакетное взаимодействие и другое. Здесь разбирать это не будем. Просто знайте, что есть специальные конструкции и ключевые слова, чтобы использовать эти механизмы.

class MyClass {
    public static void main(String [] args){
	
        AnotherClass object0 = new AnotherClass();
	
        System.out.println(object0.a);
        System.out.println(object0.addition(8, 10));
    }
}

public class AnotherClass{
    int a  = 9;
	
    int addition(int b, int c){
        return b + c;
    }
}

Разберём их. Начнём с класса AnotherClass. Перед его именем мы видим слово public, которое говорит, что класс публичный и его могут использовать другие классы. В нём мы создаём переменную a со значением 9 и метод addition. Можно сказать, что класс AnotherClass – это новый тип.

В классе MyClass мы создаём объект object0 класса AnotherClass. Это очень похоже на создание обычной переменной и также используется ключевое слово new, как при создании массива. Оператор new говорит языку программирования, что нужно создать копию этого класса в оперативной памяти. Мы можем создать множество копий и забить ими всю память. Далее мы передаём переменную a этого объекта в метод println. Dызываем динамические метод addition в параметре метода println. Метод addition вернёт результат, а метод println выведет его.

Динамический метод отличается от статического тем, что его можно вызвать только из объекта, загруженного в память. То есть для начала нужно создать объект. Статический метод можно вызывать напрямую из класса, то есть просто написав имя класса, поставить точку и через неё вызвать метод. Но у статических методов есть ограничения. Внутри их тела невозможно обращаться к динамическим переменным объекта класса, в котором находятся эти методы. Так как статический метод не загружается в оперативную память, в нём нельзя использовать переменные объекта, загруженные в неё.
Чтобы создать статический метод, перед его именем нужно написать static.

Конструкторы

class MyClass2 {
    public static void main(String [] args){
	
        AnotherClass2 object0 = new AnotherClass2();
        AnotherClass2 object1 = new AnotherClass2(6);
	
        System.out.println(object0.a);
        System.out.println(object0.a);
    }
}

public class AnotherClass2{
    public AnotherClass2(){
        a = 7;
    }

    public AnotherClass2(int x){
        a = x;
    }

    int a;
}

В этих классах почти всё идентично предыдущим, но создаётся два объекта класса AnotherClass2. object0 и object1. Но создаются они по-разному.

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

Перейдём к разбору конструкторов в классе MyClass2. В этом классе при создании объектов класса AnotherClass2 мы можем указать параметры в круглых скобках. Язык программирования выберет подходящий под параметры конструктор и проинициализирует объект подходящим образом. Так при создании объектов мы можем создать его разновидность нужную нам.

post scriptum

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

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

Правило 1. Следуйте стандартам оформления кода.

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

Например, в этом куске кода в соответствии со стандартом есть 12 ошибок:

for(i=0 ;i

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

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

Правило 2. Давайте наглядные имена.

Ограниченные медленными, неуклюжими телетайпами, программисты в древности использовали контракты для имён переменных и процедур, чтобы сэкономить время, стуки по клавишам, чернила и бумагу. Эта культура присутствует в некоторых сообществах ради сохранения обратной совместимости. Возьмите, например, ломающую язык функцию C wcscspn (wide character string complement span). Но такой подход неприменим в современном коде.

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

Гораздо важнее, чтобы вы долго и хорошо думали перед тем, как что-то назвать. Является ли имя точным? Имели ли вы в виду highestPrice или bestPrice? Достаточно ли специфично имя, дабы избежать его использования в других контекстах для схожих по смыслу объектов? Не лучше ли назвать метод getBestPrice заместо getBest? Подходит ли оно лучше других схожих имён? Если у вас есть метод ReadEventLog, вам не стоит называть другой NetErrorLogRead. Если вы называете функцию, описывает ли её название возвращаемое значение?

В заключение, несколько простых правил именования. Имена классов и типов должны быть существительными. Название метода должно содержать глагол. Если метод определяет, является ли какая-то информация об объекте истинной или ложной, его имя должно начинаться с «is». Методы, которые возвращают свойства объектов, должны начинаться с «get», а устанавливающие значения свойств — «set».

Правило 3. Комментируйте и документируйте.

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

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

Правило 4. Не повторяйтесь.

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

• Создание справочников API из комментариев, используя Javadoc и Doxygen.
• Автоматическая генерация Unit-тестов на основе аннотаций или соглашений об именовании.
• Генерация PDF и HTML из одного размеченного источника.
• Получение структуры классов из базы данных (или наоборот).

Правило 5. Проверяйте на ошибки и реагируйте на них.

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

Правило 6. Разделяйте код на короткие, обособленные части.

Каждый метод, функция или блок кода должн умещаться в обычном экранном окне (25-50 строк). Если получилось длиннее, разделите на более короткие куски. Даже внутри метода разделяйте длинный код на блоки, суть которых вы можете описать в комментарии в начале каждого блока.

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

Правило 7. Используйте API фреймворков и сторонние библиотеки.

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

Правило 8. Не переусердствуйте с проектированием.

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

Правило 9. Будьте последовательны.

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

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

Правило 10. Избегайте проблем с безопасностью.

Современный код редко работает изолированно. У него есть неизбежный риск стать мишенью атак. Они необязательно должны приходить из интернета; атака может происходить через входные данные вашего приложения. В зависимости от вашего языка программирования и предметной области, вам возможно стоит побеспокоиться о переполнении буфера, кросс-сайтовых сценариях, SQL-инъекциях и прочих подобных проблемах. Изучите эти проблемы, и избегайте их в коде. Это не сложно.

Правило 11. Используйте эффективные структуры данных и алгоритмы.

Простой код часто легче сопровождать, чем такой же, но изменённый ради эффективности. К счастью, вы можете совмещать сопровождаемость и эффективность, используя структуры данных и алгоритмы, которые даёт ваш фреймворк. Используйте map, set, vector и алгоритмы, которые работают с ними. Благодаря этому ваш код станет чище, быстрее, более масштабируемым и более экономным с памятью. Например, если вы сохраните тысячу значений в отсортированном множестве, то операция пересечения найдёт общие элементы с другим множеством за такое же число операций, а не за миллион сравнений.

Правило 12. Используйте Unit-тесты.

Сложность современного ПО делает его установку дороже, а тестирование труднее. Продуктивным подходом будет сопровождение каждого куска кода тестами, которые проверяют корректность его работы. Этот подход упрощает отладку, т.к. он позволяет обнаружить ошибки раньше. Unit-тестирование необходимо, когда вы программируете на языках с динамической типизацией, как Python и JavaScript, потому что они отлавливают любые ошибки только на этапе исполнения, в то время как языки со статической типизацией наподобие Java, C# и C++ могут поймать часть из них во время компиляции. Unit-тестирование также позволяет рефакторить код уверенно. Вы можете использовать XUnit для упрощения написания тестов и автоматизации их запуска.

Правило 13. Сохраняйте код портируемым.

Если у вас нет особой причины, не используйте функциональность, доступную только на определённой платформе. Не полагайтесь на то, что определённые типы данных (как integer, указатели и временные метки) будут иметь конкретную длину (например, 32 бита), потому что этот параметр отличается на разных платформах. Храните сообщения программы отдельно от кода и на зашивайте параметры, соответствующие определённой культуре (например, разделители дробной и целой части или формат даты). Соглашения нужны для того, чтобы код мог запускаться в разных странах, так что сделайте локализацию настолько безболезненной, насколько это возможно.

Правило 14. Делайте свой код собираемым.

Простая команда должна собирать ваш код в форму, готовую к распространению. Команда должна позволять вам быстро выполнять сборку и запускать необходимые тесты. Для достижения этой цели используйте средства автоматической сборки наподобие Make, Apache Maven, или Ant. В идеале, вы должны установить интеграционную систему, которая будет проверять, собирать и тестировать ваш код при любом изменении.

Правило 15. Размещайте всё в системе контроля версий.

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

Заключение.

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

_{Перевод статьи «15 Rules for Writing Quality Code»}

Не волнуйтесь, если что-то не работает. Если бы всё работало, вас бы уволили.

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

Факты о программировании

Вот некоторые неочевидные факты о программировании:

• Только 10-20% времени тратится на кодирование
• Большая часть времени тратится на размышления
• Существенная часть времени тратится на отладку
• В день пишутся лишь десятки строк кода, которые пойдут в конечный продукт

Действительно, профессиональные разработчики тратят лишь 10-20% времени непосредственно на написание кода. Сравним, как выглядит работа программиста в реальной жизни с тем, как она обычно представляется в кино. В фильмах программисты постоянно набирают что-то на клавиатуре, но в обычной жизни вы скорее увидите человека, который чешет голову и задумчиво смотрит в экран, записи или вообще в пустоту. Зачастую тот код, который пишет программист, не является конечным. Он может постоянно его дорабатывать, переписывать, и в конечном итоге в день будет написаны несколько десятков строк готового кода, которые пойдут в конечный продукт.

Рассмотрим график, который показывает распределение рабочего времени в зависимости от уровня программиста: от начинающего до профессионального.

Ось Х отражает уровень программиста, а ось Y — его рабочий день. Видно, что есть очень сильная корелляция между уровнем разработчика и тем, на что уходит его рабочее время. Когда человек только начинает учиться программированию, то большую часть времени занимает именно процесс кодинга и отладки. Причем на отладку будет уходить даже больше времени, нежели указано на графике — не менее 90%. Отладка — это процесс поиска ошибок в коде. Именно количество времени, которое уходит на отладку, является одним из показателей уровня программиста. Помимо отладки новичок много занимается и кодингом, потому что ему нужно набивать руку. Кодинг можно сравнить с любым ремеслом, даже боевым искусством. Это такой процесс, который в конечном итоге, когда вы становитесь профессионалом достаточно серьёзного уровня, автоматизируется и становится просто способом реализации того, что вы придумали. И для ремесленника, и для художника, и для программиста первоочередная и самая сложная задача — это создать идею, продумать, что она в себя будет включать и как её воплотить в жизнь. А сам процесс воплощения обычно протекает гораздо проще.

Из чего состоят языки

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

Лексика

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

Синтаксис

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

Семантика

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

Чем на самом деле является язык программирования

Языки программирования существуют в 2 формах:

• Стандарт языка
• Реализация стандарта

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

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

Разобраться в разнице между стандартом языка и его реализацией можно на примере популярнейшего языка программирования JavaScript, который используется абсолютно везде и часто идёт вторым языком почти в каждом проекте, особенно в веб-разработке. Есть стандарт ECMA-262 или ECMAScript, а есть язык JavaScript, который является его реализацией. Существует несколько реализаций ECMAScript, среди которых TypeScript и JScript, которые написаны Microsoft, ActionScript от Macromedia (Adobe) и другие. При этом сам язык JavaScript остаётся такой же реализацией, которая имеет несколько сред исполнения.

Одной из таких сред является браузер. Есть несколько разных браузеров, у каждого из которых своя реализация JavaScript. Существует еще серверная, бэкенд-реализация — она называется NodeJS — которая позволяет исполнять тот же самый JavaScript. Некоторые теряются и не понимают разницы между JavaScript и NodeJS, выбирая, что же из этого им нужно учить. На самом деле, выбор здесь прост: в первую очередь надо осваивать JavaSсript, как самую популярную реализацию стандарта ECMAScript, и только после этого погружаться в специфики сред исполнения. Примерно такая же ситуация с другими языками.

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

Заблуждение

Знание синтаксиса языка программирования и семантики и есть программирование?

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

---

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

Программисты в первую очередь работают с языком. Поэтому написание программ похоже на любой другой вид письменной работы. Сначала вы излагаете свои мысли как есть, а затем «причесываете» до тех пор, пока текст не будет легко читаться. Качество кода – результат проявления небезразличного отношения к делу и показатель профессионализма.

Почему важна читаемость кода

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

«Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете», — Джон Вуд в доске обсуждений по C++, 1991 г.

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

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

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

С чего начать: документация по стилю оформления кода

Все дороги программиста ведут к документации. В каждом языке существует свой стандарт оформления кода. Для Python используется документ PEP-8, для PHP – стандартные рекомендации PSR-1 и PSR-2, для Java – Java Coding Conventions, для JavaScript – Airbnb JavaScript Style Guide или Google JavaScript Style Guide. Документ для вашего языка вы найдете по поисковому запросу <Название языка> Code Style.

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

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

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

Роберт Мартин «Чистый код. Создание, анализ и рефакторинг»

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

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

Главное правило чистого кода: выразительные имена

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

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

Сравните. До:

public List < int[] > getThem() {
 List < int[] > list1 = new ArrayList < int[] > ();
 for (int[] x: theList)
  if (x[0] == 4)
   list1.add(x);
 return list1;
}

После:

public List < int[] > getFlaggedCells() {
 List < int[] > flaggedCells = new ArrayList < int[] > ();
 for (int[] cell: gameBoard)
  if (cell[STATUS_VALUE] == FLAGGED)
   flaggedCells.add(cell);
 return flaggedCells;
}

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

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

Остерегайтесь малозаметных различий – имена объектов должны существенно отличаться друг от друга. По этой причине плохи длинные имена с повторяющимся элементами – чтобы сличить их друг с другом, тратятся лишние силы и время. Избегайте использования в именах переменных строчной буквы L и прописных I, O – они часто путаются с единицей и нулем.

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

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

Имя должно быть удобным для поиска. Слишком короткие имена трудно искать в большом объеме текста. Однобуквенные имена можно использовать только для локальных переменных в коротких методах и счетчиков циклов (i, j, k). Обычно называя объект одной буквой, вы всего лишь создаете временный заменитель. Но не бывает ничего более постоянного, чем что-то «временное». Проверяйте грамотность написания выбранных слов.

Правильно выбирайте часть речи. Классы и объекты желательно называть существительными и их комбинациями: Account, WikiPage, HTMLParser. Имена функций и методов лучше представлять глаголами или глагольными словосочетаниями: delete_page, writeField(name). Для методов чтения/записи и предикатов используйте стандартные префиксы get, set, is.

Заменяйте «магические» числа именованными константами. Одно из самых древних правил разработки. Магическими называют числа, о которых сходу нельзя сказать, что они означают. Например: 100, 1.1, 42, 1000000. Выделяйте такие числа в соответствующие константы с конкретным названиями. Например, вместо числа 86400 в теле кода приятнее встретить константу SECONDS_PER_DAY.

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

Одно слово для каждой концепции. Для одной и той же идеи, реализующей одну механику, используйте одно слово. Например, для добавления элементов одинаковым образом – метод add. Однако, если механика и семантика изменились, потребуется и другое слово (например, insert, append), описывающее новую концепцию.

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

Помещайте имена в соответствующий контекст. Например, имена street, house_number, city понятнее смотрятся внутри класса Address.

Избегайте остроумия и каламбуров в названиях. Шутки имеют свойство быть понятными лишь ограниченное время и для конкретной аудитории, знакомой с первоисточником. Отдавайте предпочтение ясности перед развлекательностью. Шутки можно приберечь для презентации, которая происходит «здесь и сейчас». Хороший код способен выйти далеко за границы вашей культуры.

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

Функции

Компактность. Уже в 80-е годы считалось, что функция должна занимать не более одного экрана. Экраны VT100 тогда состояли из 24 строк и 80 столбцов. В наши дни на экране можно разместить гораздо больше инорфмации, но лучше ограничиться тем же объемом. Самоограничение позволяет видеть точку объявления каждой используемой переменной и держать в уме всю «историю», которую рассказывает функция.

Вполне вероятно, что тот, кто будет сопровождать ваш код, не будет иметь возможности работать на большом мониторе. Например, ему необходимо одновременно разместить на одном рабочем столе экрана ноутбука несколько окон. Среды разработки позволяют установить ограничение, «верхнюю планку» (то есть правую 😉 ).

Блоки if, else, while должны иметь минимальный размер, чтобы информацию о них можно было держать в уме. Старайтесь избегать отрицательных условий – на их восприятие обычно уходит чуть больше времени, чем на положительные. То есть запись if (buffer.shouldCompact()) предпочтительнее записи if (!buffer.shouldNotCompact().

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

Функция должна выполнять только одну операцию, выполнять ее хорошо, и ничего другого она делать не должна.

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

«Я люблю, чтобы мой код был элегантным и эффективным. Логика должны быть достаточно прямолинейной, чтобы ошибкам было трудно спрятаться; зависимости — минимальными, чтобы упростить сопровождение; обработка ошибок — полной в соответствии с выработанной стратегией; а производительность — близкой к оптимальной, чтобы не искушать людей загрязнять код беспринципными оптимизациями. Чистый код хорошо решает одну задачу», — Бьёрн Страуструп, создатель языка С++

Исключения вместо кодов ошибок. Используйте исключения (try-catch, try-except) вместо возвращения кодов ошибок. Возвращение кодов приводит к слишком глубокой вложенности.

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

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

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

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

Комментарии

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

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

Однако есть несколько видов комментариев, которые выглядят достаточно оправданными.

TODO-комментарии. Бывает так: нужно было успеть к дедлайну, пришлось писать код быстро, поэтому в нем остались дыры. То есть всё работает, но реализация ущербная. Укажите все недоработки и создайте под них задачи. Каждый комментарий указывает на недоработку или потенциальную уязвимость.

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

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

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

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

По-настоящему плохие комментарии

Бывают такие типы комментариев, которые лучше никогда не делать.

Закомментированный программный код. «Когда-нибудь в будущем расскомментирую этот код, приведу всё в порядок. Или вдруг эта идея кому-то поможет». Любой закомментированный код только ухудшает ситуацию. Все изменения хранятся в контроле версий – удаляйте такой код на корню. Это просто мусор: «потом» равносильно «никогда». Если что-то действительно нужно сделать, создайте краткий TODO-комментарий и задачу.

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

Избыточные комментарии. Задайте себе вопрос: стал ли код понятнее после прочтения комментария? Часто комментарии просто загромождают код и скрывают его смысл, излагая очевидные вещи. Иногда в комментарии включаются описания не относящихся к делу подробностей. Но профессионал бережет не только свое, но и чужое время, и не отвлекает читающего без повода.

Журнальные комментарии и ссылки на авторов. Некоторые программисты добавляют комментарий в начало файла при редактировании. Или указывают, кто и когда внес исправления. Когда-то это было оправдано, но теперь у нас есть системы контроля версий – это гораздо лучший способ обозначить границы зоны ответственности каждого.

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

// Классы //////////////////////////////////

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

Уровень файлов программ

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

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

Отдельные «мысли» следует отделять друг от друга пустыми строками. Каждая пустая строка – зрительная подсказка: описание одной концепции закончилось, далее следует новая. При просмотре кода взгляд концентрируется на первых строчках – в них больше всего информации, как в началах абзацев этого текста.

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

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

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

Некоторые замечания по поводу архитектуры и тестов

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

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

1. Не пишете код продукта, пока не напишете отказной модульный тест.
2. Не пишите модульный тест в объеме большем, чем необходимо для отказа.
3. Не пишите код продукта в объеме большем, чем необходимо для прохождения текущего отказного теста.

F.I.R.S.T. Качественные тесты должны обладать пятью характеристиками, первые буквы которых образуют указанный акроним:

• Fast. Тесты должны выполняться быстро.
• Independent. Тесты не должны зависеть друг от друга и выполняться в любом порядке.
• Repeatable. Тесты должны давать воспроизводимые в любой среде результаты.
• Self-validating. Результат выполнения теста – логический признак: тест пройден или нет. Иначе результаты приобретают субъективный характер.
• Timely. Тест должен создаваться своевременно. Тесты нужно писать непосредственно перед написанием кода.

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

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

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

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

Заключение

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

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

zaidi razak / Shutterstock

Фулстек-разработчик. Любимый стек: Java + Angular, но в хорошей компании готова писать хоть на языке Ада.

---

об авторе

Разработчик ПО. Увлечён искусственным интеллектом и компьютерным зрением.

---

---

Вы слышали про объектную гимнастику (Object Calisthenics)? Если нет, то вам точно стоит её освоить! Тем более что это всего-то девять правил.

Я рассказывал о них многим разработчикам, и все они реагировали схоже. Сначала думали, что это шутка: «Как вообще можно хоть какой-то код написать по этим правилам?» Но, поприменяв их, обычно соглашались, что код и правда становится чище — причём почти мгновенно.

Понятие «объектная гимнастика» ввёл Джефф Бэй (Jeff Bay) в своей книге «The ThoughtWorks Anthology» (на русском не издавалась. — Пер.). Так он назвал группу упражнений на объектно-ориентированное программирование.

Применяя объектную гимнастику, можно сделать код:

• читабельнее;
• удобнее:

       • для отладки,

       • тестирования,

       • повторного использования

       • и сопровождения.

Считайте это упражнением. Вам нужно научиться выполнять эти правила при кодинге. А вот в повседневном программировании какими-то из них всегда можно пожертвовать — если следовать им слишком сложно или результат того не стоит.

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

То есть одно значение отступа на весь метод. Так его легче будет читать.

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

• выполняется принцип единственной ответственности (SRP);
• имена становятся понятнее,
• методы — короче, 
• и их удобнее использовать повторно.

Вложенные условия усложняют код, делают его нелинейным.

Мы решили слегка отойти от оригинальной статьи и добавили пояснения к каждому способу. — Пер.

• Использовать значения по умолчанию.

Например, ваша программа работает с объектами-фруктами: яблоками и грушами. По конвейеру движутся коробки с фруктами. Некоторые коробки подписаны, некоторые — нет. Если коробка не подписана, то вы считаете, что в ней лежат яблоки, — ну, так договорились.

В этом случае вы можете написать что-то вроде:

если коробка подписана, считать, что внутри те фрукты, которые указаны на коробке

иначе считать, что там яблоки

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

• Практиковать ранний возврат из метода.

Этот способ подойдёт для тривиального случая. 

Вместо:

если условие1 выполняй действие1

иначе выполняй действие2

можно написать:

если условие1 выполняй действие1 и вернись

а ниже внутри того же метода расположить обработку второго условия — ведь исполнение дойдёт до него, только если не сработает условие1.

• Выносить ветвления кода в отдельные методы.

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

• Применить полиморфизм.

Полиморфизм — один из столпов ООП. Благодаря ему один и тот же метод может по-разному реализовываться в иерархии классов.

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

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

• Задействовать шаблон проектирования «Состояние».

Шаблон проектирования «Состояние» полезен, когда в зависимости от состояния системы одно и то же действие (переход к следующему этапу) должно обрабатываться по-разному.

Например, кофейный автомат сначала ждёт выбора напитка, потом оплаты, а только после этого готовит кофе.

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

• Применить шаблон проектирования «Стратегия».

Шаблон проектирования «Стратегия» определяет семейство схожих алгоритмов и помещает каждый из них в отдельный класс.

В вызывающем классе хранится ссылка на стратегию, которую сейчас нужно использовать. Так что вместо множества проверок типа «если…, то…» вызывается один метод класса-стратегии.

• код не дублируется,
• становится проще
• и читается легче.

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

А ещё такой код легче воспринимать, ведь по сигнатуре объекта-обёртки сразу ясно, что передавать методу в качестве параметров.

Примечание переводчика

В оригинальной книге правило звучит так: «оборачивайте примитивы и строки».

Например, если метод принимает параметр типа int, это мало о чём говорит. Другое дело, если тип параметра будет, скажем, Hour. Мы оборачиваем целое число (часов) в класс. В тот же класс можно добавить проверку допустимых значений, и тогда никто не сможет передать в метод 36 или другое неподходящее число.

• Соблюдается инкапсуляция.
• Появляются подсказки для типов.
• Можно изолировать схожее поведение в отдельных методах и использовать их повторно.

Это следствие закона Деметры: «Общайся только с друзьями» (речь об общении между классами с помощью вызова методов друг друга. — Пер.).

Точку вы используете для вызова методов в Java или С#. Вызовы типа object.getProperty().getSubProperty().doSomething() — это очень плохая практика! Классы не должны знать так много деталей реализации других классов.

• Соблюдается инкапсуляция.
• Выполняется принцип открытости/закрытости.

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

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

Поразмыслили? А теперь не сокращайте наименования!

• Соблюдается SRP.
• Вы избегаете путаницы.
• Нет дублирования кода.

Делайте их небольшими:

• 15–20 строк на метод,
• 50 строк на класс,
• 10 классов на пакет.

В конце концов, если ваш класс специализируется на чём-то одном, он не должен быть большим, верно?

• Соблюдается SRP.
• Модули уменьшаются.
• Код становится хорошо согласованным (coherent).

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

Примечание переводчика

Переменная экземпляра (instance variable, атрибут) — переменная, которая хранит свойство объекта — экземпляра класса. Этим она отличается от статической переменной (относится к классу, а не к его экземпляру) и от локальной переменной, которая объявляется в членах класса — например, в методах.

Кажется, это требование очень сложно выполнить. Уверен, вы видели классы с десятками параметров в конструкторе, так ведь?

Отлично! Почему бы не сгруппировать их в один объект? Или ещё раз хорошенько подумать о том, точно ли у этого класса идеальная архитектура и не делает ли он слишком много лишнего.

• В модулях поддерживается сильная связность (high cohesion).
• Соблюдается инкапсуляция.
• Становится меньше зависимостей между различными сущностями программы.

Это похоже на правило №3, только применительно к коллекциям.

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

Примечание переводчика

В книге The ThoughtWorks Anthology автор акцентирует внимание на том, что в таком классе — обёртке над коллекцией вообще не должно быть других членов, кроме этой коллекции. Зато туда можно добавить методы фильтрации или добавления/удаления элементов.

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

Не принимайте решений вне класса, позвольте ему самому заниматься своим делом. Иными словами, следуйте принципу «Рассказывай, а не спрашивай».

• Соблюдается принцип открытости/закрытости.

Теперь вы знаете всё! Следовать этим принципам сперва будет сложно. Появится искушение всё бросить. Но воспринимайте это как вызов себе — соберитесь и упражняйтесь (никаких оправданий!).

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

---

Об этой статье

Была ли эта статья полезной?

Глеб Летушов, редактор-фрилансер, написал статью специально для блога Нетологии о том, как правильно оформлять программный код. Статья для конкурса блога.

Один из важных моментов в разработке — качественное написание кода. С правильным оформлением удобно работать, потому что тратишь меньше времени на чтение и понимание кода.

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

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

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

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

     var browser = prompt(«ваш браузер», «»);

          if  (browser==»Сhrome»

             || browser==»Firefox»

             || browser==»Safari»

             || browser==»Opera») {

          alert( ‘Хороший браузер’ );

     }

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

function checkNumber(Number) {

     if (Number > 33) {

          return true;

     } else {

          return confirm(‘Номер маленький’);

     }

}

Восемь-девять строк подряд делают код менее читаемым, поэтому различные части лучше отделять помощью отступов.

Не превышайте оптимальную длину строки

Максимальная длина строки — 80 символов. Если их больше, то читать и понимать код становится тяжелее.

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

Правильно используйте фигурные скобки

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

• Ставить скобки сразу после кода:

var password = prompt («Введите Ваш пароль», «отмена»);

     if (pass == «qwerty»)  {

          alert («Успешная авторизация»);

     } else if (prompt == null) {

          alert («Авторизация не удалась»);

     } else {

          alert («Пароль неверный»);}

}

• Ставить скобки параллельно друг с другом:

var password = prompt («Введите Ваш пароль», «отмена»);

     if (pass == «qwerty»)

     {

          alert («Успешная авторизация»);

     }

     else if (prompt == null)

     {

          alert («Авторизация не удалась»); 

     }

     else

     {

          alert («Пароль неверный»);

     }

}

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

Называйте переменные и функции на английском

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

Правильно:

var password

var UserName

function Sum()

function Send()

Неправильно:

var parol

var ImyaPolzovatelja

function Summa()

function Otpravka()

Названия, написанные транслитом, будут вносить путанницу в код. Одно и то же слово можно по-разному написать транслитом: ssilka, ssylka.

Составляйте названия из несколько слов

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

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

• Новое слово пишется слитно с предыдущим и начинается с большой буквы:

var paddingHeight

function showResult()

Такой стиль написания называется CamelCase (верблюжья нотация).

• Слово соединяется через знак нижнего подчеркивания:

var pading_height

function show_Result()

Имя переменной — существительное

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

var productName

var baseLink

Название функции — глагол

Так как функция выполняет действие, то ее обозначают глаголом.

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

checkValue()

findSolution()

Одна функция должна выполнять одно действие, которое указано в названии. Если действие в функции сложное, лучше разделить его на несколько функций.

Комментарии к коду

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

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

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

Заключение

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

Мнение автора и редакции может не совпадать. Хотите написать колонку для «Нетологии»? Читайте наши условия публикации.

В этой главе мы напишем первую программу на C++ и научимся печатать и считывать с клавиатуры строки и числа.

Функция main

Пожалуй, самая простая и короткая программа на C++ — это программа, которая ничего не делает. Она выглядит так:

int main() {
    return 0;
}

Здесь определяется функция с именем main, которая не принимает никаких аргументов (внутри круглых скобок ничего нет) и не выполняет никаких содержательных команд. В каждой программе на C++ должна быть ровно одна функция main — с неё начинается выполнение программы.

У функции указан тип возвращаемого значения int (целое число), и она возвращает 0 — в данном случае это сообщение для операционной системы, что программа выполнилась успешно. И наоборот, ненулевой код возврата означает, что при выполнении возникла ошибка (например, программа получила некорректные входные данные).

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

int main() {
}

Hello, world!

Соблюдая традиции, напишем простейшую программу на C++ — она выведет приветствие в консоль:

#include <iostream>

int main() {
    std::cout << "Hello, world!n";
    return 0;
}

Разберём её подробнее.

Директива #include <iostream> подключает стандартный библиотечный заголовочный файл для работы с потоками ввода-вывода (input-output streams). Для печати мы используем поток вывода std::cout, где cout расшифровывается как character output, то есть «символьный вывод».

В теле функции main мы передаём в std::cout строку Hello, world! с завершающим переводом строки n. В зависимости от операционной системы n будет преобразован в один или в два управляющих байта с кодами 0A или 0D 0A соответственно.

Инструкции внутри тела функции завершаются точками с запятой.

Компиляция из командной строки

Вы можете запустить эту программу из какой-нибудь IDE. Мы же покажем, как собрать её в консоли Linux с помощью компилятора clang++.

Пусть файл с программой называется hello.cpp. Запустим компилятор:

$ clang++ hello.cpp -o hello

В результате мы получим исполняемый файл с именем hello, который теперь можно просто запустить. Он напечатает на экране ожидаемую фразу:

$ ./hello
Hello, world!

Если опцию -o не указать, то сгенерированный исполняемый файл будет по умолчанию назван a.out. В дальнейшем для простых примеров мы будем использовать краткую форму записи команды:

$ clang++ hello.cpp && ./a.out
Hello, world!

С её помощью мы компилируем программу и в случае успеха компиляции сразу же запускаем.

Комментарии

Комментарии — это фрагменты программы, которые игнорируются компилятором и предназначены для программиста. В C++ есть два вида комментариев — однострочные и многострочные:

int main() {  // однострочный комментарий продолжается до конца строки

/* Пример
   многострочного
   комментария */
}

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

Хорошо: комментировать, что делает библиотека, функция или класс или почему этот код написан именно так.

Плохо: комментировать, что происходит на отдельной строчке. Это признак того, что код можно написать лучше.

Библиотеки и заголовочные файлы

Библиотека — это код, который можно переиспользовать в разных программах. В стандарт языка C++ входит спецификация так называемой стандартной библиотеки, которая поставляется вместе с компилятором. Она содержит различные структуры данных (контейнеры), типовые алгоритмы, средства ввода-вывода и т. д. Конструкции из этой библиотеки предваряются префиксом std::, который обозначает пространство имён.

Чтобы воспользоваться теми или иными библиотечными конструкциями, в начале программы надо подключить нужные заголовочные файлы. Так, в программе, которая печатала Hello, world!, нам уже встречался заголовочный файл iostream и конструкция std::cout из стандартной библиотеки.

Для C++ существует также множество сторонних библиотек. Наиболее известной коллекцией сторонних библиотек для C++ является Boost.

Ошибки компиляции

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

Рассмотрим пример такой программы:

#include <iostream>

int main() {
    cout << "Hello, worldn"

Компилятор может выдать такие сообщения:

$ clang++ hello.cpp
hello.cpp:4:5: error: use of undeclared identifier 'cout'; did you mean 'std::cout'?
    cout << "Hello, world!n"
    ^~~~
    std::cout

hello.cpp:4:30: error: expected ';' after expression
    cout << "Hello, world!n"
                             ^
                             ;

hello.cpp:5:1: error: expected '}'
^
a.cpp:3:12: note: to match this '{'
int main() {
           ^
3 errors generated.

Первая ошибка — вместо std::cout мы написали cout. Вторая ошибка — не поставили точку запятой после "Hello, world!n". Наконец, третья – не закрыли фигурную скобку с телом функции.

Ошибки компиляции (compile errors) следует отличать от возможных ошибок времени выполнения (runtime errors), которые происходят после запуска программы и, как правило, зависят от входных данных, неизвестных во время компиляции.

Отступы и оформление кода

Фрагменты программы на C++ могут быть иерархически вложены друг в друга. На верхнем уровне находятся функции, внутри них написаны их тела, в теле могут быть составные операторы, и так далее.

Среди программистов есть соглашение — писать внутренние блоки кода с отступами вправо: компилятор полностью игнорирует эти отступы, а код читать удобнее. Мы будем использовать отступы в четыре пробела. Также мы будем придерживаться стиля оформления кода, принятого в Яндексе. Имена переменных мы будем писать с маленькой буквы, имена функций и классов — с большой (если речь не идёт о конструкциях стандартной библиотеки, где действуют другие соглашения).

Переменные

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

Type name;

где вместо Type — конкретный тип данных (например, строка или число), а вместо name — имя переменной. Имена переменных должны состоять из латинских букв, цифр и знаков подчёркивания и не должны начинаться с цифры. Также можно в одной строке определить несколько переменных одного типа:

Type name1 = value1, name2 = value2, name3 = value3;

Например:

#include <string>  // библиотека, в которой определён тип std::string

int main() {
    // Определяем переменную value целочисленного типа int
    int value;

    // Определяем переменные name и surname типа std::string (текстовая строка)
    std::string name, surname;
}

В этом примере мы используем встроенный в язык тип int (от слова integer — целое число) и поставляемый со стандартной библиотекой тип std::string. (Можно было бы использовать для строк встроенный тип с массивом символов, но это неудобно.)

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

От типа зависит:

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

Например, переменной типа int можно присваивать значения и с ней можно производить арифметические операции. Подробнее про разные типы данных и их размер в памяти мы поговорим ниже.

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

int main() {
    int value;
    value = 42;  // OK
    value = "Hello!";  // ошибка компиляции!
}

Переменные можно сразу проинициализировать значением. В С++ есть много разных способов инициализации. Нам пока будет достаточно способа, который называется copy initialization:

#include <string>

int main() {
    int value = 42;
    std::string title = "Bjarne Stroustrup";
}

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

Потоковый ввод и вывод

Поток — это абстракция для чтения и записи последовательности данных в форматированном виде.

Записывать данные можно на экран консоли, в файл, буфер в памяти или в строку. Считывать их можно с клавиатуры, из файла, из памяти. Причём с каждым таким «устройством» можно связать свой поток.

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

В программе Hello, world! нам уже встречался поток вывода std::cout, по умолчанию связанный с экраном консоли. Познакомимся с потоком ввода std::cin, связанным с клавиатурой. Для его использования нужен тот же заголовочный файл iostream.

Рассмотрим программу, которая спрашивает имя пользователя и печатает персональное приветствие:

#include <iostream>
#include <string>

int main() {
    std::string name;  // объявляем переменную name
    std::cout << "What is your name?n";
    std::cin >> name;  // считываем её значение с клавиатуры
    std::cout << "Hello, " << name << "!n";
}

Обратите внимание на направление угловых скобок в этом примере — они условно показывают направление потока данных. При печати данные выводятся на экран, и стрелки направлены от текста к cout. При вводе данные поступают с клавиатуры, и стрелки направлены от cin к переменной.

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

What is your name?
Alice
Hello, Alice!

Однако если ввести строку из нескольких слов с пробелами, то в name запишется только первое слово:

$ ./a.out
What is your name?
Alice Liddell
Hello, Alice!

Дело в том, что cin читает поток данных до ближайшего пробельного разделителя (пробела, табуляции, перевода строки или просто конца файла). Чтобы считать в строковую переменную всю строчку целиком (не включая завершающий символ перевода строки), нужно использовать функцию std::getline из заголовочного файла string:

#include <iostream>
#include <string>

int main() {
    std::string name;
    std::getline(std::cin, name);
    std::cout << "Hello, " << name << "!n";
}

В этом примере мы печатаем в одном выражении друг за другом несколько строк ("Hello, ", name и "!n"), разделённых угловыми скобками <<. Таким образом, cin и cout позволяют кратко считывать и печатать несколько объектов одной командой.

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

int main() {
    int a;
    int b;
    int c;
    std::cin >> a >> b >> c;
}

Напечатать их значения можно следующим образом:

std::cout << a << " " << b << " " << c << "n";

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