Mga karaniwang error sa Java code.

Ang materyal na ito ay naglalaman ng mga pinakakaraniwang error na nakita ko sa Java code ng mga taong nagtatrabaho sa akin. Ang static na pagsusuri (ginagamit namin ang qulice ), para sa malinaw na mga kadahilanan, ay hindi matukoy ang lahat ng mga error, kaya't nagpasya akong ilista ang mga ito dito. Ang lahat ng mga error na ito ay nauugnay sa object-oriented programming sa pangkalahatan at Java sa partikular.

Mga Pangalan ng Klase

Ang iyong klase ay dapat na isang abstraction ng isang tunay na bagay sa buhay na walang " validators " , " controllers " , " managers " , atbp. Kung ang pangalan ng iyong klase ay nagtatapos sa "-er" ito ay masamang disenyo. At siyempre, ang mga anti-pattern helper na klase tulad ng Apache's StringUtils , FileUtils , at IOUtils ay mahusay na mga halimbawa ng kakila-kilabot na mga pattern ng disenyo. Huwag kailanman magdagdag ng mga suffix o prefix upang makilala ang pagkakaiba sa pagitan ng mga interface at mga klase. Halimbawa, lahat ng mga pangalang ito ay kakila-kilabot: IRecord , IfaceEmployee , o RecordInterface . Karaniwan, ang pangalan ng interface ay ang pangalan ng real-life object, habang dapat ipaliwanag ng pangalan ng klase ang mga detalye ng pagpapatupad. Kung walang tiyak na masasabi tungkol sa pagpapatupad, ang mga pangalan na " Default ", " Simple ", o isang katulad na bagay ay gagawin. Halimbawa: class SimpleUser implements User {}; class DefaultRecord implements Record {}; class Suffixed implements Name {}; class Validated implements Content {};

Mga Pangalan ng Pamamaraan

Ang mga pamamaraan ay maaaring ibalik ang " isang bagay " o ibalik ang " walang bisa ". Kung ang isang pamamaraan ay nagbabalik ng isang bagay, kung gayon ang pangalan nito ay dapat ipaliwanag kung ano ang ibabalik. Halimbawa (huwag gamitin ang prefix na " get "): boolean isValid(String name); String content(); int ageOf(File file); Kung ibinalik ang " void ", dapat linawin ng pangalan kung ano ang ginagawa ng pamamaraan. Halimbawa: void save(File file); void process(Work work); void append(File file, String line); Mayroon lamang isang pagbubukod sa panuntunang ito - JUnit test method . Ang mga ito ay inilarawan sa ibaba.

Mga Pangalan ng Paraan ng Pagsubok

Ang mga pangalan ng pamamaraan sa mga pagsusulit sa JUnit ay dapat gawin bilang isang pangungusap sa Ingles na walang mga puwang. Ito ay mas madaling ipaliwanag gamit ang isang halimbawa: /** * HttpRequest can return its content in Unicode. * @throws Exception If test fails */ public void returnsItsContentInUnicode() throws Exception { } Mahalagang simulan ang unang pangungusap ng iyong JavaDoc na may pangalan ng klase na iyong sinusubok na sinusundan ng " maaari ". Kaya, ang unang pangungusap ay dapat palaging katulad ng pariralang " may magagawa ang isang tao ." Ang pangalan ng pamamaraan ay magsasaad ng parehong bagay, ngunit walang paksa ng pagsubok. Kung idaragdag ko ito sa simula ng pangalan ng pamamaraan, makakakuha ako ng kumpletong English na pangungusap, tulad ng sa halimbawa sa itaas: " Ibinabalik ng HttpRequest ang nilalaman nito sa unicode ." Pakitandaan na ang pangalan ng paraan ng pagsubok ay hindi nagsisimula sa " maaari ". Ang mga komento ng JavaDoc lamang ay nagsisimula sa " maaari ". Bilang karagdagan, ang mga pangalan ng pamamaraan ay hindi dapat magsimula sa isang pandiwa ( Mula sa tagasalin: tila, ang ibig sabihin ng may-akda ay ang imperative mood ng pandiwa ). Magandang kasanayan na ipahiwatig na ang isang pagbubukod ay itinapon kapag nagdedeklara ng isang paraan ng pagsubok.

Mga Pangalan ng Variable

Iwasan ang mga compound variable na pangalan gaya ng timeOfDay , firstItem , o httpRequest . Ang ibig kong sabihin ay parehong mga variable ng klase at mga variable ng pamamaraan. Dapat sapat ang haba ng variable na pangalan upang maiwasan ang kalabuan sa saklaw nito, ngunit hindi masyadong mahaba kung maaari. Ang pangalan ay dapat na isahan o pangmaramihang pangngalan. Halimbawa: Minsan maaaring may mga banggaan sa pagitan ng mga parameter ng constructor at mga field ng klase kung ang constructor ay nag-iimbak ng data ng input sa nilikha na bagay. Sa kasong ito, inirerekumenda ko ang paglikha ng isang pagdadaglat sa pamamagitan ng pag-alis ng mga patinig. Halimbawa: Sa karamihan ng mga kaso, ang pinakamahusay na pangalan ng variable ay ang pangalan ng kaukulang klase. I-capitalize lang ito at magiging maayos ka: Gayunpaman, huwag na huwag gawin ang parehong para sa mga primitive na uri tulad ng o . Maaari ka ring gumamit ng mga adjectives kapag mayroong ilang mga variable na may iba't ibang mga katangian. Halimbawa: List names; void sendThroughProxy(File file, Protocol proto); private File content; public HttpRequest request; public class Message { private String recipient; public Message(String rcpt) { this.recipient = rcpt; } } File file; User user; Branch branch; Integer number String string String contact(String left, String right);

Mga konstruktor

Nang walang pagbubukod, dapat ay mayroon lamang isang tagabuo na nag-iimbak ng data sa mga variable ng bagay. Ang lahat ng iba pang mga konstruktor ay dapat tumawag sa isang ito na may iba't ibang mga parameter: public class Server { private String address; public Server(String uri) { this.address = uri; } public Server(URI uri) { this(uri.toString()); } }

Isang beses na Variable

Iwasan ang isang beses na mga variable sa lahat ng mga gastos. Sa pamamagitan ng "disposable" ang ibig kong sabihin ay mga variable na ginamit nang isang beses. Tulad ng sa halimbawang ito: String name = "data.txt"; return new File(name); Ang isang variable ay ginagamit nang isang beses lang, at ang code ay maaaring gawing simple sa: return new File("data.txt"); Minsan, sa napakabihirang mga kaso - karamihan ay dahil sa mas mahusay na pag-format - ang isang beses na mga variable ay maaaring gamitin. Gayunpaman, subukang iwasan ang mga ganitong sitwasyon.

Mga pagbubukod.

Siyempre, hindi mo dapat "lunok" ang mga pagbubukod; dapat silang itapon nang mataas hangga't maaari. Ang mga pagbubukod mula sa mga pribadong pamamaraan ay dapat pangasiwaan sa labas. Huwag gumamit ng mga pagbubukod upang kontrolin ang daloy. Ang code sa halimbawa ay hindi tama: int size; try { size = this.fileSize(); } catch (IOException ex) { size = 0; } Seryoso, paano kung ang IOException ay nagsasabing "puno na ang disk", ipagpalagay mo ba na ang laki ng file ay zero at magpapatuloy?

Indentation.

Para sa indentation, ang pangkalahatang tuntunin ay dapat na tapusin ng panaklong ang linya o isara sa parehong linya (ang kabaligtaran ng panuntunan ay nalalapat para sa pagsasara ng panaklong). Sa halimbawa sa ibaba, ang code ay hindi tama dahil ang unang panaklong ay hindi sarado sa parehong linya at may mga character pagkatapos nito. Ang pangalawang bracket ay may parehong problema dahil may mga character bago ito, at walang pambungad na bracket sa kasalukuyang linya. final File file = new File(directory, "file.txt"); Ang tamang indentation ay dapat magmukhang ganito: StringUtils.join( Arrays.asList( "first line", "second line", StringUtils.join( Arrays.asList("a", "b") ) ), "separator" ); Ang pangalawang mahalagang panuntunan ng indentation ay dapat mong ilagay hangga't maaari sa isang linya - sa loob ng 80 character. Ang halimbawa sa itaas ay hindi wasto dahil maaari itong i-compress: StringUtils.join( Arrays.asList( "first line", "second line", StringUtils.join(Arrays.asList("a", "b")) ), "separator" );

Mga Kalabisan na Constant.

Dapat gamitin ang mga constant ng klase kapag gusto mong magbahagi ng access sa impormasyon sa pagitan ng mga pamamaraan ng klase, at ang impormasyong ito ay isang katangian( ! ) ng iyong klase. Huwag gumamit ng mga constant bilang kapalit ng mga string o numeric literal - napakasamang kasanayan, humahantong ito sa polusyon ng code. Ang mga constant (tulad ng iba pang OOP object) ay dapat may kahulugan sa totoong mundo. Ano ang kahulugan ng mga constant na ito sa totoong mundo: class Document { private static final String D_LETTER = "D"; // bad practice private static final String EXTENSION = ".doc"; // good practice } Ang isa pang karaniwang pagkakamali ay ang paggamit ng mga constant sa mga unit test upang maiwasan ang pagdoble ng string/numeric literal sa mga pamamaraan ng pagsubok. Huwag mong gawin yan! Ang bawat paraan ng pagsubok ay dapat gumana sa sarili nitong hanay ng mga halaga ng input. Gumamit ng mga bagong teksto at numero sa bawat bagong paraan ng pagsubok. Ang mga pagsusulit ay independyente. Kaya bakit dapat silang magbahagi ng parehong input constants?

Test Data Coupling.

Narito ang isang halimbawa ng hooking sa isang paraan ng pagsubok: User user = new User("Jeff"); // maybe some other code here MatcherAssert.assertThat(user.name(), Matchers.equalTo("Jeff")); Sa huling linya, pinagsama namin ang " Jeff " sa parehong literal na string na tinukoy sa unang linya. Kung, pagkalipas ng ilang buwan, may gustong baguhin ang halaga sa ikatlong linya, kakailanganin niyang gumugol ng karagdagang oras sa paghahanap kung saan pa ginagamit ang " Jeff " sa paraang ito. Upang maiwasan ang pag-snagging ng data na ito, dapat kang magpakilala ng variable.