Nejčastější a nejvážnější chyby v zadání

• U každého komitu napište smysluplný komentář o provedených změnách.

• Opravené zadání je v části branches/opravene_zadani. Je potřebné pomocí volby svn/merge (na složce trunk) verze spojit - Reintegrate branch. Tato verze by se měla stát výchozím bodem pro další tvorbu zadání (pro výslednou dokumentaci, zadání se ještě bude měnit podle skutečné realizace).

• Todo a note by se v zadání již neměly objevovat. Bug v zadání ponechte – změňte je na bugfix – dopište kdo opravil a jak.

• Pro připomínky k zadání byl zvolen přepínač \bug, který je v dokumentaci zvýrazněn a všechny takto označené položky jsou také zobrazeny na zvláštní stránce - buglist. Za značkou následuje [zad], které již není značkou ale již textem - poznámkou, že tato chyba vznikla při opravě zadání.

• Postup opravy chyby je následující. Nejprve je nutné opravit vlastní chybu - v zadání nejčastěji dopsat správný text, u zdrojových kódu najít správné řešení. Následně se za text popisující bug doplní že byl opraven u zdrojových kódu vysvětlit v čem byl problém. Nakonec změním značku \bug na \bugfix, i tento má nastavenu svou zvláštní stránku v dokumentaci, takže je možné se podívat jaké byly problémy a jak se řešily. I bugfix zůstává v textu.

• Je potřebné změnit i hlavní název projektu v horní části dokumentace (mění se v doxygen konfiguračním souboru - doxyfile).

• Název projektu je i v tabulce zadání.

• V tabulce zadání uvádějte funkční školní maily.

• Úvodní část stránky zadání se neměla mazat, je součástí zadání a mělo se zde vyznačit, pro které další typy k řešení jste se rozhodli.

• U metod nejsou uvedeny jména (monogramy) autorů, kteří je vypracují v dalších fázích vývoje projektu.

• vypuštěné body zadání je nutné doplnit a vypracovat. I když v hodnocení není výslovně uvedeno, je třeba přečíst a splnit všechny body zadání, počty metod ....

• Měl by se precizněji provést popis návrhu včetně jednoduchého popisu implementace. Například sčítání, odečítání a násobení front jsou operace různě interpretovatelné a proto je dobré je popsat (je také nutné si uvědomit, že k hodnotám prvků seznamu nemá kontejner přístup).

• Zadání by mělo být definováno „laicky“ (tj. bez detailních návazností na C++), ale přitom jako požadavek na vytvoření třídy (žádané po někom jiném). Proto by zde měly být popsány činnosti metod a operátorů konkrétněji. Nemělo by se zde objevovat „bude dělat například ... nebo ... nebo ...“

• měly by se objevit metody, které k "typu" logicky patří - Push, Pop, Top, Front, u pole operator[] …

• Uvést u každé funkce/metody jak se bude jmenovat (např. pro vkládání a výběr)?

• Nečlenský operátor něco dělá, ale také se nějak jmenuje (který operátor bude použit).

• Název třídy by měl být krátký (aby se dobře psal) ale zároveň srozumitelný.

• Názvy jmenných prostorů jsou bez mezer, měly by být výstižné, ale ne zbytečně dlouhé. Určitě by měly držet konvenci názvů prostorů z již hotových tříd.

• Znovu přepočítejte zda dosahujete požadovaných počtů metod (nejčastěji nesplňujete unární operátory, konstruktory a operátory). Nesplněné požadavky na počet v odevzdaném souboru zadání nejsou rozhodující, důležité je jaké požadavky byly v původní šabloně zadání.

• Nelze použít neexistující operátory (ty které neznáme například pro int, neexistuje operátor $, @ …). U přetížení operátorů nelze měnit počet parametrů a prioritu. U nečlenského operátoru je nutné specifikovat typ návratové hodnoty.

• v zadáních jsou vidět jisté „školy“ (= „rodiny“ přibližně stejných textů) – snažte se pracovat samostatně – kopie budou penalizovány (a nic se nenaučíte)

• kombinace aaa.metoda, Funkce(aaa), které dělají totéž, jsou zamýšleny tak, aby jste si všimli rozdílu mezi voláním metody a funkce a mezi vrácením hodnoty odkazem (u metody (proč to jde?)) a hodnotou (u funkce, co se při tom děje (proč to nejde odkazem?))). Obojí by mělo vrátit prvek stejného typu jako je prvek, který tyto vyvolal (aaa).

• Konstruktorem z řetězce (stringu) je myšlen klasický řetězec C (char *, neboli pole znaků ukončené znakem ´\0´). Pro zpracování řetězce napište vlastní algoritmy, ve kterých použijete funkce: xscanf, xtoa, atox – nepoužívejte pro zpracování řetězce jiné knihovní funkce). Řetězec by měl sloužit k tisku a zadávání „pochopitelnému“ pro člověka. Proto by jeho formátování mělo být takové aby se v něm člověk snadno orientoval.

• Jaký je formát řetězce pro tisk, načítání? Pouhé data struktur oddělené čárkami budou (například při tisku na konzolu) značně nepřehledné.

• Použití dynamických dat ve třídě – skutečně uděláte lineární seznam bez dynamických dat?

• Dědění ve třídě – prohlédli jste si pozorně CXItem?

• Použití výjimek - prohlédli jste si pozorně vzorové části projektu? Budete alokovat paměť?

Poslední úpravy 2014-11-18