Научиться писать компьютерный код
Соавтор(ы): Stephen Cognetta, MBA. Стивен Коньетта — сооснователь и исполнительный директор обучающей платформы Exponent, которая помогает людям готовиться и мастерски проходить технические собеседования. Специализируется на подготовке к собеседованиям по управлению продуктом, программированию, маркетингу продукта, менеджменту, управлению техническими проектами и науке о данных. Получил диплом бакалавра с отличием по компьютерной инженерии в Принстонском университете и магистра делового администрирования в Стэнфордском университете. До того как основать Exponent, работал менеджером по продукту в Google и был сооснователем HackMentalHealth.
Итак, у вас появилась идея для отличной программы, однако вы и понятия не имеете, как ее реализовать? Не беда, поможем. Правда, придется потратить немало времени на то, чтобы выучить язык программирования, но это нормально. Скажем даже более, многие успешные программисты — самоучки. Выучив основы, вы сможете создавать простые программы, тратя на это минимум времени. Создание более сложных программ, конечно, является более серьезной задачей, но, как говорится, терпение и труд все перетрут!
- C — один из самых старых языков программирования. Знакомство с С позволит упростить изучение C++ и Java.
- C++ — один из самых популярных языков программирования в наши дни, особенно в плане разработки программного обеспечения. Правда, на то, чтобы выучить С++, уйдет время, а на то, чтобы еще и научиться им пользоваться, уйдет еще больше… Но это окупит себя!
- Java — еще один очень популярный язык программирования, который может работать почти что в любой операционной системе.
- Python — один из простейших языков программирования, чьи основы можно выучить за пару дней. Тем не менее это весьма мощный язык, задействованный для создания множества серверных и веб-приложений.
Загрузите образцы и программы с открытым кодом. Вам будет куда проще учиться на примере, работая с образцами, благо что их в сети доступно предостаточно. Начните с простых программ, которые хоть как-то относятся к той программе, которую вы хотите сделать.
Чтобы выучить основы, создавайте простые программы. Раз уж вы начали писать код сами, то начните с азов. Напишите несколько программ, скажем, на вывод строки или подсчет простенького уравнения. Отрабатывайте все это — пригодится позже, во время работы над более сложными программами. Экспериментируйте, старайтесь сломать даже собственные программы.
Присоединитесь к сообществам программистов. Возможность задать вопросы состоявшемуся программисту — бесценна. На сайтах, где собираются программисты, вы найдете множество единомышленников, причем вне зависимости от того, на каком языке вы пишете. Не бойтесь спрашивать, но никогда не просите помощи, не испробовав перед этим все доступные вам средства.
Не забывайте, что на изучение языка программирования уходит много времени. Вы не сумеете написать программу (сложную), когда впервые сядете за компьютер с учебником программирования. Впрочем, чем больше вы будете учиться и практиковаться, тем лучше будете программировать. [3] X Источник информации
- Все, что вы хотите реализовать в программе, должно быть перечислено на страницах дизайн-документа.
- Кроме того, дизайн-документ должен учитывать и пользователя, точнее то, как он будет работать с программой.
Сделайте блок-схему вашей программы. Это будет своего рода карта, показывающая, как пользователь будет переходить от одной части программы к другой. На этом этапе ничего сложнее простой блок-схемы вам не нужно.
Определитесь с архитектурой программы. Цели будут определять средство… то есть архитектуру. Если знать и понимать, каким задачам какая архитектура соответствует, то процесс разработки пойдет куда эффективнее. [4] X Источник информации
- Следующим шагом в схеме «1-2-3» будет так называемый REPL (Read-Execute-Print Loop). Проще говоря, это возврат к первому шагу программы после вывода результата вычислений.
- Подумайте о программах типа Pipeline. Они характеризуются тем, что трансформируют вводимые пользователем данные и работают последовательно. Данный тип подходит для программ, которые требуют минимум взаимодействия с пользователем — скажем, RSS-ридеры. Такая программа будет представлять собой несколько классов с общим циклом.
Сделайте акцент на какой-то одной функции программы. Точнее сказать, прототип — это всегда основная функция программы. Допустим, вы создаете программу-органайзер — тогда основной функцией будет календарь и возможность добавлять события.
- В прототип можно вносить срочные изменения и тестировать их.
- Разумеется, задача тестирования прототипа требует участия сразу многих людей.
- Прототип может и будет меняться, это факт.
Не бойтесь перерабатывать прототип снова и снова. В этом его суть — сначала эксперименты, потом релиз. Именно на примере прототипа вы сможете увидеть, все ли работает так, как надо. Если же прототип оказывается неудачным — не беда, просто перепишите его с нуля, начните все заново. Лучше так, поверьте.
- Псевдокод, впрочем, использует тот же синтаксис, что и обычный код, поэтому писать псевдокод надо так же, как и программу.
Усовершенствуйте прототип. Можете взять сам прототип, можете взять псевдокод — в любом случае суть в том, чтобы сделать прототип лучше, совершеннее, быстрее!
Начните работу над кодом программы. Вот, собственно, мы и добрались до сути. Именно работа над кодом программы и займет бо́льшую часть времени, не говоря уже про бесчисленные компиляции, не менее бесчисленные тесты и поиски багов… Если над вашей программой работает целая команда, то стоит начать с псевдокода, чтобы все шло равномерно.
Не забывайте комментировать код. Описывайте функции и особенности, которые вы реализуете в коде. Это нужно не только для того, чтобы кто-то другой, открыв ваши исходники, сумел разобраться, что к чему, но и для того, чтобы вы сами не запутались в собственном коде, если вернетесь к нему, скажем, через год.
- Этот этап работы над программой часто называют «альфа-тестированием».
- Часто данный процесс называют бета-тестированием.
Протестируйте релиз-версию. Продолжая вносить в программу исправления и дополнительные материалы, не забывайте все тестировать.
Подумайте, что вам нужно. Это будет зависеть от программы, так что подумайте, нужны ли вам, скажем, аудиозаписи? Графика? Контент? Задумайтесь об этом до релиза.
Подумайте, не стоит ли отдать все это на аутсорсинг. Если вам нужно много всего, но вы или никто в вашей команде не умеет рисовать или заниматься звукозаписью, то стоит вспомнить про аутсорсинге. Вы без проблем найдете фрилансеров, которые смогут подготовить для вас все необходимое.
Добавьте в программу все необходимые дополнительные материалы. Опять же, они не должны портить функционал программы. Добавление дополнительных материалов знаменует собой начало финального этапа работы над программой, если только, конечно, дополнительные материалы не являются неотъемлемой и внутренней частью самой программы (как, скажем, бывает при создании видеоигр).
Подумайте, не стоит ли выпустить вашу программу под лицензией открытого кода. Тогда и другие люди смогут получить доступ к исходному коду программы, вносить в него изменения и улучшения. Правда, по такой лицензии вы вряд ли получите доход от программы — вы же не сможете ее продавать, код-то открытый. В чем же резон? В помощи сообщества, которое, если заинтересуется вашей программой, может превратить ее в истинный шедевр.
- В зависимости от того, что у вас за программа, вы можете продавать еще множество услуг.
- Хотите не растерять покупателей и стяжать себе добрую славу? Выпускайте патчи почаще.
Сначала — try-catch-finally, потом — всё остальное
Жорж Кангилем сделал верное наблюдение, когда сказал: «Человеку свойственно ошибаться, упорствовать в ошибке — дело дьявола».
Обработкой ошибок занимаются все программисты. Откуда берутся ошибки? В систему могут поступить аномальные входные данные, устройства могут давать сбои… От разработчиков ждут, чтобы они обеспечивали правильную работу созданных ими программ. Однако проблема заключается не в самой обработке ошибок. Проблема заключается в том, чтобы обрабатывать ошибки, не нарушая при этом читаемость и чистоту основного кода.
Многие программы сверх меры перегружены конструкциями обработки ошибок. В результате полезный код оказывается беспорядочно разбросанным по этим конструкциям. Подобное ведёт к тому, что то, что составляет цель программы, практически невозможно понять. Это — совершенно неправильно. Код должен быть чистым и надёжным, а ошибки надо обрабатывать изящно и со вкусом. Подобный подход к обработке ошибок — признак программиста, отлично знающего своё дело.
Один из способов качественной обработки ошибок заключается в правильном использовании блоков try-catch-finally. В них включают потенциально сбойные места, и с их помощью организуют перехват и обработку ошибок. Эти блоки можно представить себе как выделение изолированных областей видимости в коде. Когда код выполняется в блоке try, это указывает тому, кто читает код, на то, что выполнение в любой момент может прерваться, а затем продолжиться в блоке catch.
Поэтому рекомендуется выделять блоки try-catch-finally в самом начале работы над программой. Это, в частности, поможет вам определить, чего от кода может ждать тот, кто будет его читать, при этом неважно, выполнится ли код без ошибки, или во фрагменте, заключённом в блок try, произойдёт сбой.
Важность форматирования
Роберт Мартин однажды очень точно подметил: «Форматирование кода направлено на передачу информации, а передача информации является первоочередной задачей профессионального разработчика».
Полагаю, нельзя недооценивать эту идею. Внимание к форматированию кода — это одна из важнейших характеристик по-настоящему хорошего программирования.
Отформатированный код — это окно в ваш разум. Мы хотим впечатлять других людей нашей аккуратностью, вниманием к деталям и ясностью мысли. Но если тот, кто читает код, видит беспорядочные нагромождения конструкций, мешанину, у которой нет ни начала, ни конца, это немедленно бросает тень на репутацию автора кода. В этом нет никаких сомнений.
Если вы думаете, что самое главное для профессионального разработчика — это «сделать так, чтобы программа заработала», это значит, что вы очень далеки от истины. Функционал, созданный сегодня, вполне может измениться в следующем релизе программы, но читаемость кода — это то, что оказывает воздействие на всё то, что с ним происходит, с самого начала его существования.
Стиль программирования и удобочитаемость кода продолжают влиять на сопровождаемость программы и после того, как её первоначальный облик был преобразован до неузнаваемости.
Учитывайте то, что вы запомнитесь тем, кто читает тексты ваших программ, по вашему стилю и аккуратности, и очень редко — по функционалу, реализованного в коде. Поэтому уделяйте внимание форматированию, например, придерживаясь правил, которые приняты в вашей организации.
Итоги
Как выразить, буквально в двух словах, всё то, о чём мы говорили? Ответ на это вопрос — термин «чувство кода». Это, в мире программирования, эквивалент здравого смысла.
Вот что говорит об этом Роберт Мартин: «Чтобы написать чистый код, необходимо сознательно применять множество приёмов, руководствуясь приобретённым усердным трудом чувством «чистоты». Ключевую роль здесь играет чувство кода. Одни с этим чувством рождаются. Другие работают, чтобы развить его. Это чувство не только позволяет отличить хороший код от плохого, но и демонстрирует стратегию применения наших навыков для преобразования плохого кода в чистый код». По мне — так это золотые слова.
Чувство кода помогает программисту выбрать лучший из имеющихся у него инструментов, использование которого поможет ему в его стремлении создавать чистый и красивый код, приносящий пользу другим людям.
Программист, пишущий чистый код — это художник. Он способен превратить пустой экран в элегантное произведение искусства, которое будут помнить долгие годы.
В завершение нашего разговора о чистом коде вспомним слова Гарольда Абельсона: «Программы должны писаться, в первую очередь, для того, чтобы их читали люди, и лишь во вторую — для выполнения машиной».
Набор практик хорошего кода, не зависящих от языка программирования. Примените их, и ваш код будет не только работать, но и читаться.
Программисты в первую очередь работают с языком. Поэтому написание программ похоже на любой другой вид письменной работы. Сначала вы излагаете свои мысли как есть, а затем «причесываете» до тех пор, пока текст не будет легко читаться. Качество кода – результат проявления небезразличного отношения к делу и показатель профессионализма.
Чтение кода происходит чаще, чем написание. Есть большая разница между обучением программированию и реальной работой в компании. Вначале мы и пишем, и читаем собственные программы. Но чем дальше мы продвигаемся, тем чаще нам приходится не писать, а читать код. Чем легче код читается, тем проще с ним работать другим людям.
Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете
Чем проще читать код, тем проще его сопровождать. Понятный, читаемый код легче тестировать, в нем легче отлавливать ошибки – они не скрываются в его запутанной структуре. Плохо оформленный код неприятно изучать, читать, тестировать, сложно дополнять. Рано или поздно плохой код становится проще переписать.
Эстетическое восприятие кода влияет на удобство работы. Казалось бы, гораздо важнее производительность, возможность модификации, расширения… Но все эти показатели улучшаются, если код соответствует нашему чувству прекрасного. Глядя на качественно написанный код, можно быстро понять алгоритм и то, как работает программа для разных входных данных. Чистый код читается, как хорошо написанная проза: слова превращаются в зрительные образы.
Стиль кода определяет его будущее. Стиль и дисциплина продолжают жить в коде, даже если в нем не осталось ни одной исходной строки.
Все дороги программиста ведут к документации. В каждом языке существует свой стандарт оформления кода. Для 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 программы, на ваш взгляд, имеют лучшее качество кода?
Больше полезной информации вы найдете на наших телеграм-каналах «Библиотека программиста» и «Книги для программистов».
Дополнительные статьи
Об этой статье
wikiHow работает по принципу вики, а это значит, что многие наши статьи написаны несколькими авторами. При создании этой статьи над ее редактированием и улучшением работали, в том числе анонимно, 44 человек(а).
Из этой статьи вы узнаете, как написать программу в стандартном приложении «Блокнот» для Windows. Если коротко, то вам нужно будет построчно ввести код программы в Блокнот, а затем сохранить файл в формате необходимого языка программирования.
- Файлы Блокнота по умолчанию сохраняются в виде текстовых документов.
- Если вы не знаете ни одного языка программирования, воспользуйтесь одним из примеров, указанных в статье.
Завершив строку кода, нажмите ↵ Enter . Как и в большинстве редакторов кода, отдельные строки кода должны располагаться на разных строках Блокнота.
Закройте все открытые фигурные и квадратные скобки. Если вы открыли квадратную или фигурную скобки ( или [ ), ее обязательно нужно закрыть, чтобы завершить строку кода. Несоблюдение этого правила приведет к ошибкам в коде.
Соавтор(ы): Archana Ramamoorthy, MS. Арчана Рамамурти — технический директор Workday (Северная Америка). Высококлассный специалист по продуктам, поборница безопасности, сторонница большего распространения интеграции на равных для всех условиях в индустрии технологий. Получила степень бакалавра в Университете SRM и магистра в Университете Дьюка. Работает в области продакт-менеджмента более восьми лет.
По мере того как технология становится все более и более доступной широкой публике, растет и потребность в программистах. Написание компьютерных кодов и программ, оно же кодинг (от английского «сoding») — это навык, который приобретается и совершенствуется на протяжении долгого времени, но даже самый опытный программист когда-то был новичком. Существует большое разнообразие языков программирования, которые великолепно подходят для начинающих программистов, вне зависимости от того, в какой сфере деятельности вы хотите применять ваши навыки (например, JavaScript довольно сложен, так что лучше начать с HTML или CSS). Узнайте, как научиться писать компьютерные программы, прочитав эту статью.
- Выбирая язык, сконцентрируйтесь на том, в каких целях вы хотите создавать программные коды, и уже потом выбирайте начальный язык. К примеру, если вы хотите заниматься разработкой веб-сайтов, то вам следует начать с изучения HTML5, а затем дополнить его языками CSS, JavaScript и PHP. Если вы хотите создавать компьютерные программы, то начните изучать C ++ или любой другой основной язык программирования.
- Если вы станете профессиональным программистом, то вы можете обнаружить, что никогда не используете язык, который вы изначально выучили, для своей работы. Вместо этого вы будете все время продолжать учить новые языки через документацию и эксперименты.
Технический директор Workday
Арчана Рамамурти — технический директор Workday (Северная Америка). Высококлассный специалист по продуктам, поборница безопасности, сторонница большего распространения интеграции на равных для всех условиях в индустрии технологий. Получила степень бакалавра в Университете SRM и магистра в Университете Дьюка. Работает в области продакт-менеджмента более восьми лет.
Наш специалист делится своей историей:: «Я пришла к написанию кодов, не зная ничего ни о компьютерном дизайне, ни о программировании. Когда я захотела научиться писать программы, я начала с чтения книг по языку и с использования информации из интернета. Сегодня в мире доступно так много ресурсов, что научиться новым навыкам очень легко!»
Каким должен быть качественный код? Роберт Мартин выразил это невероятно точно, когда сказал: «Единственная адекватная мера качества кода — это количество восклицаний «какого чёрта!» в минуту».
Позвольте мне пояснить эту идею.
Каждый раз, когда я читаю чужой код, вот какие мысли приходят мне в голову:
- Какого чёрта! (с отвращением) — когда в некоем фрагменте кода нет необходимости.
- Какого чёрта! (с восхищением) — когда программист сделал что-то очень удачное.
- Какого чёрта! (с раздражением) — когда я не могу понять тот ужас, который находится у меня перед глазами.
Путь к мастерству кодирования идёт через две важные вехи. Это — знания и труд. Знания дают шаблоны, принципы, практические приёмы, эвристические правила, которые нужны для профессионального роста. Но эти знания нужно закреплять. Тут в дело вступает механическая и зрительная память, знания должны прочно обосноваться у вас внутри через постоянную практику и упорный труд.
Короче говоря, обучение написанию чистого кода — это тяжёлая работа. Вы должны вложить в неё немало сил. Вам нужна практика. Причём, на этом пути будут моменты, когда дело стопорится, когда ничего не получается, но это вас останавливать не должно — шаг за шагом вы будете приближаться к совершенству, повторять всё снова и снова до тех пор пока всё не окажется таким, каким должно быть. Обходных путей здесь нет.
Вот несколько идей, руководствуясь которыми вы сможете продвинуться на пути освоения искусства написания чистого и красивого кода.
Имена
Кендрик Ламар как-то сказал: «Если я соберусь рассказать настоящую историю, я начну её с моего имени».
В мире программ мы встречаем имена буквально повсюду. Мы даём имена функциям, классам, аргументам, пакетам, да чему угодно. Имена придумывают для файлов с программным кодом, для папок, и для всего, что в них находится. Мы постоянно изобретаем имена, и поэтому имена часто становятся тем, что загрязняет код.
Имя, которое вы даёте сущности, должно раскрывать её предназначение, намерение, с которым вы её используете. Выбор хороших имён требует времени, но позволяет сэкономить гораздо больше времени, когда страсти накаляются. Поэтому уделяйте внимание именам, а если вам удаётся найти имя, которое лучше справляется с возложенной на него задачей — замените им то, что вы уже используете. Любой, кто читает ваш код, будет вам благодарен за ваше внимательное отношение к именам.
Всегда помните, что имя любой переменной, функции или класса, должно отвечать на три главных вопроса о некоей сущности: почему она существует, какие функции она выполняет, и как она используется.
Для того чтобы придумывать хорошие имена, нужно не только умение подыскивать подходящие слова. Тут требуется знакомство с общим для программистов всей Земли культурным контекстом, для которого не существует границ. Этому нельзя научить — каждый осваивает всё это самостоятельно, например — читая качественный код других людей.
Одна функция — одна задача
Луис Салливан однажды сказал замечательную вещь: «Форма следует функции».
Каждая система построена на основе языка, предназначенного для конкретной предметной области, который спроектирован программистами для точного описания этой области. Функции — глаголы этого языка, а классы — это имена существительные. Функции обычно являются первой линией организации любого языка программирования, и их качественное написание — это суть создания хорошего кода.
Есть всего два правила написания чистых функций:
- Они должны быть маленькими.
- Они должны решать лишь одну задачу и должны делать это хорошо.
Смешивание уровней абстракции в функции всегда сильно сбивает с толку и ведёт, со временем, к появлению кода, которым невозможно нормально управлять. Опытные программисты видят в функциях нечто вроде историй, которые они рассказывают, нежели код, который они пишут.
Они используют механизмы выбранного ими языка программирования для создания чистых, выразительных, обладающих широкими возможностями блоков кода, которые, и правда, могут быть отличными рассказчиками историй.
Код и комментарии
Вот интересное наблюдение, которое сделала Винус Уильямс: «Все делают собственные комментарии. Так рождаются слухи».
Комментарии в коде напоминают обоюдоострый нож. Ничто не может быть более полезным, чем комментарий, сделанный к месту. С другой стороны, ничто не может захламить код сильнее, чем пустые, бесполезные комментарии, которые просто занимают пространство на экране. И ничто не может быть более разрушительным, чем комментарии, распространяющие дезинформацию и ложь.
Комментарии, в лучшем случае — это необходимое зло. Почему? Они не всегда — зло, но в большинстве случаев это так. Чем старше комментарии — тем сложнее становится поддерживать их в актуальном состоянии. Многие программисты запятнали свою репутацию тем, что их комментарии, в ходе развития проектов, перестали согласовываться с кодом.
Код меняется и развивается. Блоки кода перемещаются. А комментарии остаются неизменными. Это — уже проблема.
Всегда помните о том, что чистый и выразительный код с минимумом комментариев гораздо лучше запутанного и сложного текста программы, в котором имеется множество пояснений. Не тратьте время на то, чтобы объяснить созданный вами беспорядок, лучше уделите время наведению порядка в коде.
Читайте также: