Как научиться писать код в 1с
(1)Сначала понять кем в 1С экосистеме хочешь быть. Мнение со стороны, что программист1С только и занят тем, что пишет код на русском - не совсем корректно изначально и чем больше времени проходит, тем дальше оно от реальности.
Сейчас бОльшую часть времени "сферический программист программист 1С в вакууме" посвящает не написанию кода, а внедрению типовых конфигураций и ответам на вопросы пользователей.
Лет 10-15 назад можно было не знать типовой программы, но умея быстро читать код, разобраться в любой проблеме пользователя на лету. (ну почти в любой. рекурсивная процедура ДоходыНалогиВычетыСотрудников на 4тыс строк в ЗиК 7.7 была исключением). В современных конфигах, если дело дошло до чтения кода - запасаемся терпением и страдаем.
Появилась , или вернее сказать оформилась, целая категория "программистов1С", которые не умеют писать год, зато разбираются досконально в возможностях конкретных конфигураций. Те же 10-15 лет назад в эту категорию попадали "женщины за 40", бывшие бухгалтера и ценился их труд не особо высоко. Любой бородатый программист мог заменить такую, просто порывшись в коде 10 минут. Сейчас это люди в костюмах с весьма обширными познаниями и хорошей зарплатой, которым вышеупомянутый программист вообще не нужен.
Могу привести ещё много примеров, но попытаюсь обобщить. Фирма 1С последние лет 15-20 только росла, ширилась и развивалась. Представим себе расширяющийся круг. Внутри круга задачи которые 1С уже решила в типовых программах, либо они решены лучшими из партнёров 1С. В этой области программисты почти не нужны, зато нужны консультанты. Граница круга - это направления, где 1С еще не имеет готовых решений, либо они ущербные. Тут мало работы консультанту, но много работы программисту.
Решай что тебе ближе.
Если Консультант - учи выбранный раздел учёта, подписывайся на периодику, мониторь новые законы(именно они основной источник хлеба для начинающих консультантов), ставь и настраивай типовые программы, пытайся организовать полный цикл учёта в вымышленной организации.
Если Программист - тебе курсы Гилева, книги мастодонтов1С типа Радченко, а еще, очень желательно второй(третий итд) язык программирования, для упорядочивания знаний. Вполне возможно, что кодить придётся не только и не столько в 1С
Очень часто в программе необходимо реализовать ситуацию, когда нужный код должен срабатывать тогда, когда выполняется определенное логическое условие. Или по другому: когда выполняется какое –то логическое условие, отрабатывает один код, а когда выполняется другое условие, то отрабатывает другой код.
В этой статье мы рассмотрим, каким образом осуществляется отработка логических условий в 1С 8.3.
Оператор Если
Основным оператором условий в языке программирования в 1С, по средством которого осуществляется отработка условий, является оператор Если.
В самом просто случае этот оператор имеет следующий синтаксис:
В том случае, если логическое условие принимает значение Истина, то выполняются операторы после ключевого слова Тогда. Если же это условие не выполняется, то следуют операторы после ключевого слова КонецЕсли.
То есть, может быть, такой вариант.
Или, такой вариант.
Заметьте, что операторы после ключевого с лова КонецЕсли выполняются в любом случае. Выполняется условие или нет. Если же нам нужно, чтобы когда условие выполняется, работали одни операторы, а когда нет – другие, то синтаксис операторе Если усложнится.
В этом случае операторы 1 выполняться тогда, когда логическое условие будет Истина, а операторы 2 выполняться, когда логическое условие будет Ложь.
Если мы возьмем предыдущий пример, то с ключевым словом Иначе он будет выглядеть следующим образом.
Но, очень часто возникают случаи, когда нужно отработать несколько условий. Например, может возникнуть ситуация, когда нужно отработать три условия: число больше нуля, число меньше нуля и число равно нулю. Тогда синтаксис еще усложниться.
В этом случае введено новое ключевое слово ИначеЕсли. Условие, которое установлено после ключевого слова ИначеЕсли будет проверяться тогда, когда условия после ключевого слова Если и после предыдущих ключевых слов ИначеЕсли (при их наличие) не выполняются (возвращается Ложь).
Причем, в этой конструкции ключевое условие Иначе не обязательно к использованию.
В этом случае решение предыдущего примера (с числом) будет выглядеть так:
Или мы можем отработать такое условие.
Обращаю внимание, что проверка условий идет с верху в низ, т.е. сначала проверяется выполнение условий после ключевого слова Если, и если условие выполняются , то отрабатываются операторы, которые идут после этого ключевого слова, потом проверяется выполнении условий после первого условия ИначеЕсли, и выполняются его операторы и т.д. И если ни одно условие не отработалось, то выполняются операторы после ключевого слова Иначе (при его наличии).
Вычислить выражение по условию
В 1С 8.3. в качестве оператора условия можно использовать ни только оператор Если, но также оператор ?(вычислить выражение по условию). Этот оператор имеет следующий синтаксис.
Если логическое выражение Условие принимает значение Истина, то выполняется выражение 1, а иначе выполняется выражение 2.
Например, этот оператор мы можем использовать, если нужно вычислить квадратный корень какого-то числа. Если число под корнем будет меньше нуля, то мы его умножим на -1, а иначе возьмем это же число.
Как вы видите, при помощи этого оператора можно упрощать написание кода, по сути можно писать условие одной строкой.
Отличное пособие по разработке в управляемом приложении 1С, как для начинающих разработчиков, так и для опытных программистов.
Если даже вы не знакомы с программированием, то благодаря этому руководству постепенно, за шагом шаг, сможете изучить 1С.
2 Создание рабочей среды
Для начала работы вам нужно создать рабочую среду. Для этого вы должны:
1. Создать любую из типовых демо-баз БП, УТ, где вы будете упражняться.
2. Научиться заходить в 1С в режиме Предприятие и Конфигуратор.
Демо-база должна быть с заполненными документами и справочниками, чтобы вам не заниматься вводом данных, а сосредоточиться на изучении программирования., чтобы вам не заниматься вводом данных, а сосредоточиться на изучении программирования.
2.1 Создание демо-базы для опытов
Пока что раздел не написан. Предполагается, что создавать новую базу вы умеете или попросите знакомых.
2.2 Создание пустой обработки для опытов
В Конфигураторе создайте новую внешнюю обработку через меню «Файл – Новый – Внешняя обработка». Откроется форма настройки новой внешней обработки.
Код для опытов будем писать непосредственно в модуле обработки. Модуль можно открыть через меню «Действия – Открыть модуль объекта» в форме настройки обработки.
После внесения изменений в код не забывайте сохранить обработку. Для этого активизируйте форму настройки внешней обработки и нажмите «Действия – Открыть модуль объекта».
Обработку можно запустить на выполнение, открыв ее файл в режиме 1С-предприятия через «Файл – Открыть». Она сразу же выполнится.
3 Первые шаги
3.1 Hello world
Вместо Hello World можно написать произвольный текст.
Обратите внимание, что код состоит из операторов, каждый из которых заканчивается точкой с запятой.
В одной строке можно размещать несколько операторов, но так не принято у программистов 1С:
Сообщить("Hello Wold"); Сообщить("И снова привет!");
3.2 Помощь по функциям
3.3 Переменные
Рассмотрим использование переменных в 1С.
Модифицируем обработку «Hello World» следующим образом:
Значение переменной можно менять многократно, посмотрите как работает этот код:
3.4 Комментарии
В коде можно использовать комментарии. Они не выполняются, а просто содержат описание того, что выполняется в коде или служат для заметок, чтобы не забыть какие-либо важные вещи. Комментарии важны, чтобы другой человек, или вы сами, спустя какое-то время могли разобраться, что и зачем вы делали в коде.
Изменим предыдущий код:
//Выводим приветствие миру
Комментарий начинается с символов // и длится до конца строки. Начинать комментарий можно в любом месте.
Комментарии можно использовать, чтобы какой-то участок кода не выполнялся. Для этого нужно просто закомментировать этот участок.
Попробуйте выделить следующие строки с помощью мышки или курсорных клавиш, а затем выбрать команду «Текст – Блок – Добавить комментарий»:
Вы увидите, что текст изменится на:
Соответственно, можно выделить участок кода и выполнить обратную команду «Текст – Блок – Удалить комментарий», при этом текст раскомментируется.
3.5 Арифметика
Рассмотрим использование арифметических операций в 1С.
Числа в 1С записываются интуитивно понятным образом:
Б = 10.2; //Десять целых, ноль десятых
В = -0.123; //Минус ноль целых сто двадцать три тысячных
Порядки вещественных чисел и отличные от десятичной системы счисления числа не используются.
Математические операции выполняются тоже просто:
А = 4/2; //4 разделить на 2
Б = А * 10; //Значение из переменной А умножаем на 10
В = А % 10; //Берем остаток от деления из переменной А на 2
Г = А + Б - В; //В Г помещаем А + Б – В
Д = (А+Б) * Б //Сначала вычисляем А + Б, затем полученное значение умножаем на Б
Е = ((А+Б)-Г) * Б //Сначала вычисляем А + Б, затем от полученного значения отнимаем Г, затем полученное значение умножаем на Б
Можно использовать также арифметические функции:
Б = Окр(А/3); //Округление при делении А на 3
3.6 Использование форм для ввода/вывода данных
3.6.1 Создание формы обработки
У обработки можно создать форму. Для этого в форме настройки обработки нужно ПКМ на пункте «Формы» и выбрать «Добавить», затем нажать «Готово». Будет создана основная форма обработки и открыта в Конфигураторе для редактирования.
Если щелкнуть на синем заголовке формы, откроются свойства формы.
3.6.2 Добавление элементов управления
Команда «Форма – Вставить элемент управления» позволяет разместить на форме элемент управления.
Попробуем разместить на форме поле для ввода целого числа, и заголовок для него.
Команда «Форма – Вставить элемент управления – Поле ввода – ОК» добавляет новое поле ввода.
Команда «Форма – Вставить элемент управления – Надпись – ОК» добавляет надпись.
3.6.3 Настройка элементов управления
Разместим надпись справа от поля ввода.
Если щелкнуть на элементе управления, открываются его свойства.
Для надписи установим заголовок «Число».
Для поля ввода установим значение свойств «Имя» и «Данные» в «Число». Обычно «Имя» и «Данные» всегда совпадают.
3.6.4 Настройка поведения формы
В низу формы есть три закладки «Диалог», «Модуль» и «Реквизиты».
Перейдем на закладку «Модуль». Мы увидим код модуля формы. В модуле есть только такой код:
// Вставить содержимое обработчика.
Изменим его следующим образом:
Так происходит потому, что у кнопки «Выполнить» в свойстве «Действие» указано «КнопкаВыполнитьНажатие».
3.6.5 Элементы для вывода данных
Добавим еще одно поле, дадим ему имя «Результат». В свойствах укажем «Только просмотр» в «Истина». Теперь это поле доступно только для просмотра.
Изменим процедуру на такую:
3.6.6 Сохранение значений
В реальных формах может быть очень много полей. Чтобы постоянно не вводить все значения, в свойствах формы поставим галочку «Сохранять значения» и в списке «Сохраняемые значения» выберем поле «Число».
Теперь зайдем в 1С, введем в поле «Число» значение 2. Выполним «Действия – Сохранить значения». Сохраним в настройку «Основная», установим галочку «Использовать при открытии».
Теперь закроем обработку и откроем ее еще раз. В поле «Число» окажется значение 2. Таким образом, можно сохранять значения для любого количества элементов формы, чтобы не заполнять их повторно.
Можно использовать несколько настроек и перезаписывать существующие настройки.
3.7 Строки
Рассмотрим работу со строками в 1С.
3.7.1 Запись строковых констант
Строки записываются в двойных кавычках, пример мы уже видели: "Hello World!"
Если нужно записать кавычку внутри строки, она повторяется два раза: "Я использую для бизнеса программы фирм ""1С"" и ""Микрософт""".
Строка может быть помещена в переменную так:
Если в строке встречается перевод строки, то она записывается с помощью символа вертикальной черты:
"Съешь конфеточку, дружок!
|Или хочешь пирожок?";
3.7.2 Конкатенация
Простейшая операция над строками – склейка (конкатенация).
В результате в переменную В будет помещена строка "Привет мир".
3.7.3 Строковые функции
Рассмотрим основные строковые функции:
Длина = СтрДлина(С); //10 - длина строки
С1 = Лев(С, 2); //Пр - левые 2 символа
С2 = Прав(С, 3); //мир - правые 3 символа
С3 = Сред(С, 5, 2); //ет - два символа, начиная с 5-й позиции
Задача:
Используя только функции Лев, Прав и Сред, получите из строки «Привет мир» строки «веер», «Пирр» и «ветер ветер».
3.7.4 Служебные символы
Не все символы можно включать в строку. Некоторые символы можно получить только по их коду.
В данном примере мы выводим символ табуляции между строками «Поз1» и «Поз2».
Сообщить("Поз1" + Символ(9) + "Поз2");
Но для наиболее часто используемых служебных символов в 1С существуют специальные константы:
Сообщить("Поз1" + Символы.Таб + "Поз2"); //Табуляция
Сообщить("Поз1" + Символы.ПС + "Поз2"); //Перевод строки
Задача:
Выведите строки «Хлеб», «Батон», «Булочка», «Пирожок», каждую с новой строки. Решить задачу двумя способами – с помощью символа вертикальной черты и конкатенацией с символом перевода строки.
Программисты в первую очередь работают с языком. Поэтому написание программ похоже на любой другой вид письменной работы. Сначала вы излагаете свои мысли как есть, а затем «причесываете» до тех пор, пока текст не будет легко читаться. Качество кода – результат проявления небезразличного отношения к делу и показатель профессионализма.
Сначала учимся читать и писать код, потом читать и переписывать написанный другимиЧтение кода происходит чаще, чем написание. Есть большая разница между обучением программированию и реальной работой в компании. Вначале мы и пишем, и читаем собственные программы. Но чем дальше мы продвигаемся, тем чаще нам приходится не писать, а читать код. Чем легче код читается, тем проще с ним работать другим людям.
Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живетеЧем проще читать код, тем проще его сопровождать. Понятный, читаемый код легче тестировать, в нем легче отлавливать ошибки – они не скрываются в его запутанной структуре. Плохо оформленный код неприятно изучать, читать, тестировать, сложно дополнять. Рано или поздно плохой код становится проще переписать.
Эстетическое восприятие кода влияет на удобство работы. Казалось бы, гораздо важнее производительность, возможность модификации, расширения… Но все эти показатели улучшаются, если код соответствует нашему чувству прекрасного. Глядя на качественно написанный код, можно быстро понять алгоритм и то, как работает программа для разных входных данных. Чистый код читается, как хорошо написанная проза: слова превращаются в зрительные образы.
Стиль кода определяет его будущее. Стиль и дисциплина продолжают жить в коде, даже если в нем не осталось ни одной исходной строки.
Все дороги программиста ведут к документации. В каждом языке существует свой стандарт оформления кода. Для 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, но большинство идей справедливы для любых языков.
Если вы видели эту книгу ранее с другим оформлением, не удивляйтесь – это новая версия обложки книги «Чистый код»
Всё что изложено ниже, в значительной мере представляет сжатый конспект этой книги с дополнениями из нашего опыта в проектировании программ. Итак, приступим к практикам.
Содержательность. К выбору названий любых объектов нужно подходить со всей ответственностью. Выразительные имена позволяют писать код, не требующий комментариев.
Полезно не только исходно выбирать ясные имена, но и заменять названия на более удачные, если они нашлись позже. Современные среды программирования позволяют легко заменить название переменной во всём коде, так что это не должно быть проблемой.
В первом примере непонятно, что вообще происходит, хотя в этом коде нет ни сложных выражений, ни каких-либо странностей. В результате правок сам код никак не изменился. Если знать, что это часть игры «Сапер», то теперь из кода понятно: здесь обрабатывается список ячеек игрового поля. Этот код можно улучшать и далее, но уже в результате простого переименования переменных стало понятно, что происходит.
Избегайте любых двусмысленностей и ложных ассоциаций. Если в объекте перечисляется список, но сам объект не является списком, нельзя в составе его названия употреблять слово 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 столбцов. В наши дни на экране можно разместить гораздо больше инфорфмации, но лучше ограничиться тем же объемом. Самоограничение позволяет видеть точку объявления каждой используемой переменной и держать в уме всю «историю», которую рассказывает функция.
Внешний вид текстового компьютерного терминала VT100
Вполне вероятно, что тот, кто будет сопровождать ваш код, не будет иметь возможности работать на большом мониторе. Например, ему необходимо одновременно разместить на одном рабочем столе экрана ноутбука несколько окон. Среды разработки позволяют установить ограничение, «верхнюю планку» (то есть правую 😉 ).
Блоки if, else, while должны иметь минимальный размер, чтобы информацию о них можно было держать в уме. Старайтесь избегать отрицательных условий – на их восприятие обычно уходит чуть больше времени, чем на положительные. То есть запись if (buffer.shouldCompact()) предпочтительнее записи if (!buffer.shouldNotCompact() .
Правило одной операции. Плохой код пытается сделать слишком много всего, намерения программиста расплываются для читателя. Поэтому стоит ввести важное правило:
Функция должна выполнять только одну операцию, выполнять ее хорошо, и ничего другого она делать не должна.Каждая функция должна делать то, что вы от нее ожидали из названия. Если функция действует не так, как она названа, читатель кода перестает доверять автору программы, ему приходится самостоятельно разбираться во всех подробностях реализации.
Я люблю, чтобы мой код был элегантным и эффективным. Логика должны быть достаточно прямолинейной, чтобы ошибкам было трудно спрятаться; зависимости — минимальными, чтобы упростить сопровождение; обработка ошибок — полной в соответствии с выработанной стратегией; а производительность — близкой к оптимальной, чтобы не искушать людей загрязнять код беспринципными оптимизациями. Чистый код хорошо решает одну задачу.Исключения вместо кодов ошибок. Используйте исключения ( try-catch , try-except ) вместо возвращения кодов ошибок. Возвращение кодов приводит к слишком глубокой вложенности.
Соблюдайте уровни абстракции. Одна функция – один уровень абстракции. Смешение уровней абстракции создает путаницу, функция обрастает слишком большим количеством второстепенных подробностей. Старайтесь соблюдать ясную иерархию.
Код читается сверху вниз. По мере чтения уровни абстракции должны меняться равномерно. Каждая функция должна быть окружена функциями единого уровня абстракции.
Ограничивайте число аргументов. Чем больше аргументов у функции, тем сложнее с ней работать. Необходимость функций с количеством аргументов большим двух должна быть подкреплена очень вескими доводами. Каждый новый аргумент критически усложняет процедуру тестирования. Если функция должна получать более двух аргументов, скорее всего, эти аргументы образуют концепцию, заслуживающую собственного имени.
Это непопулярное мнение, но в большинстве случаев комментарии – зло. Код должен быть самодокументированным. Комментарий – всегда признак неудачи: мы не смогли написать код так, что он понятен без комментариев. Проверьте, можно ли выразить свое намерение в самом коде.
В чём проблема? Программисты умеют сопровождать код, но не комментарии. В растущем коде комментарии быстро устаревают, частично или полностью переставая соответствовать ситуации. Только код правдиво сообщает своим содержанием, что он в действительности делает. Лучше потратить время на исправление запутанного кода, чем добавлять к плохому коду комментарии.
Однако есть несколько видов комментариев, которые выглядят достаточно оправданными.
TODO-комментарии. Бывает так: нужно было успеть к дедлайну, пришлось писать код быстро, поэтому в нем остались дыры. То есть всё работает, но реализация ущербная. Укажите все недоработки и создайте под них задачи. Каждый комментарий указывает на недоработку или потенциальную уязвимость.
Юридические комментарии. Корпоративные стандарты могут принуждать вставлять комментарии по юридическим соображениям. Ограничьтесь в таком комментарии описанием лицензии и ссылкой на внешний документ.
Предупреждения о последствиях. Иногда бывает полезно предупредить других программистов о нежелательных последствиях:
Комментарий также может подчеркивать важность обстоятельства, которое на первый взгляд кажется несущественным.
Бывают такие типы комментариев, которые лучше никогда не делать.
Закомментированный программный код. «Когда-нибудь в будущем раскомментирую этот код, приведу всё в порядок. Или вдруг эта идея кому-то поможет». Любой закомментированный код только ухудшает ситуацию. Все изменения хранятся в контроле версий – удаляйте такой код на корню. Это просто мусор: «потом» равносильно «никогда». Если что-то действительно нужно сделать, создайте краткий TODO-комментарий и задачу.
Мертвые функции – идентичные по смыслу предыдущему пункту функции и методы, которые не вызываются в программе. Пользуйтесь системой контроля версий и без зазрений совести удаляйте любой код, который не используется во время выполнения программы.
Избыточные комментарии. Задайте себе вопрос: стал ли код понятнее после прочтения комментария? Часто комментарии просто загромождают код и скрывают его смысл, излагая очевидные вещи. Иногда в комментарии включаются описания не относящихся к делу подробностей. Но профессионал бережет не только свое, но и чужое время, и не отвлекает читающего без повода.
Журнальные комментарии и ссылки на авторов. Некоторые программисты добавляют комментарий в начало файла при редактировании. Или указывают, кто и когда внес исправления. Когда-то это было оправдано, но теперь у нас есть системы контроля версий – это гораздо лучший способ обозначить границы зоны ответственности каждого.
Позиционные маркеры. Иногда любят отмечать определенные группы и позиции в исходных файлах:
Качественно организованный код способен внятно рассказать историю без балластных заголовков.
Минималистичность. Чем меньше кода, тем лучше. Имя файла должно быть простым, но содержательным. Маленькие файлы обычно более понятны, чем большие. Но размер файла, конечно, не должен быть самоцелью.
Код должен быть максимально линейным. Чем больше вложенность кода, тем сложнее его читать. Следите за тем, как двигаются ваши глаза. В хорошем коде вы двигаетесь строка за строкой, лишь изредка возвращаясь к предыдущим строчкам. Вложенность более трех уровней указывает на то, что с кодом нужно поработать: переписать условия проверок и циклов (использовать return и функциональное программирование), разбить код на меньшие методы.
Отдельные «мысли» следует отделять друг от друга пустыми строками. Каждая пустая строка – зрительная подсказка: описание одной концепции закончилось, далее следует новая. При просмотре кода взгляд концентрируется на первых строчках – в них больше всего информации, как в началах абзацев этого текста.
Тесно связанные концепции, должны располагаться вблизи друг друга. Не заставляйте читателя прыгать между файлами или постоянно скроллить файл. По той же причине переменные нужно объявлять как можно ближе к месту использования. Однако переменные экземпляров лучше объявлять в одном месте, обычно в начале класса, так как в хорошо спроектированном классе переменные используются большинством методов класса.
Пробелы для группировки взаимосвязанных элементов. Пробелы улучшают читаемость кода, если они стоят вокруг операторов присваивания, после запятых при перечислении переменных. В формулах пробелы используются для подчеркивания приоритета: не ставятся между множителями, но отбивают знаки сложения и вычитания.
Отступы. Размер отступов должен соответствовать позиции кода в иерархии. Это общая практика, которая позволяет быстро пропускать области видимости, не относящиеся к текущей ситуации. Не поддавайтесь искушению нарушить правила расстановки отступов для коротких команд.
В системе должны выполняться все тесты. Тесты – главный способ, с помощью которого можно понять, что система контролируема. А только контролируемую систему можно проверить.
Три закона тестирования по методологии TDD. Тестовый код не менее важен, чем код продукта. Соблюдение следующих трех правил позволяет организовать работу так, чтобы тесты охватывали все аспекты кода продукта:
- Не пишете код продукта, пока не напишете отказной модульный тест.
- Не пишите модульный тест в объеме большем, чем необходимо для отказа.
- Не пишите код продукта в объеме большем, чем необходимо для прохождения текущего отказного теста.
F.I.R.S.T. Качественные тесты должны обладать пятью характеристиками, первые буквы которых образуют указанный акроним:
- Fast. Тесты должны выполняться быстро.
- Independent. Тесты не должны зависеть друг от друга и выполняться в любом порядке.
- Repeatable. Тесты должны давать воспроизводимые в любой среде результаты.
- Self-validating. Результат выполнения теста – логический признак: тест пройден или нет. Иначе результаты приобретают субъективный характер.
- Timely. Тест должен создаваться своевременно. Тесты нужно писать непосредственно перед написанием кода.
Повышение уровня абстракции и устранение дубликатов. Все программы состоят из очень похожих элементов, а все задачи программирования сводятся к работе с ограниченным набором действий. Многие из этих действий могут быть описаны в одних и тех же терминах, например, извлечение элемента из коллекции. В подобных ситуациях правильно инкапсулировать реализацию в более абстрактном классе. Повышение уровня абстракции позволяет избежать дублирования и многократно применения одного и того же кода, лучше понять, что действительно происходит в программе, уйдя от частностей.
Если что-то в программе делается снова и снова, значит, какая-то важная концепция не нашла своего отражения в коде. Нужно попытаться понять, что это такое, и выразить идею в виде кода. Избегайте дубликатов, это всегда лишняя работа, лишний риск, лишняя сложность.
Несколько языков в одном исходном файле. Современные среды программирования позволяют объединять в одном файле код, написанный на разных языках. Результат получается запутанным, неаккуратным и ненадежным. Чтобы четко разграничить ответственность, в файле должен преобладать один язык. Сведите к минимуму количество и объем кода на дополнительных языках.
Не нужно бездумно следовать догмам. Не переусердствуйте с сокращением кода функций и классов. Всегда руководствуйтесь здравым смыслом.
Чистый код выглядит так, как если его автор над ним тщательно потрудился. Вы не можете найти очевидных возможностей для его улучшения. Попытавшись его улучшить, вы вновь вернетесь к тому же коду.
Чтобы писать чистый код, который бы никого не удивлял, необходимо раз за разом сознательно применять описанные приемы. При чтении чистого кода вы улыбаетесь, как при виде искусно сделанной музыкальной шкатулки. Код можно назвать красивым, если у вас создается впечатление, что язык был создан специально для этой задачи.
Расскажите нам о правилах, которые вы применяете для написания своего программного кода. Какие open source программы, на ваш взгляд, имеют лучшее качество кода?
Читайте также: