Добре написан код = Щастливи клиенти, разработчици, мениджъри, потребители…

Писането на код е като готвенето. Каквото и да правите, някой ще дойде при вас и ще ви каже да добавите повече сол, захар, подправки и т.н.

Същото важи и за писането на код. Начинът, по който пишете своя код, е ваша работа и някой в ​​крайна сметка ще погледне кода ви и ще ви каже как бихте могли да напишете тази функция по-добре. Разбира се, има много правилни начини за писане на код, така че как да разберете кой да изберете?

Започнах да кодирам професионално преди около 3,5 години. Все още съм нов в много концепции и някои концепции просто ми минават през главата. Всеки път, когато започна да кодирам функция, прекарвам много време в тревоги дали пиша оптимизиран код или как моят много опитен колега ще го напише. Това е мястото, където прегледите на кода помагат и трябва да разберете, че те са важна част от вашето професионално пътуване като софтуерен програмист.

Има някои прости насоки, които можете да следвате, за да гарантирате, че прегледите на кода остават верни на предназначението си, намиране на потенциални грешки и осигуряване на изпращане на код с добро качество.

Не пишете код, от който нямате нужда

Мо код, мо проблеми.

Колкото повече код пишете, толкова повече ще се нуждае от поддръжка. Пишете по-малко код, премахнете кода, който не ви трябва. Контролът на версиите винаги ще помогне да се върнете назад във времето и да се върнете, ако е необходимо.

Същото с коментирания код, ако коментиран блок влиза в издание, премахнете го. Това помага да запазите кодовото си пространство чисто и лесно за разбиране.

Използвайте последователни стилове на код

Няма правилен или грешен начин за отстъп на вашия код. Въпреки това, който и стил да изберете, останете последователни с него.

Нека си признаем, това е досадно:

if (hour < 18) {
greeting = "Good day";
}else 
{
greeting = "Good evening";
}

Както w3.org, правилно споменава:

Браузърите са много прощаващи, когато става въпрос за синтаксиса на JavaScript. Това обаче не трябва да е причина да пишете небрежен код, който разчита на браузъри, за да работи.

Обикновено използвам ESLint, който е наличен във всички основни IDE като плъгин, когато пиша JavaScript код. Наличието на последователен стил прави кода ви да изглежда красив и други разработчици могат бързо да прочетат кода ви.

За Python ръководството за стил PEP8 е може би най-утешителното и предлага удобен инструмент за команден ред, така че да можете да тествате вашите файлове на Python.

Структура на файлове и папки

Ако сте начинаещ, който започва първия си проект, изглежда има смисъл да напишете целия си код в няколко файла. Въпреки това, когато проектът ви стане по-сложен и грешките започнат да се трупат, ще разберете, че това не е добра идея.

Поддържането на вашия код в един или два файла затруднява отстраняването на грешки и дори най-умните разработчици забравят къде се намира всяка функция.

Преди да започнете да пишете код, уверете се, че сте разделили кода си на функции и модули и ги дръжте логически разделени. Това ще ви помогне да поддържате кода си в дългосрочен план.

DRY - Не се повтаряйте

Ако пишете част от кода отново за трети път, време е да извлечете тази част от ценната логика и да я поставите в помощен клас, който можете да импортирате навсякъде. Има много случаи на употреба, които могат да се използват като помощни класове, като функции за формат на дата или низ или функции за регистриране.

Представете си сценарий, при който форматирате дата в ММ-ДД-ГГГГ в различни файлове във вашата кодова база и изведнъж вашият клиент решава да превключи на формат ДД-ММ-ГГГГ, представете си какъв ужас! Ще трябва да прегледате всички файлове и ако пропуснете някой от тях, ще получите сочен доклад за грешка.

Ако сте използвали помощен клас, всичко, което трябва да направите, е да редактирате само тази функция!

Както казах по-рано, Mo код, Mo проблеми.

Модулирайте своя код

Ако функция или метод надхвърли 30 реда код, помислете дали да не ги разделите. Добрият максимален размер на модула е около 500 реда.

Малките парчета код са по-лесни за разбиране и отстраняване на грешки.

Пишете отбранително.

Винаги мислете какво може да се обърка, какво ще се случи при невалиден вход и какво може да се провали, което ще ви помогне да хванете много грешки, преди да се случат.

Това вероятно е една от най-пренебрегваните концепции. Разработчиците трябва да разберат, че потребителят не разбира потока на продукта и е длъжен да изстреля ядрена ракета, докато се опитва да разгадае вашето приложение.

Така че трябва да помислите за сценарии с невалидно въвеждане и случаи на грешка и да се уверите, че вашият код връща подходящ отговор за грешка, а не просто неясна грешка като „Грешка“.

QA инженер влиза в бар.

Поръчва бира. Поръчва 0 бири. Поръчва 99999999999 бири. Поръчва гущер. Поръчки -1 бира. Поръчва ueicbksjdhd.

Първият истински клиент влиза и пита къде е банята. Барът избухва в пламъци, убивайки всички. 🔥

Използвайте смислени имена на променливи

Всеки път, когато видя файл, пълен с променливи като i, j, k, abc и т.н., затварям редактора си и избягвам файла като чума.

Разбирам, че е трудно да се измислят смислени имена за всяка променлива, но моля, направете го, струва си усилието. Това прави вашия код по-малко чужд и лесен за четене и разбиране.

Също така не прекалявайте и наименувайте променлива aVeryMeaningfulButExtremelyLongNameForThisVariable.

Това не е ракетна наука

Не, не казвам, че писането на код е лесно. Казвам го така, както е точно. Това не е ракетна наука (освен ако не работите в космическа агенция - не се колебайте да пропуснете тази част).

Повечето от функциите, които разработвате, и грешките, които разрешавате, могат да бъдат разделени на по-прости, разумни блокове. Не прекалявайте с проектирането на неща, които не трябва да бъдат поставени в ракетен кораб и изстреляни в космоса.

Не забравяйте, че прекомерно проектираният код е толкова труден за разбиране и поддържане, колкото недостатъчно проектираният код.

Коментирайте вашия код!

Като се има предвид това, не коментирайте всеки ред в кода си. Функции, които изпълняват сложна задача, или фрагменти, които разрешават неясен бъг, заслужават да бъдат коментирани.

Освен това коментарите са наистина трудни за поддържане в дългосрочен план, тъй като вашият код се променя. Повечето разработчици забравят за актуализирането на коментари след промяна на функция. След това подобни коментари се превръщат в горивото на вашите кошмари.

Заключение

Ето! Това са някои от най-добрите практики, които трябва да следвате, когато пишете код. Мислете за това като за създаване на наследството, което оставяте след себе си, докато преминавате към различни проекти. Разработчикът, който поема вашия код, трябва да ви благодари, че сте написали чист и лесен за разбиране код!

Честито кодиране! ❤️