Очевидното: код.

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

Тестове

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

Игри и друг GUI intensive софтуер

Когато сте избрали да пишете неща, наподобяващи игри — или каквито и да е други проекти, изискващи сериозно GUI — постарайте се да "откачите" основния си код максимално много от рисуването/графиката/GUI-то. Целта ви е да имате много ясно разделение и абстракция между "ядрото" на вашия проект и графичния му интерфейс. Добре би било основната логика на проекта ви да се намира изцяло в "ядрото", под формата на пакети, типове и прочее, като това ядро предоставя на своите ползватели някакво API. Тоест, стремите се да пишете въпросното ядро все едно пишете библиотека, която ще се преизползва в друг(и) софтуер(и). От там нататък, GUI-то се прави като wrapper на тази библиотека, ползва публичното ѝ API и е един вид pluggable компонент към нея.

Можете да минете и само с кода от основното ядро, който имплементира функционалност без GUI, ако сте писали обилно тестове. Този проект е подходящ шанс за вас да пробвате подхода TDD. Допълнително, това ще ви помогне да покриете едно от изискванията, а именно да имате пълно покритие с unit тестове.

GUI-то е добре да е съвсем просто и може да минете без особено тестване там, освен, евентуално, някой друг интеграционен тест. Може да минете и с най-просто и дървено конзолно UI, което е тънка обвивка около API-то на "ядрото". Ако сте запалени, може да направите повече от едно GUI. Последното със сигурност ще ви донесе бонус точки :)

Документация

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

README

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

Version control

Задължително е. Силно препоръчваме да ползвате Git и GitHub, но сме ок и с алтернативи. Кодът на проекта трябва да е публичен. Ако все пак държите да ползвате друга version control система, пак ще приемем това изискване за покрито. Важното е да има някакъв version control.

Опитайте се да покажете добро използване на version control-а си. Ако целия ви код е в три къмита вероятно не правите нещо правилно.

Език

Част от изискването за добър код е имената в него да са на английски. За всичко друго имаме следното правило: окуражаваме ви да не izpolzvate shliokavica под каквато и да е форма.

Оценяване

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

• 20 точки за верен и отговарящ на условието код. Трябва като минимум да покриете условието на проекта (по ваш избор можете да го разширите, но не и да променяте/пропускате части от него)
• 20 точки за стил, другояче казано: за четим код, добър дизайн, лесни възможности за разширяване на програмата ви, ясно README, достатъчна документация, до колко сте ползвали go vet, golint и семейство.
• 20 точки отиват при добрите unit, benchmark (ако сметнете за нужно) и example тестове.