ОСНОВЫ НАПИСАНИЯ КОДА
Основная задача написания не просто кода, а хорошего кода – увеличение скорости разработки продукта.

Для структурирования правил написания вашего кода лучше придерживаться одной из парадигм программирования. Для разработки игр отлично подходит парадигма ООП.
КРИТЕРИИ ХОРОШЕГО КОДА

Работающий

код должен исправно функционировать и выполнять свою функцию

Понятный

когда кто-либо другой смотрит ваш код – он понимает , как он работает

Расширяемый

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

Удобный

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

Шаги для ускорения процесса написания игры

Правильно располагать файлы в проекте

Для того, чтобы вы не тратили время на поиск нужного файла кода лучше структурировать вашу систему хранения. Не нужно разделять папки по типам файлов. Папки Classes, Interfaces, Enums не помогут вам найти нужный класс или интерфейс.

Структурируйте файлы так, чтобы вы смогли оперативно найти нужную вам сущность. Рекомендуется хранить все файлы соответствующей сущности в одной папке, за редким исключением. Так вам будет намного удобнее работать с ней и расширять её код, а проверяющим будет проще проверить вашу работу.

ВЕРНО

НЕВЕРНО

Понятно называть сущности

Чтобы вы смогли спустя продолжительный промежуток времени вернуться к своим классам и их методам – называйте их правильно.

• Название любого метода должно содержать глагол (GetDistanceToTarget / DistanceToTagret)
• Название метода должно отражать его функциональность (SetDistanceToTagret / SetValue)
• Названия классов не должны содержать глагол(ValueGetter / ValueGetClass)
• Названия переменных должны быть понятны (distance / d или ds или sdfsdfsdf)
• Все названия пишутся словами английского языка (Splitter \ Razdelyitel)
• Любое название не должно быть длинным (GetDistanceToURFU \ GetDistanceToUralFederalUniversityOfBorisNikolaevitchYeltsin)

Придерживаться парадигмы ООП

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

Чтобы избежать этих проблем – придерживайтесь ООП.

ЗАЧЕМ?
Хороший код нужен для того, чтобы его могли быстро прочитать другие люди и не тратить время на поиск ошибок и рефакторинг. Поэтому учиться его писать нужно как можно раньше.
А если не сделать? А если не сделать?