#BadPractice

Пример того как человек потерялся в стилистике кода:

public class BoosterSettings
{
    public bool _enabled;
    public BoosterType _typeBooster;
    public bool LB;
    public bool QB;
    public bool vE;
    public bool vP;
    public bool oG; //useOneInGame
    public uint resId;
    public Sprite _sprite;
    public Sprite _spriteActive;
}

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

Каждый начинающий игродел

Вот и пошёл 6й год моей работы в GameDev в роли Unity Developer.

Мой путь был сложен, но при этом интересен.

В начале пути мне было даже физически больно перестраивать мозг под код. До этого я лишь баловался вёрсткой на HTML. Да и несколько лет вообще жил без компьютера.

Сначала я работал в профессии, не связанной с IT, а вечерами и в выходные учить C# и Unity.

Только через год такого самостоятельного обучения, создав свой первый полноценный игровой проект под Android, выпустив его на GooglePlay, решился начать зарабатывать на фрилансе.

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

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

Так получилось, что большинство проектов, которые я разрабатывал были мобильными, но успел пробежаться по всем доступным Unity платформам, кроме приставок.

За это время верстал UI (много, слишком много…), писал логику под физику 2D и 3D, делал пазлы, шутеры, догонялки, обучалки, симуляторы, квизы, разные ГК, VR, AR и многое другое. Успел поработать с ООП и несколькими ECS архитектурами и понял, что ООП мне ближе и удобней.

Сделал несколько законченных пет-проектов и несколько так и не завершённых (может быть, часть из них я таки издам… но это другая история)

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

Процесс багафикса

Вышел на улицу после целого дня багафикса в легами

Герб любой разработки

#BadPractice
Пример стиля, который не стоит использовать:

if (!item.Right) { ++count; tList.Add(item); }

Машина всё стерпит, а вот ваши коллеги этого не поймут. Читается сложно, особенно когда пытаешься найти что сломалось. Часто пробегаешь по началу строки и ищешь логику ниже if.
Название переменных тоже ничего не говорят.
Можно переписать так:

 if (!progressAnswer.Right)
 {
     ++count; 
     progressAnswers.Add(progressAnswer);
 }

#BadPractice
Не делайте так!
Если вы понимаете, что название переменной не понятно с первого раза - переименуйте, не нужно писать комментарий с полным именем. Современные IDE могут изменить название в пару кнопок. Не усложняйте себе и другим жизнь

#BadPractice
Ещё один пример плохого стиля:

 for (var i = 0; i < _availableCells.Length; i++) _availableCells[i] = -1;
        _availableCellsIndex = 0;

Код вообще не читается. Первое восприятие что в цикле используется обнуление - _availableCellsIndex = 0; и это сильно сбивает с толку

Как можно оформить:

for (var i = 0; i < _availableCells.Length; i++)
{
   _availableCells[i] = -1;
}
                
_availableCellsIndex = 0;

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

#BadPractice
Лишнее объявление переменой с передачей значения часто сбивает с толку.
Например:

bool show = true;
show = levelEnt.isLevelOpened;  

Можно заменить на:

bool isLevelOpened = levelEnt.isLevelOpened;  

И сразу становится понятно что означает переменная. Так же стоит её переименовать.

#BadPractice
Спорная практика, но всё же.
Упрощение написание кода в одну строку позволяет ускорить понимание общей логики.
Например, мы можем вместо:

private bool Duel(QuizEntity quizEnt)
{
  bool duel = false;

  if (quizEnt.hasMode && quizEnt.mode.Value == QuizModule.QuizMode.Duel)
      duel = true;

  return duel;
}

Написать в одну строку:

private bool Duel(QuizEntity quizEnt)
{
  return quizEnt.hasMode && quizEnt.mode.Value == QuizModule.QuizMode.Duel;
}

#BadPractice
Просто не делай так:

if (cellMoveEnt.wagonInfo.currentRailIndex + 1 == cellMoveEnt.wagonInfo.rails.Count
   && cellMoveEnt.wagonInfo.railsLoop) cellMoveEnt.wagonInfo.currentRailIndex = 0;
else cellMoveEnt.wagonInfo.currentRailIndex++;

Код абсолютно не читаем.
В таких случая лучше всегда использовать скобки, что бы выделить логику:

if (cellMoveEnt.wagonInfo.currentRailIndex + 1 == cellMoveEnt.wagonInfo.rails.Count
    && cellMoveEnt.wagonInfo.railsLoop)
{
   cellMoveEnt.wagonInfo.currentRailIndex = 0;
}
else
{
   cellMoveEnt.wagonInfo.currentRailIndex++;
}

#BadPractice
Ещё один пример if без скобочек. Найдите логику исполнения😉

if (!neighborCellView.cellEntity.isCellOfFlow &&
    neighborCellView.cellEntity.cellAvailable.Value &&
    !HaveAnsweredNeighbor(neighborCellView.cellEntity) &&
    !neighborCellView.cellEntity.isCellIgnoreReset)
    neighborCellView.cellEntity.ReplaceCellAvailable(false);

Этот шедевр даже править не буду. Пусть останется для следующих поколений