Хардкод — что это в программировании
Хардкод — это ошибка программистов, которая заключается в «принудительном» присвоении переменной какого либо значения, вместо того чтобы присваивать его динамически, в зависимости от ситуации.
Слово hard в переводе с английского означает «твёрдый», а code — «программа, программный код».
Хардкод — одна из главных причин появления в программах разного рода глюков и багов. Хардкод однозначно относится к плохому стилю. Также его можно назвать костылями.
3 греха программиста: Хардкодинг, Говнокодинг и Шизокодинг
Есть 3 проблемы кода, с которыми встречаешься в программировании: Хардкод, Говнокод и Шизокод.
Давайте поговорим об этом.
Хардкод
Это известная всем проблема, когда программист из-за спешки или лени пишет код без учета переменных. Пожалуй самый частый случай — домен сайта. Он может меняться от окружения к окружению и часто доставляет массу хлопот. Тут все просто. В разных платформах это решается по разному. Главное соблюдать соглашения и правила принятые в рамках платформы.
Обычно проблемы этого класса быстро обнаруживаются и легко лечатся.
Говнокод
Это более сложная проблема. Часто субъективная. Грубо говоря — это нарушение стиля кода, принятого в голове, команде или сообществе.
Есть разные стили кода в зависимости от платформы и даже иногда внутри платформы:
Это из мира php. В других сообществах ситуация похожая. Сюда же можно отнести истории про таб, таб через 2 пробела или таб через 4 пробела и т. д.
Здесь же возникает проблема чистого кода… например длинные функции на 3-4 страницы, что критикуется. Это не всегда конечно плохо, но часто можно такие функции сделать короче, разбить на ряд коротких функций, каждая из которых решает свою задачу.
Обычно эти проблемы легко лечатся через софт и контроль принятых стандартов в конкретной команде.
Высший пилотаж, когда разработчик может переключаться между разными стилями кода в зависимости от проекта.
Плохо когда разработчик нарушает стиль кода принятый в команде или считает свой любимый (часто единственно выученный) стиль кода единственно правильным.
Не бывает правильных стилей кода. Бывают утвержденные стили в команде или общепринятые стили.
Тоже относительно простая проблема и легко решаемая.
Шизокод
Вот это менее популярная проблема, но часто наиболее дорогостоящая.
Шизокод — происходит от понятия шизофрении. Выжимка из Википедии:
Тут 2 важных тезиса: раскалывание и слабоумие. Которые являются причинам шизокода.
Идеальный код — тот который не написан. Шизокодеры не знакомы с этим понятием.
Если коротко то шизокод, это код, который нарушает принцип Бритвы Оккама.
Выжимка из Википедии:
Выражается в том что разработчики начинают усложнять код и архитектуру без веских на то причин. Или вескость причин существует только в их воображении.
Есть 2 основных симптома: изобретение велосипедов на костылях и размножение слоев абстракции.
Изобретение велосипедов на костылях
Выражается в том что разработчики ввиду плохой способности обучаться вместо поиска оптимальных решений/методов в рамках платформы и существующей архитектуры начинают изобретать велосипеды/костыли.
- Написание своих CMS/фреймворков птм что у существующих есть фатальный недостаток
- Блог на Symfony. При том что весь мир для этого использует WordPress.
- Интернет-магазины на Laravel, при том что есть WooCommerce (№1 в мире), Magento (тоже хорошо), 1С-Битрикс (на худой конец, лучше чем Laravel)
- Встречал ситуацию когда верстка была на Bootstrap, но разработчик решил написать свои стили для меток (label). Что мешало добавить класс label, который уже есть в Bootstrap?
- Излишним функциям, методам и классам нет исчисления, которые можно было избежать используя уже готовые библиотеки и методы в используемых платформах
Бесконтрольное размножение слоев абстракции: лишние классы, наследования, методы
Внимательный читатель мог заметить конфликт с говнокодом. В одном случае проблем в том что функция или класс слишком длинный, а тут проблема в том что возникает наоборот избыточное дробление сущностей.
Тут нужно отметить что это одна из крайностей, границу которой не всегда просто соблюсти.
С одной стороны плохо все пытаться решать одной функцией на 3 страницы или класс который содержит в себе HTML и механики шаблона и где-то выгоднее разбить код на несколько функций/классов/компонентов, каждый из которых решает свою задачу. Это одна крайность.
С другой стороны плохо простой код разбивать на 5 классов в каждом из которых 3-4 метода по 3-4 строки, со множеством бесполезных наследований, когда можно обойтись одним или двумя с минимальным наследованием или даже без наследования если этого можно избежать.
Последствия лишних и плохих абстракций
Размножение методов, классов, наследований без веских причин — это лишний код и рост слоев абстракции.
У всего есть цена, как и у лишних абстракций:
- удоражается обучение новых разработчиков
- чем больше кода, тем больше точек отказа, тем больше ошибок
- усложняется диагностика и отладка кода
Проблема конечности мыслетоплива
Чем больше слоев абстракции, наследований, методов, тем больше нужно мыслетоплива для изменений, улучшений и диагностики проблем.
А рабочий объем мыслетоплива конечен и часто его нехватка влечет очень большие затраты на разработку.
Каждый разработчик, который делал диагностику и изменение шизокода упирался в дефицит мыслетоплива. Но не все это осознавали.
Видео, в котором объясняется что такое мыслетопливо и дается простое упражнение на 1 минуту, которое позволяет вспомнить ощущение дефицита мыслетоплива на простом примере:
Это наезд на ООП, классы и наследование?
Отнюдь. Однако доля правды в этом есть. В функциональном стиле проще наговнокодить, но шизокодить там сложно. ООП же с одной стороны дает множество преимуществ, но и открывает простор для шизокода.
ООП, классы и наследование — это не плохо и не хорошо. Это инструменты. Я лично их использую.
Однако у меня есть ряд собственных правил:
- Классы пишу почти всегда из-за инкапсуляции, но часто мне хватает Синглтонов, статических методов и stateless
- Там где есть частоиспользуемый метод — пишу функции, которые часто являются лишь обертками для методов какого-либо класса, но иногда функция это просто функция без класса и это хорошо там где уместно.
- Классы stateful — да, но реже и опять же только там где есть веские причины
- Наследования еще реже, и только там где на то есть веские причины (стараюсь уменьшать слои абстракции и экономить мыслетопливо в команде)
Резюме
Мы много говорим о хардкоде и говнокоде т.к. они понятны и легко осязаемы. А вот шизокод часто остается безнаказанным, птм что его сложнее выявить и понять объем вреда от него. А объем вреда от него возможно больше чем можно представить с наскоку.
Что на самом деле нельзя хардкодить
Это страшное слово — хардкод. Все боятся это сделать, но иногда каждый из нас это делает.
Но я утверждаю, что хардкод в привычном нам понимании вовсе не так уж страшен, и на самом деле гораздо страшнее, когда в коде прописывают кое-что иное.
Так что же на самом деле нельзя хардкодить?
Классический хардкод
Все обычно считают, что
- Нельзя хардкодить числа в коде! Надо вынести в константу.
- Нельзя хардкодить настройки в коде! Надо вынести в файл с настройками (а у некоторых и в базу данных).
То есть если джуниор девелопер напишет в коде if (age >= 23) , ему за это надо дать по рукам. Так обычно считается. Чтобы сберечь руки, он должен срочно вынести “23” в константу типа MINIMUM_LOAN_AGE .
Давайте разбираться в причинах
А почему плохо прописать в коде “23”?
Обычно называют две причины. Их втирают нам в сознание ещё с университетской скамьи.
Когда нужно будет поменять “23” на “24”, её придётся поменять во многих файлах — трудоёмко.
Само по себе “23” плохо читается. Что означает “23” — возраст, длину волос, объём бензобака? Почему именно 23, а не 22 или 24?
Почему эти причины не катят?
Эти причины настолько нам привычны, что мы даже не задумываемся, насколько они актуальны в наше время. Вы удивитесь, но не очень-то актуальны. Прямо скажем, они устарели. Смотрите сами.
Во всех современных IDE очень легко поменять “23” на “24”. Одной кнопкой. Ctrl+R -> Enter. Всё. Хоть у тебя в проекте три файла, хоть три миллиона.
Да, “23” плохо читается. Но часто при вынесении в константу оно не становится более читаемым. Да, название константы MINIMUM_LOAN_AGE говорит о том, что это минимальный возраст, с которого можно брать кредит. Но и выражение if (age >= 23) в методе canRequestLoan() говорит ровно о том же ничуть не хуже.
А почему именно 23, почему не 22 или 24 — это всё равно непонятно. Чтобы это узнать, в наше время легче заглянуть в историю изменений (git -> annotate) или в тесты (Ctrl+Shift+T) — с нашими IDE это легко.
Ладно, ладно
Я знаю, вас переполняют эмоции. Вы хотели бы вбить мне в грудь осиновый кол за такую ересь. Но потерпите, сейчас мы дойдём до главного.
Конечно, всё-таки выносить такие штуки в константы иногда полезно.
Я хотел сказать, что самый страшный хардкод — это вовсе не константы.
А что же — самый страшный хардкод?
Вглядитесь внимательно в это выражение. Все обычно думают, что самый страшный хардкод — это вот: 
Но вглядитесь, неужели это действительно самое страшное место? Оглядитесь вокруг, не притаилось ли рядом что-то более опасное? На самом деле самая страшная часть — это вот: 
Потому, что вот её-то поменять во всём коде на порядок сложнее. Когда однажды выяснится, что для получения кредита нужно стать старше 23 лет, да ещё и найти работу, нам придётся найти в коде все места, где прописано if (age >= 23) и поменять их на if (age > 23 && employed) . Но как найти все знаки все знаки >= ? Их же тысячи! Вот это ручная работа на столетия!
Но самое страшное, что в коде могут быть и выражения вида
- if (!(age < 23)) , и
- if (23 > age) ,
и даже такие места, которые совсем нереально обнаружить:
Что же делать?
Вот почему важно выносить не константы, а логику. Важно следить, чтобы любое знание в коде было прописано ровно в одном месте. В данном случае — знание о том, в каких случаях клиент может взять кредит (то самое >= 23 ) должно быть вынесено в отдельный метод.
И все остальные места должны использовать этот метод. Кажется тривиальным? О нет. Если это знание действительно в одном месте, зачем вы так рьяно хотите вынести “23” в константу?
Упростим
Всё ещё кажется тривиальным? Ок, давайте упростим пример. Забудьте 23. Пусть будет 0.
Я уверен, в вашем коде миллион таких мест:
И я таких видел миллион. if balance > 0 прописан и на странице платежей, и на странице кредитов, и депозитов, и т.д.
Но однажды приходит новое требование: клиент не может сделать платёж, если на его счёт наложен арест. Нам приходится добавить условие типа такого:
Но тут… опачки. Оказывается, что в десяти местах прописано if (balance > 0) , в ещё двадцати — if (balance <= 0) , а в грёбаном яваскрипте и вовсе if (account.balance) .
И вот тут-то начинаются проблемы. Все эти места нужно анализировать отдельно. В некоторые из них нужно добавить && !arrested , а в некоторые не нужно — ведь там речь идёт не о платежах.
Я не придумываю, это абсолютно реальный пример.
Юнит-тесты
Очевидный плюс вынесения логики в методы — её легко тестировать.
Поначалу этот тест кажется даже избыточным и даже бесполезным:
Но всё меняется, как только добавляются ньвые требования:
Пэдж обжекты
Всё ещё кажется, что для разумных людей это очевидные вещи?
Тогда посмотрите на пэдж обжекты — воплощение константного антипаттерна во всей красе! Миллионы людей выносят локаторы в константы и даже не задумываются, что что-то здесь не так…
What does "hard coded" mean?
My assignment asks me to access a test.txt document, so the file name has to be hard coded to my C drive. I have no idea what hardcoding means. Can somebody please help me with this?
4 Answers 4
«hard coding» means putting something into your source code. If you are not hard coding, then you do something like prompting the user for the data, or allow the user to put the data on the command line, or something like that.
So, to hard code the location of the file as being on the C: drive, you would just put the pathname of the file all together in your source code.
Here is an example.
The file name is «hard coded» as: C:\myfile.txt
The reason the backslash is doubled is because backslashes are special in C strings.
"Hard Coding" means something that you want to embed with your program or any project that can not be changed directly.
For example, if you are using a database server, and hard code to connect your database with your project, then that can not be changed by the user.
Scenario
In a college there are many students doing different courses, and after an examination we have to prepare a marks card showing grade. I can calculate grade two ways
1. I can write some code like this
2. You can ask user to enter grade definition some where and save that data
Something like storing into a database table 
In the first case the grade is common for all the courses and if the rule changes the code needs to be changed. But for second case we are giving user the provision to enter grade based on their requirement. So the code will be not be changed when the grade rules changes.
That’s the important thing when you give more provision for users to define business logic. The first case is nothing but Hard Coding.
So in your question if you ask the user to enter the path of the file at the start, then you can remove the hard coded path in your code.