"Magická čísla", tedy čísla ve zdrojovém textu programu, kde není jasně vidět jejich účel se objevila prakticky ve všech pracech. Je ale lepší čísla nahradit symbolickými konstantami, výrazně to zpřehlední čitelnost zdrojových textů i jejich údržbu.
Obvykle šlo o čísla udávající rozměry statických nebo počáteční velikost dynamických polí. Ačkoliv je nastavení číslem nejsnazší, nejde o vhodné řešení. V případě, že je třeba provést nějaké úpravy programu (třeba proto, že odhadnuté velikosti nedostačují), je nutné projít celý zdrojový text a všude číslo upravit. Pokud je použita konstanta, stačí jen úprava na jednom místě. A nejde jen o uspořený čas, pokud ve zdrojových textech přehlédnete byť jen jediné číslo, které je třeba upravit, může se program začít "chovat divně" bez zjevných důvodů a najít takovou chybu dá dost práce.
Druhým případem byly hodnoty použité při realizaci textových menu. I tady je lepší použít symbolické konstanty, tentokrát hlavně pro usnadnění čitelnosti zdrojových textů. Přece jen vypadá mnohem lépe
if (vyber == OTEVRI_SOUBOR) {...}
než
if (vyber == 3) {...}
V prvním případě je na první pohled jasné, co má podmínka dělat, v druhém je třeba dohledat cože to volba "3" vlastně znamená.
Při práci se soubory se v Javě používají streamy (například BufferedReader nebo třeba FileWriter). Streamy je třeba po ukončení práce uzavírat. Stream totiž může být (a často je) svázán se souborem a ten pak nemohou jiné programy (nebo dokonce ten váš) používat. Operační systém zajisti uzavření všech souborů po ukončení programu, ale za jeho běhu se vám může stát, že budete chtít dvakrát přistoupit k témuž souboru a pokud není uzavřen, nemusí se to podařit.
Práce s proudy může vyhazovat několik výjimek a tak je obvykle v try {...} catch(IOException e) {...} bloku. Pokud je uzavření streamu už v části try , nemusí k němu při výskytu výjimky dojít. Proto je lepší použít část finally a uzavření proudu dát do ní.
V Javě je konvence pro pojmenovávání proměnných trochu jiná, než v jazyce C. Ačkoliv jistě byla probrána v PPA, občas jsem narazil na drobné prohřešky proti ní. Na stránkách Sunu je podrobný popis, ale základní pravidla zde uvedu:
mojePromenna,zdrojovySoubor.MojeTrida,HlavniOkno.MOJE_KONSTANTA, VELIKOST_POLE.Dále je lepší nekombinovat české a anglické názvy tříd a proměnných. Když už začnete používat české názvy, držte se jich.
V dokumentaci by neměly chybět základní informace o použitých algoritmech a datových strukturách. Jsou mnohem užitečnější, než třeba poppis všech metod, které jsou v aplikaci použity. Například pokud používáte hash tabulku, měla by být uvedena použitá rozptylová ("hashovací") funkce.
Prezentace by měla mít zahájení (kde představíte sami sebe a téma, o kterém budete mluvit), stručný přehled toho, o čem chcete mluvit (seřazené nejlépe tak, že postupujete od nejznámějších věcí k těm novým), pak vaše řešení a na konci závěr, zhodnocení vaší práce nebo její výsledky. Obrázky a diagramy jsou užitečné a mohou demonstrovat myšlenku lépe, než několik stran textu. Na druhé straně ukázky zdrojového textu nebo tabulky jsou prakticky k ničemu. A hlavně si před prezentací vyzkoušejte odříkat ji někomu jinému, nejlépe několikrát - jednak si utřídíte pořadí věcí, které chcete říct, jednak si uděláte obrázek o době, kterou to zabere.
Desetinná čísla je lepší vypisovat v nějakém "lidském" formátu. Standardní výpis v Javě vypadá jako 0.4555E-06, což není pro běžné lidi zrovna čitelné. Podívejte se na formátování řetězců, Java poskytuje velmi silné formátovací nástroje, nejen pro čísla, ale třeba i pro čas, měnu nebo datum.
Ti, kteří řešili úlohu s Fibonacciho řadou, si jistě všimli, že datový typ Integer na výsledky zdaleka nestačí (rozsah je jen zhruba +/- 2 miliardy). Při výpočtu dochází k přetečení (proto některým z vás vycházela záporná čísla na místě, kde by zjevně být neměla), které ale není indikováno. Vzniká sice výjimka ArithmeticException, pokud ale není odchycena nijak se neprojeví, přetečení tedy není indikováno. Napravit to lze použitím typu double, ale ani to není ideální, double totiž nebude přesné číslo, jen zaokrouhlené. Pro takové případy Java nabízí třídy pro velká čísla s neomezenou přesností a velká celá čísla, cenou za jejich použití je ale pomalejší výpočet.