Nejčastější a nejvážnější chyby v hlavičkových souborech

• Opravená verze je v adresáři tag - spojit (merge) s aktuální verzí.

• Dále už se pracuje pouze v adresáři projekt - demonstrace všech metod a funkcí v main, zdroje (h a cpp) kontejneru. Schopno pracovat se všemi čtyřmi CBNode (pouze "přepnutím" namespace).

• Místa, kterých byste si měli všímat jsou označena “\bug [Hla]“. K poznámce připište způsob ošetření a „přepněte“ na “\bugfix [Hla]“.

• Každý z autorů by měl provést minimálně jeden významný komit týdně. Měla by se komitovat každá nově zapsaná metoda/funkce. Takže komitů by mělo být více (i kdyby na projektu pracoval jen jeden). Práce by měla být rozdělena rovnoměrně mezi autory.

• Práce by měla obsahovat splnění původního zadání (počty a typy metod/funkcí) - nejčastěji chybí nečlenský operátor.

• I doxygen generuje chybová hlášení - je nutné je vyřešit.

• Komentování třídy jako celku podrobněji v zadání, nebo na samostatné stránce (\page). - V dokumentaci bude stručný popis třídy, jak je koncipovaná, jak funguje ... Zadání s vyznačením změn, zvláštní stránka pro popis základních vlastností třídy, závěr (zhodnocení dosaženého, možná zlepšení).

• Pro obsah dokumentace doxygen: popis souboru, popis třídy jako celku, popis členských dat a metod (včetně parametrů, návratové hodnoty a stručně činnost), třídy, struktury, namespace. Z dokumentace by mělo jít poznat co má metoda dělat a jaký mají její parametry význam (=help). Komentován bude: kontejner, nové CBNode (z nich odstraňte komentáře, které se jich netýkají).

• Projekt musí být přeložitelný ve VC - doplňte projekt a zkuste přeložit. (Nebo dodejte fungující make pro "běžný" překladač). Sledujte i Warningy, které většinou upozorňují na chybné použití jazyka.

• CBNode by měly pracovat proti původnímu main (v adresáři CBNode). Druhý vámi vytvářený CBNode neměl být "jednoduchý" typ (Je nutné zařídit aby pro něj fungovalo nastavení hodnoty a konstruktory tak, že naplní všechny proměnné typu pomocí jediného parametru (tj. struct, class, pole ...)).

• Jednotlivé include CBNodu v cbnode.h nechejte už pro vždy odkomentované

• Includovat by se měly pouze knihovny, které jsou potřeba, „systémové“ pomocí znaků < a >, „autorské“ hlavičkové soubory pomocí “ a “.

• Knihovna pro kontrolu check.h by měla být až jako poslední include.

• Často chybí istream pro CBNode.

• Hlavičkové soubory by měly být standardně ošetřeny.

• Pokud možno nepoužívejte „typedef“ pro struktury a třídy (většina z nich je použita špatně, a v C++ je použití tohoto mechanizmu v těchto situacích zbytečné).

• Promyslete si používání referencí v návratové hodnotě (v parametru vždy).

• Zamyslete se nad umístěním klíčového slova const do hlaviček metod, funkci a operátorů.

• Pokud je implementován operátor ++, --, musí být implementovány verze postfix i prefix. Tyto operátory vrací hodnotu.

• Kontejner by neměl "pustit" uživatelovi ukazatel na svůj (privátní) prvek. Ani jinak umožnit přístup k privátním prvkům (například přímým vložením prvku, který dostal pomocí ukazatele - ukazatel zná i uživatel a tedy může k němu přistoupit -> "odkrytí" privátních dat).

• Všimněte si popisu metody a funkce Reverzuj - měly by fungovat kód, kdy se výsledek opět uloží do proměnné typu kontejneru.

• Stejnojmenné metody TestValue1 a TestStringValue1 by měly vracet hodnoty které inicializuji CBNode na stejnou vnitřní hodnotu. (jejich použití by mělo vést ke stejné hodnotě).

• Metody s „delším“ kódem by neměly být (inline) v hlavičkovém souboru, ale měly by bít tělíčka v cpp souboru.

• Všechny metody a funkce by měly být volány, pokud možno v různých situacích, aby se plně otestovalo jejich chování (na různé vstupy).

• Při vstupu do metody/funkce je nutné ošetřit chybové stavy (záporná délka, chybné znaky v řetězci, objekt v chybovém stavu. Na konci metody/funkce je nutné nastavit případný chybový stav.

• Projekt i dokumentace se odevzdává najednou v zápočtovém týdnu. Bude provedena kontrola "stejnosti" projektů - analýza kódu napříč projekty.

Poslední úpravy 2013-01-08