Шест съвета за създаването на по-четлив код

Как да се предпазите от проблемите, причинени от собствените си програми

Dzheff Фогел. Председател, Паяжината Софтуер

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

С други думи, ако се създаде бъркотия, аз го изцяло на свой собствен гнездо. Когато три часа сутринта търся грешка в объркващо като програма лош сън "макарони" и да си кажа: "О, Боже мой, какво забавя причинява близкородствено кръстосване написал този кошмар", отговорът на този въпрос може само да бъде: "Това съм Аз" ,

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

Като илюстрация, в тази статия ще разгледам програмата, която е хипотетична компютърна игра, наречена Kill Bad извънземни (Убийте лошите чужденец). Член на тази игра е да контролира космически кораб. Този кораб се движи хоризонтално в долната част и стреля снаряди вертикално. Управлението на този космически кораб ще се извършва, например, с помощта на клавиатурата.

Фиг. 1. Нашата хипотетичен игра

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

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

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

Така че, седнете на бюрото и започнете да пишете код Kill Bad Извънземни игри в езика C ++. Първо, вие се определят обектите, които ще бъдат на космическия кораб, ракети Player, извънземни и техните бомби. След това напишете кода за графичното изображение на екрана на всички тези обекти. След това напишете кода да се движат обекти на екрана в зависимост от времето. И накрая, пишете игра логика, изкуствен интелект, извънземни, програмен код за въвеждане на команди от плейъра клавиатура и т.н.

Неизбежният възниква въпросът - как да направя всичко по-горе, така че крайният кода на играта беше очевидно, не създава затруднения при последваща подкрепа и не представлява нечетливи бъркотия?

И ако се стигне до това, друга препоръка - никога да направите това:

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

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

Съвет 2: Използвайте #define оператор често. Възможно най-често.

Да предположим, че в нашия хипотетичен игра, ние искаме на всеки контакт с извънземна играчът получава десет точки. Този проблем може да бъде решен по два начина. Bad начин:

Един добър начин: В една глобална файл напишете следния ред:

Сега, ако искаме да възложи на играча повече бонус точки, достатъчно, за да напише следното:

Повечето програмисти по някакъв начин ще знаят, че е необходимо да се направи това. Въпреки това, за последователното прилагане на тази концепция изисква самодисциплина. Почти всеки път, когато въвеждате цифров постоянно, то е необходимо да се разгледа внимателно - не я питам в "централна точка". Например, да предположим, че искате да имате площадка с размери 800 х 600 пиксела. Силно ви препоръчваме да зададете размера на областта, както следва:

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

Съвсем ясно е код. След това, когато аз стигнах до заключението, че вълните са твърде кратки или че интервалите между срещания на извънземните са твърде малки, не мога да променя тези стойности и веднага нулират цялата игра.

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

Сега, само една компилация - и играта ще бъде много по-забавно, а дори и по-луд.

Фиг. 2. Игра Убий Лошите извънземни преди константите на климата

Фиг. 3. Игра Убий Лошите извънземни след увеличение от константи (възпроизвеждане, може би трудно, но интересно да се види)

Съвет 3: Не давайте на имената на променливите, които могат да бъдат подвеждащи.

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

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

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

Вероятно щях да съм написал следното:

Всяко недоразумение, причинени от по-късото име, ще бъдат отстранени много бързо, и "разбираемостта" на код се подобрява.

А сега да разгледаме фрагмент от кода, който ще се използва много често да се движат всички чужденци, на екрана. Бих почти сигурно го написали по този начин:

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

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

Съвет 4. Проверете вашата програма за грешки. Можете да направите правят грешки. Да, това сте вие.

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

Когато създавате всякакви процедури / функции винаги трябва да се попита: "Да предположим, умопомрачен престъпник ще я дам най-неподходящи ценности. Тъй като този пухкав част от код, ще бъде в състояние да се предпазите и да запази цялата програма от повреждане? "След това напишете кода си, така че да проверява процедура / функция в присъствието на такива враждебни данни и да ги предпази.

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

Дотук добре. Сега си задайте въпроса: "Какво има в този код може да не е така"

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

Този пример е доста проста. Има и по-малко очевиден проблем (с което аз съм непрекъснато се сблъскват в техните игри). Какво се случва, ако NUM_POINTS променлива ще бъде нула?

Това е един много правдоподобна ситуация. Не забравяйте, че в края на всяка вълна, ние даваме играч бонус точки в зависимост от скоростта на преминаването му. Какво ще стане, ако един играч е твърде бавен, за да действа, и да решим да го дам 0 точки? Много е вероятно, че по време на работата на кода си в 3 часа сутринта, че решите да се обадите процедура change_score и да му дадете стойност 0.

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

Добре. Така че много по-добре.

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

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

Този подход спестява много време и заслужава редовна употреба. Време - най-ценният ни ресурс.

Съвет 5: "Преждевременно оптимизация - коренът на всяко зло" - Доналд Кнут (Доналд Кнут).

Тази фраза не е моя идея. Въпреки това, той е в Уикипедия, и това е така, както изглежда, не е безсмислена.

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

Оптимизация - враг на яснота. Трябва да се отбележи обаче, че в някои случаи е необходима оптимизация. Това е особено вярно за игри. Все пак - и това е много важно - почти никога не се знае предварително какво се нуждае от подобрение, стига да не се тестват реалното функциониране кода с помощта на инструмент, наречен профайлър. (Profiler - е програма, която следи вашата програма и изчислява времето, необходимо за извършване на определени предизвикателства Има една прекрасна програма от този тип намират и използват времето ...)

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

Следвайте това правило не е лесно. От друга страна, в противен случай няма да бъде правило. "Добро" програмен код в неудобно досадно, дори и да работи по-бързо.

Въпреки това, радвайте се! След дълги моите проповеди, че трябва да прекарват повече време и повече време върху него, дойде рядко, безценна, когато ви кажа, че малко мързел е доста приемлив!

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

И накрая, тъй като ние не говорим за болезненото, тук е последната ми съвет:

Съвет 6. Да не се получи умна.

Може да сте чували за съществуването на събитието под името Международна Прикрит C Code Contest - международен конкурс за най-сложен софтуер код в C. Факт е, че езиците C и C ++, с всичките й предимства, могат да създават кошмар заплетени код. Този конкурс демонстрира предимството на ясна "на противоречие на" код - чрез предоставяне на най-безумните програмистите. Чудесна идея.

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

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

Всеки програмист е на приемливо ниво на сложност на генерирания код. Лично аз пиша програми като шофьори типичен баба. По мое мнение, ако вашият C код изисква разбиране на фините разлики между изрази аз ++ и ++ аз, а след това, че е твърде сложно.

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

заключение

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

Ако се занимават с големи количества код и не искам да умра под товар си, искрено се надявам, че моите съвети ще ви помогнат. Стреми се към простота и яснота - това ще ви спести много време и да се отърве от излишни страдания.

Вземете продукти и технологии

• Използвайте пробните версии на IBM софтуерни продукти. на разположение за изтегляне директно от developerWorks, следващия си проект за развитие на Linux.

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