Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Люди, по своей природе, склонны к совершению ошибок. Однако множества недочётов, характерных для разработчиков, можно избежать. Если программист способен избавиться от распространённых оплошностей, о которых речь пойдёт в этом материале, он сможет писать более качественный и чистый код.
Устранение недочётов в коде пойдёт на пользу не только тому, кто от них избавится, но и тем программистам, которым придётся этот код читать. В результате можно сказать, что тот, кто трудится в команде и стремится улучшить свой код, делает это не только для себя, но и для тех, с кем работает.
Вот некоторые распространённые недочёты, которых стоит избегать программисту.
В соответствии с принципом единственной ответственности функция должна отвечать лишь за выполнение какой-то одной операции. И это должна быть только одна операция. Я видел слишком много функций, которые выполняют и загрузку, и обработку, и представление неких данных. Считается, что выполнение подобных действий лучше распределять по нескольким функциям. Одна функция загружает данные, другая обрабатывает, третья отвечает за их представление.
Причина важности того, чтобы писать функции, сосредоточенные на решении единственной задачи, заключается в том, что такой подход делает код более надёжным. Предположим, что в вышеописанном случае данные загружаются из некоего API. Если этот API изменится, например — выйдет его новая версия, то высока вероятность того, что работать перестанет вся функция. Код, загружающий данные, загрузит что-то не то, это повлияет на обработку и представление данных. Для решения проблемы придётся сначала найти её, выяснив, что дало сбой, а потом править код большой функции. Если же загрузка, обработка и представление данных разбиты на несколько функций, решать подобные проблемы будет гораздо легче.
Все видели код, большие фрагменты которого, например, содержащие некие функции, закомментированы. При этом никто не знает о том, почему эти фрагменты всё ещё не удалены из кодовой базы. И никто не знает о том, будут ли эти фрагменты кода работать, если их раскомментировать. Но при этом их не удаляют. А удалять их надо. Причина, по которой подобный код загрязняет проекты, заключается в том, что все предполагают, что этот код может кому-то понадобиться.
Подобные фрагменты кода стоит просто удалять. И если в самой свежей версии кода этих удалённых фрагментов не будет, а они при этом кому-то реально понадобятся, их можно будет найти в системе контроля версий. Отмечу, что это лишь моё мнение по данному вопросу.
Однажды я написал статью, в которой представлены простые правила подбора хороших имён переменных. Качественные имена переменных — это крайне важно. Дело в том, что программисты обычно работают над проектами не в одиночку. Их коллегам нужно понимать тот код, который они пишут. Понятные имена переменных способствуют улучшению восприятия чужого кода.
Повторю то, о чём я говорил в вышеупомянутом материале: «Выбор хороших имён переменных отнимает время, но это экономит больше времени, чем отнимает».
Если продолжить рассуждения о проблеме непонятных имён переменных, можно прийти к мысли об использовании в программе неких значений, «магических чисел» или строк, которые вообще не имеют имён и не записаны в какие-либо переменные.
Из Википедии можно узнать, что «магическими числами» называют плохую практику программирования, когда в исходном тексте встречается числовое значение и неочевидно, что оно означает.
Взглянем на следующий пример кода:
Здесь значение
Этот код станет гораздо понятнее в том случае, если переписать его так:
Теперь любой поймёт, что в цикле мы перебираем колоду карт. Это указывает другим разработчикам на сущность происходящего, помогает понять контекст выполняемого действия. Такой подход, вдобавок, значительно упрощает изменение подобного значения, так как оно, если и используется в разных местах программы, задаётся лишь в одном месте кода.
То же самое имеет отношение и к работе со строками:
Что это за
Перепишем это:
А вот теперь всё оказывается гораздо понятнее.
Неопрятное форматирование кода — это «болезнь» начинающих программистов. Многие разработчики, имеющие некоторый опыт, обычно утвердительно кивают, отвечая на вопрос о том, знают ли они какого-нибудь тестировщика или дата-сайентиста, который плохо форматирует код. Причина этого заключается в недостатке опыта. Исключение составляют лишь те программисты, которые пользуются языком наподобие Python, в котором форматирование кода влияет на выполнение программы.
Один из самых распространённых способов решения этой проблемы заключается в использовании линтера. Все современные IDE, кроме того, поддерживают возможности по автоматическому форматированию кода. Иногда подобный функционал реализуется средствами плагинов, которые нужно устанавливать самостоятельно, а иногда он входит в стандартные возможности IDE.
Если значения жёстко задаются коде в программы, это значит, что данные встраивают прямо в исходный код или в другие подобные объекты. Противоположность такому подходу — получение данных из внешних источников или генерирование их во время выполнения программы.
Жёстко заданные значения не позволяют легко конфигурировать программу. Они, так сказать, «высечены в камне». Подобное считается анти-паттерном, или, как минимум, указывает на явные проблемы в коде.
Чаще всего жёстко задаются пароли и пути к файлам. Делают это по самым разным причинам, иногда они могут быть даже и оправданными.
Например, много жёстко заданных значений можно увидеть в некоторых примерах кода, ответственного за аутентификацию на внешних сервисах или API. Лучше так не делать.
Если некто заметил за собой частое использование значений, жёстко заданных в коде, ему стоит критически оценить свою работу. Дело в том, что обычно применение таких значений — это не лучший способ решения неких задач.
Уважаемые читатели! С какими недочётами в коде вам приходилось сталкиваться?
Устранение недочётов в коде пойдёт на пользу не только тому, кто от них избавится, но и тем программистам, которым придётся этот код читать. В результате можно сказать, что тот, кто трудится в команде и стремится улучшить свой код, делает это не только для себя, но и для тех, с кем работает.
Вот некоторые распространённые недочёты, которых стоит избегать программисту.
1. В функции выполняется слишком много действий
В соответствии с принципом единственной ответственности функция должна отвечать лишь за выполнение какой-то одной операции. И это должна быть только одна операция. Я видел слишком много функций, которые выполняют и загрузку, и обработку, и представление неких данных. Считается, что выполнение подобных действий лучше распределять по нескольким функциям. Одна функция загружает данные, другая обрабатывает, третья отвечает за их представление.
Причина важности того, чтобы писать функции, сосредоточенные на решении единственной задачи, заключается в том, что такой подход делает код более надёжным. Предположим, что в вышеописанном случае данные загружаются из некоего API. Если этот API изменится, например — выйдет его новая версия, то высока вероятность того, что работать перестанет вся функция. Код, загружающий данные, загрузит что-то не то, это повлияет на обработку и представление данных. Для решения проблемы придётся сначала найти её, выяснив, что дало сбой, а потом править код большой функции. Если же загрузка, обработка и представление данных разбиты на несколько функций, решать подобные проблемы будет гораздо легче.
2. В проекте имеется закомментированный код
Все видели код, большие фрагменты которого, например, содержащие некие функции, закомментированы. При этом никто не знает о том, почему эти фрагменты всё ещё не удалены из кодовой базы. И никто не знает о том, будут ли эти фрагменты кода работать, если их раскомментировать. Но при этом их не удаляют. А удалять их надо. Причина, по которой подобный код загрязняет проекты, заключается в том, что все предполагают, что этот код может кому-то понадобиться.
Подобные фрагменты кода стоит просто удалять. И если в самой свежей версии кода этих удалённых фрагментов не будет, а они при этом кому-то реально понадобятся, их можно будет найти в системе контроля версий. Отмечу, что это лишь моё мнение по данному вопросу.
3. Неудачные имена переменных
Однажды я написал статью, в которой представлены простые правила подбора хороших имён переменных. Качественные имена переменных — это крайне важно. Дело в том, что программисты обычно работают над проектами не в одиночку. Их коллегам нужно понимать тот код, который они пишут. Понятные имена переменных способствуют улучшению восприятия чужого кода.
Повторю то, о чём я говорил в вышеупомянутом материале: «Выбор хороших имён переменных отнимает время, но это экономит больше времени, чем отнимает».
4. «Магические числа» и строки
Если продолжить рассуждения о проблеме непонятных имён переменных, можно прийти к мысли об использовании в программе неких значений, «магических чисел» или строк, которые вообще не имеют имён и не записаны в какие-либо переменные.
Из Википедии можно узнать, что «магическими числами» называют плохую практику программирования, когда в исходном тексте встречается числовое значение и неочевидно, что оно означает.
Взглянем на следующий пример кода:
for ($i = 1; $i <= 52; $i++) {
...
}Здесь значение
52 — это «магическое число». Никто не знает о том, почему это — именно число 52, и о том, что оно означает. Почему 52? Почему не 64? Может — это количество недель в году?Этот код станет гораздо понятнее в том случае, если переписать его так:
$cardDeckSize = 52;
for ($i = 1; $i <= $cardDeckSize; $i++) {
...
}Теперь любой поймёт, что в цикле мы перебираем колоду карт. Это указывает другим разработчикам на сущность происходящего, помогает понять контекст выполняемого действия. Такой подход, вдобавок, значительно упрощает изменение подобного значения, так как оно, если и используется в разных местах программы, задаётся лишь в одном месте кода.
То же самое имеет отношение и к работе со строками:
if (userPasswordIsValid($user, "6yP4cZ".$password)) {
...
}Что это за
6yP4cZ? Выглядит как случайный набор символов.Перепишем это:
$salt = "6yP4cZ";
if (userPasswordIsValid($user, $salt.$password)) {
...
}А вот теперь всё оказывается гораздо понятнее.
5. Неаккуратное форматирование кода
Неопрятное форматирование кода — это «болезнь» начинающих программистов. Многие разработчики, имеющие некоторый опыт, обычно утвердительно кивают, отвечая на вопрос о том, знают ли они какого-нибудь тестировщика или дата-сайентиста, который плохо форматирует код. Причина этого заключается в недостатке опыта. Исключение составляют лишь те программисты, которые пользуются языком наподобие Python, в котором форматирование кода влияет на выполнение программы.
Один из самых распространённых способов решения этой проблемы заключается в использовании линтера. Все современные IDE, кроме того, поддерживают возможности по автоматическому форматированию кода. Иногда подобный функционал реализуется средствами плагинов, которые нужно устанавливать самостоятельно, а иногда он входит в стандартные возможности IDE.
6. Значения, жёстко заданные в коде
Если значения жёстко задаются коде в программы, это значит, что данные встраивают прямо в исходный код или в другие подобные объекты. Противоположность такому подходу — получение данных из внешних источников или генерирование их во время выполнения программы.
Жёстко заданные значения не позволяют легко конфигурировать программу. Они, так сказать, «высечены в камне». Подобное считается анти-паттерном, или, как минимум, указывает на явные проблемы в коде.
Чаще всего жёстко задаются пароли и пути к файлам. Делают это по самым разным причинам, иногда они могут быть даже и оправданными.
Например, много жёстко заданных значений можно увидеть в некоторых примерах кода, ответственного за аутентификацию на внешних сервисах или API. Лучше так не делать.
Если некто заметил за собой частое использование значений, жёстко заданных в коде, ему стоит критически оценить свою работу. Дело в том, что обычно применение таких значений — это не лучший способ решения неких задач.
Уважаемые читатели! С какими недочётами в коде вам приходилось сталкиваться?
