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 – návod je ve cvičeních (cv 6) odkaz na svn a tam odkaz na prvním řádku. 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).

• Před editací textu zadání bylo vhodné si nakreslit diagram signatury a promyslet souvislosti dat, parametrů, návratových hodnot a činností.

• Číst warningy a errory (i doxygen) a snažit se je odstranit.

• Číst zadání - co má být odstraněno je nutné odstranit. Nenechávat text "například", alternativy pro jednu metodu "... nebo ...", "...".

• 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, v textu by měl být i autor úpravy. 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 (delá) mazat, je součástí zadání a mělo se zde vyznačit (zůstat přítomno), 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.

• Implicitní konstruktor slouží k plnohodnotné inicializaci objektu bez informace dodané pomocí parametrů a reprezentuje tzv. minimální inicializaci objektu (tzn. Prázdný kontejner).

• 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 .... Hodnotit se bude nadále podle počtů a typů metod ze základního zadání (pokud jste povinnou metodu smazali, je nutné ji stejně napsat – například metody pro vkládání a vybrání prvku, konverzní operátor ...) Nedostatečný počet metod v daném bodě.

• Program (projekt v adresáři project) musí fungovat i pro CNode půjčené od jiné skupiny (takže se nedá manipulovat s hodnotami "uvnitř" CNode, protože to není obecná vlastnost CNode).

• Co je myšleno prvkem? Je zde skiplist, CNode, obsah CNode, CSLNode, extraInt … Na začátku textu by měl být rozbor řešení, uvedení terminologie, datové členy – potom by se lépe tvořil zbytek zadání.

• 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). Kontejner má prvek CNode a int. Kontejner má definici svou definici a činnosti "otočení" či "inverze" mohou vést ke stejnému kontejneru a tedy nedává smysl je realizovat.

• Při práci operátorů je nutné říci co se děje s CNode a co s "int". Není možné napsat pouze, že to je součet, průnik. Tyto operace je nutné definovat (popsat co se děje s "obsahy" kontejnerů). Pokud to jde měly by operátory dělat činnost podobnou činnosti u základních datových typů (a ne např. "vynuluje kontejner").

• 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 a mapy 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). Co je to friend operátor? Jak se ke kontejneru například přičte float?

• 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 nadefinovat neexistující operátory (ty které neznáme například pro int, neexistuje operátor $, @ …) . Existují tedy pouze ty operátory, které lze použít u základních datových typů. Při přetěžování operátoru nelze také měnit jeho aritu (počet parametrů) ani 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. Řetězec musí (měl by) mít stejný tvar při všech příležitostech (konstruktor, tisk, načítání).

• 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 kontejner bez dynamických dat?

• Dědění ve třídě – prohlédli jste si pozorně dodané zdrojové texty – jak vznikají dodané třídy?

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

Poslední úpravy 2015-11-19