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