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

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

• Dále už se pracuje pouze v adresáři projekt: hlavní je třída kontejner s demonstrací všech metod a funkcí v main, zdroje (h a cpp) kontejneru. Main s kontejnerem musí být schopen pracovat se všemi čtyřmi CXItem (pouze "přepnutím" namespace v hlavičkovém souboru).

• 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]“.

• Odevzdaný projekt musí být přeložitelný – jinak nebude obodován.

• Každý z autorů by měl provést minimálně tři významné komity 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, volání v main, počítání objektů třídy, komentář doxygen, privátní metody, friend funkce, smazat „testovací“ new ...

• Čtěte a přemýšlejte nad chybovými (warning) hlášeními, které většinou upozorňují na chybné použití jazyka..

• I doxygen a knihovna check generují 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é CXItem (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č).

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

• include pro všechny vytvořené CXItem v cxitem.h nechejte už 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í streamy pro CXItem i kontejner.

• 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 je použjte 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.

• Všechny operátory vrací hodnotu. Pouze u konverzního operátoru je drobná výjimka, že se typ návratové hodnoty neuvádí v deklaraci. Relační operátory by měly vracet typ bool.

• 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 – pro obě by měl fungovat uvedený kód, kdy se výsledek opět uloží do proměnné typu kontejner. Reverzuj by se tedy měl objevit v deklaracích dvakrát.

• Stejnojmenné metody TestValue1 a TestStringValue1 by měly vracet hodnoty které inicializuji CXItem 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 2014-12-08