Что такое хард код

ТОП-10 признаков плохого кода: хардкод и спагетти-код в примерах на JavaScript

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

Большинство младших программистов (и даже некоторые более опытные) не знают, как отличить хороший код от плохого. Когда программа заработает — они сразу идут дальше. К тому же, если они работают в одиночку, то никогда даже не узнают, что пишут плохой код.

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

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

1. Повсюду скопированный код

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

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

Конечно, ведь всегда проще скопировать-вставить, чем написать функцию. Но вопрос состоит в том, когда подобный метод применим, а когда — только навредит кодовой базе?

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

1. Экономия времени, ведь функции изначально предназначены для подобного, верно?
2. Чистый, структурированный код, который легко понять.
3. Потенциал повторного применения функции в других проектах.
4. Легкость удаления мусорного кода.
5. Удобство в отладке.

2. Одинаковые функции, но разный интерфейс

Постоянство — качество хорошего программиста: старайтесь следовать шаблону, ведь вам придется написать еще очень много функций.

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

Проверка заключается в том, что при совпадении входных данных с данными о пользователе булевы функции возвращают true , а при несовпадении — возвращают false .

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

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

3. Хардкод

Все ненавидят жесткий кодинг, “хардкод”. Хорошо, что его появление легко заметить и предотвратить. Проанализируйте следующий фрагмент кода:

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

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

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

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

4. Слишком длинные и сложные условия

Определение достаточно абстрактное, так что же имеется в виду?
Во-первых, не стоит писать “спагетти-код” — слишком конкретные и длинные условия со множеством проверок и категорий.

Тем не менее, второй совет — противоположность первого:
НЕ пишите сложные условия ради экономии в пару строк. Если вам придется написать две лишние строки, но код станет понятнее, то пишите эти строки с уверенностью. Проанализируйте следующие два примера:

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

5. Велосипед вместо встроенной функции

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

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

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

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

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

6. Игра в загадочные имена

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

Давайте рассмотрим простой пример: getABC() .

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

Посмотрите на следующее название: getUserNameFromDB() . Идентификатор метода явно сообщает о предполагаемом результате выполнения.

Некоторые программисты так сокращают название, что становится трудно расшифровать его полную версию. handleBtnClick , getConfig или parseInfo легко понять. Но hndleBtnClk , getCnfg уже слишком коротки. Отбрасывая скуку, рассмотрим ситуацию из жизни:

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

7. Сплошь глобальные переменные

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

Почему? Много причин для превалирования локальных переменных над глобальными. Поговорим о некоторых основных:

1. Меньше ошибок и неожиданных результатов.
2. Когда вы получаете ошибки, то их легко найти.
3. Серьезное упрощение рефакторинга кода.
4. Другим программистам в сотни раз сложнее читать ваш код, когда в нем повсеместно применены глобальные переменные.

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

8. Запутанный код

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

Однажды программист ответил, что запутанный код делает компанию зависимой от него — работа ему обеспечена.

Но это очень неправильная концепция, крайне вредная идея. Гораздо лучше руководствоваться следующим:
“Загадочность” — плохо. “Легкость” — хорошо.

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

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

9. Взаимозависимые функции

Код весьма плох, когда функции выполняются исключительно в строгом порядке. Рассмотрим пример:

Откуда другим программистам знать, что перед процедурой begin() надо вызвать процедуру start() ?

Функции работают независимо друг от друга.

Решением “на каждый раз” послужит специальный метод-шаблон. Рассмотрим пример на языке программирования JavaScript:

Когда все же необходимо вызывать функции по порядку, то пишется одна внешняя функция start() , со множеством внутренних, вроде begin() , preparing() и end() . Кроме того, внешней функции start() присваивается идентификатор, явно отражающий ее функционал.

10. Нет понимания сложности алгоритма

Начинающие программисты часто пишут лишние вложенные циклы. Тем более, когда менталитет “достаточно выполнить работу и запустить код” превращает программиста в неэффективного лентяя. Правда, производительность приложения — скорее дело привычки:

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

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

Многие программисты даже не знают про “сложность алгоритма по памяти” или “memory complexity”. Если вы не знаете, пожалуйста, узнайте, ведь это поможет на собеседованиях.

Выводы

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

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.

Что на самом деле нельзя хардкодить

Это страшное слово — хардкод. Все боятся это сделать, но иногда каждый из нас это делает.

Но я утверждаю, что хардкод в привычном нам понимании вовсе не так уж страшен, и на самом деле гораздо страшнее, когда в коде прописывают кое-что иное.

Так что же на самом деле нельзя хардкодить?

Классический хардкод

Все обычно считают, что

• Нельзя хардкодить числа в коде! Надо вынести в константу.
• Нельзя хардкодить настройки в коде! Надо вынести в файл с настройками (а у некоторых и в базу данных).

То есть если джуниор девелопер напишет в коде 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 , а в некоторые не нужно — ведь там речь идёт не о платежах.

Я не придумываю, это абсолютно реальный пример.

Юнит-тесты

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

Поначалу этот тест кажется даже избыточным и даже бесполезным:

Но всё меняется, как только добавляются ньвые требования:

Пэдж обжекты

Всё ещё кажется, что для разумных людей это очевидные вещи?

Тогда посмотрите на пэдж обжекты — воплощение константного антипаттерна во всей красе! Миллионы людей выносят локаторы в константы и даже не задумываются, что что-то здесь не так…

Хардкод — что это такое? Определение, значение, перевод

Хардкод (hardcode) это распространенная ошибка программистов, которая заключается в «принудительном» присвоении переменной какого либо значения, вместо того чтобы присваивать его динамически, в зависимости от ситуации. Слово hard в переводе с английского означает «твёрдый», а code — «программа, программный код». Хардкод — одна из главных причин появления в программах разного рода глюков и багов.

Не следует путать хардкод с хардкором.
Метки / Компьютеры