• Используйте camelCase для переменных/аргументов и параметров.
  • Используйте регистр Pascal для имен классов, функций, свойств/полей/членов (обычно следующий: https://msdn.microsoft.com/en-us/library/x2dbyw72(v=vs.71).aspx)
  • Анонимные функции/лямбда-выражения не должны превышать ~20 строк кода, если только для этого нет конкретного варианта использования. Вместо этого вы можете использовать именованную встроенную функцию или традиционное определение.
  • Ширина одной строки кода не должна превышать примерно 1000 при размере шрифта 10pt. (это около 100-150 символов в зависимости от вашего монитора)
  • Тернарные операторы никогда не должны расширяться более чем на две строки. Один уровень троичной вложенности допустим, если он легко читается и для этого есть веская причина, в противном случае вообще не используйте вложенность.
  • Функции утилит, такие как ведение журнала и отправка электронной почты, должны быть заключены в другую функцию в случае их изменения, поэтому изменение необходимо вносить только в одном месте.
  • В целях устранения неполадок только одна функция может быть вложена один раз в другую функцию при выполнении функции return для передачи в качестве аргумента другой функции. В качестве примера: fn(fn()) в порядке, fn(fn(),fn()) в порядке, но fn(fn(fn())) не в порядке.
  • Регулярные выражения следует использовать только для простых задач или разбивать на несколько более простых операторов регулярных выражений. Следует избегать одной гигантской строки RegEx.
  • _ следует использовать для обозначения приватного в языках, которые в противном случае не имеют приватной функциональности, в противном случае следует полностью избегать этого символа.
  • Как правило, один файл никогда не должен превышать 500 строк кода, а цель — 20–200 строк. Если в файле меньше 20 строк, и он может находиться в другом месте, вы можете подумать о его перемещении. В противном случае не думайте, что у вас не может быть такого маленького файла, если он кажется совершенно не связанным со всем остальным.
  • Вкладки/отступы в одном файле никогда не должны превышать 5 уровней отступа, если только вы не имеете дело со встроенными структурами данных, и даже в этом случае вы можете рассмотреть возможность помещения структуры в другой файл.
  • Регионов, если они доступны на каком-либо языке, следует избегать. Если они необходимы для организации кода, код следует разбить на несколько файлов и организовать соответствующим образом.
  • Комментарии должны либо: А) Объяснять, почему вы сделали что-то странное, либо Б) Объяснять очень сложный блок кода. Он никогда не должен объяснять простой блок кода, который легко понять. Вы также никогда не должны писать очевидные вещи. В качестве примера: «//Функция, которая имеет цикл foreach, который создает сотрудников», и только если вам нужны комментарии для A и B, переименуйте ее в «//Создает объекты сотрудников».
  • Всегда помещайте комментарий в строку перед тем, что он описывает, размещение его рядом со строкой кода может привести к проблемам с форматированием позже.
  • Всегда называйте методы и свойства описательно. Хороший код с исключениями, перечисленными в пункте выше, не требует большого количества комментариев.
  • Избегайте использования префиксов ведущих типов, таких как intMyNumber. Единственный случай, когда это может иметь смысл, — это когда могут возникнуть конфликты имен переменных между чем-то вроде перечисляемого типа и переменной этого типа. В подобных случаях всегда используйте префикс наименее распространенной переменной или типа. Другими словами, для перечисления я мог бы использовать enEmployeeType и EmployeeType в качестве имени моей переменной.
  • Если возможно, никогда не дублируйте код. Двух вариантов использования достаточно, чтобы оправдать обобщение (например, общий метод), но вам действительно следует обобщать свой код, если у вас есть 3+ варианта использования одной и той же функциональности.
  • Краткость отличная, Читабельность хорошая. Другими словами, лучше сократить ваш код и сделать его немного менее читаемым, чем иметь длинный растянутый код, который читается. Тем не менее, замена огромного количества кода однострочным вложенным беспорядком также не идеальна. Другими словами, стремитесь к краткости, а не к удобочитаемости, но будьте осторожны, чтобы не зайти слишком далеко, иначе вы можете создать нечитаемую, не поддающуюся ошибкам катастрофу.
  • В таких языках, как C#, которые поддерживают интерпретацию типов переменных на основе компилятора, таких как var, всегда печатайте тип данных, если он не очень длинный. Вариантами использования var могут быть дженерики или громоздкие пространства имен.
  • Избегайте динамики/использования слабых типов в языках, которые поддерживают сильные типы, если только этого не требует очень конкретный вариант использования. На самом деле я столкнулся только с одним случаем: когда вы загружаете данные, структура которых вам неизвестна, возможно, это веб-служба, которая возвращает три разных типа структур, и в этой структуре есть информация, которую вы можете использовать для ее вывода. В этом случае вы должны сохранить его динамичным, найти структуру, а затем составить строго типизированную структуру.
  • В таких языках, как JavaScript, где есть несколько способов сделать одно и то же, попробуйте придерживаться одного варианта. Например, если вы используете класс в JavaScript, оставайтесь с классом и старайтесь избегать использования функций в качестве классов.