#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);

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

Красота! Жаль это пост её и испортит(

#BadPractice
Наличие не используемых using

Хоть компилятор не ругается на ошибки при наличии не используемых using, но это имеет несколько негативных последствий:

1. Увеличение времени компиляции: Каждая using-директива добавляет пространство имен в область видимости компилятора. Это может немного увеличить время компиляции, особенно в больших проектах.

2. Загрязнение глобальной области видимости: Если добавить несколько using с одинаковым именем из разных пространств, то это приведёт к конфликтам имён - придётся прописывать полное имя.

3. Снижение читаемости кода: Шум в начале файла может отвлекать или сбивать разработчика - возможно этот using используется в !Unity_Editor зоне

Руководство от Unity для создания мультиплеер игра

"Эта электронная книга:

-Ознакомьтесь с основными понятиями Unity Multiplayer.

-Изучите различные Multiplayer системы и сетевые модели.

-Простой пример использования Netcode for GameObjects"

Немножко о стилистике.

В какой-то момент понял что мне удобней читать вариант if в подобной стиле:

if (isFruit
    && isEdible
    && isRipe
    || isExists)

Чем в стиле:

if (isFruit &&
     isEdible &&
     isRipe ||
     isExists)

Просто по тому что сразу понятно где стоит && а где ||. И если в данном случае примеры короткие, сразу можно увидеть, но в длинным методах проверки, например, quizEntity.gameType.Value == QuizGameType.Learning уже сложнее увидеть быстрым взглядом.

#BadPractice

Ещё один пример нейминга. Угадайте что это, потому как я не знаю:

AHAndHWindowInRegimMistakeSystem

Не сокращайте там, где это сокращение не очевидно

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

Как же давно это было...

Унитеки: "Это будет новый успешный провал!"

Когда платят за кол-во символов)

Как невротик пишет код