Нейминг

1. Следуйте правилам нейминга, используйте семантику

2. Не использовать сокращения

3. Использовать общепринятые английские термины для нейминга классов/свойств/методов

   1. Не используйте транслитерацию

   2. Не используйте машинный перевод для исконно русских терминов

   3. Не используйте системные/зарезервированные термины в ваших классах

      Пример плохого нейминга:

      // Метод добавления студента в подпоток 
      class Thread { 
      	void Join(Student student) { … } 
      }
      

4. Познакомиться с кодстайлом, префиксами для интерфейсов

Do:

1. Следуйте кодстайлу

2. Следуйте правилам семантического нейминга комитов

3. Использовать конструкторы для создания полностью инициализированого объекта

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

5. Проверяйте может ли метод выполниться с переданными аргументами, если эти аргументы - это пользовательский ввод.

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

7. Минимизировать использование статических методов, полей и классов. Если в коде была использована статика, то нужно обозначить комментарием почему это решение лучше в таком виде, нежели без статики.

8. Стараться минимизировать вложенность за счет инвертирования условий.

9. Делать всю возможную валидацию аргументов в конструкторе (например, на null)

10. Стараться делать типы иммутабельными. Особенно в кейсах, где мутабельность объекта нужно для инициализации вне конструктора:

    // Плохо:
    var group = new Group(); 
    group.Name = "Tasks";
    
    // Хорошо:
    var group = new Group("Tasks"); 
    

11. Поддерживать инвариант типа. Никакое изменение не должно делать экземпляр класса не валидным.

12. Разделять бизнес логику и логику работы с UI. Разделять логику, парсинг аргументов и валидацию

13. Если есть зависимость от внешних сущностей, то их нужно прокидывать аргументами.

14. Бросать понятные ошибки бизнес логики (т.е. не из namespace'a System). Обрабатывать возможные NRE, OutOfRange etc и вместо них бросать понятные. Сообщения ошибок стоит писать на английском. Если хочется поддержать русский, то нужно смотреть в сторону локализации.