Javan nimeämisessa on package oleellinen käsite, koska

• sillä rajoitetaan nimiavaruus omaan packageen, jonka kautta luokat ovat suoraan käytettävissä ilman import-lauseketta.
• sillä laajennetaan nimiavaruutta, eli mahdollistetaan samannimisen luokan esiintyminen useissa packageissa.
• se toimii osaltaan dokumetoivana, eli packagen/luokan tekijä paljastuu helposti package määritelmällä.

Ei tulisi koskaan käyttää, koska

• koodi dokumentoituu myös käytettyjen luokkien avulla ja käytetyt luokat näkyvat helposti import-lauseiden avulla.
• Kun luokat importoidaan yksitellen, näkyy selvästi käytettyjen luokkien maara.
  Jos luokkien määrä on suuri, voi suoraan epäillä koodissa olevan jotain mätää, koska hyvä luokka käyttää pääsääntãisesti vain harvoja luokkia.
• mahdollista samojen luokkien päällekäisyys, koska samannimisia luokkia on usein eri pakkauksissa.

Tulisi kirjoittaa interface-tyyppiseen luokkaan, koska

• määritelmä on silloin käytettävissä useissa luokissa, eli ei tarvitse duplikoida koodia, josta aiheutuu muutoksissa suhteellisen suuri työ.
• implements-lausella vakioita sisältävän interfacen vakiot ovat suoraan käytettävissä ilman luokkanimi.vakionimi nimeämistä, eli vakionimi nimenä riittää.

// -kommentointia tulisi käyttää vain yhden rivin kommenteissa ja silloinkin mielellään vain rivin loppuun tuleviin kommentteihin. Käytä /* */ -kommentteja.

Kirjoita metodien ja luokkien edessä olevat kommentit Javadoc-kommenteiksi, jolloin ne tulevat suoraan Javadocin ajamisella metodien ja luokkien dokumenteiksi.
Javadoc-kommentti on muotoa /** */

Tulisi tehdä servlet-parametroinnin kautta, ei final static muuttujiin.
Parametrointi tehdään siis siten, ettei koodia tarvitse kääntää uudestaan ja se toimii suoraan kaikissa toimintaympäristöissä.

Kun määritellään vakiot, tulee vakiot oikein nimeämällä koodikin paremmin dokumentoitua itsellään ja vältetään turhilta kommenteilta (joiden tulisi olla koodia!).

Koska servlet-luokka on käyttöliittymä, ei sen tulisi koskaan sisältää toiminnallista logiikkaa.
Toiminnallinen logiikka tulisi aina olla uudelleenkäytettävää, jolloin koodiin käytetty aika (==investointi) tulee mahdollisimman hyvin..
Myös JUnit-testaus on helpompaa kun toiminnallinen logiikka on erillisissä testattavissa luokissa.

Käytä java.util.Calendar -luokkaa. Suomessa käytetään GregorianCalendar -luokkaa.
Huomioi Locale.

Tehty oikein koodissa.
ResultSet, Statement ja Connection suljetaan kaikki erikseen, koska kaikissa voi olla aktiivisia threadeja, riippuen toteutuksesta, jolloin sulkemalla vain esimerkiksi Connectionin voi koodiin jäädä ylimääräisiä threadeja pyörimään.
Koodi näyttää helposti toimivalta mutta ei sitten toimikaan oikeassa ympäristössä, vaan lukkiutuu kummallisesti. Lukkiutuminen aiheutuu threadien määrän kasvusta, tietokannan yhteyksien loppumisesta tai muistin loppumisesta.

Jos Hashtablea käytetään selkeästi luokkana, kannattaa operaatiot piilottaa oman luokkansa sisään.

URL:ien kasaaminen tai URL:in komponenttien parsimiseen kannattaa käyttää valmista luokkaa, sen sijaan että rakentaisi vastaavan toiminnon itse. Työ on turhaa, sekavoittaa koodia (refaktorointi hankalampaa) ja saattaa tuottaa ylimääräisia virheitä ts. koodin luotettavuus ja toimivuus saattavat heikentyä.

Ei ole suositeltavaa vaan luokkien importtaaminen ja käytto omalla nimellään, koska

• import-lauseet dokumentoivat koodia.
• muuttamalla importattuja luokkia saadaan samat luokat kätevasti vaikkapa eri paketista tai luokka "trampoliiniksi/liimaksi" omaan pakkaukseen (trampoliiniluokan kautta käytetään toisessa paketissa olevaa luokkaa ts. saadaan joskus tarvittava lisätoiminnallisuus aikaiseksi ilman suurempia muutoksia tai koko luokan läpikäymistä, eikä tule mitään yllätyksiä).