Indholdsfortegnelse
Når du begynder at lære et nyt programmeringssprog, er det vigtigt at kende dens bedste praksis, da et godt program ikke kun er en veludført algoritme, men også dokumentation Og vejen ind hvad er koden skrevet er vigtige.Hvis vi dokumenterer godt, vil vi være i stand til at forlade de programmører, der gennemgår vores kode, på en god måde, så de forstår, hvad vi gjorde og årsagerne, på denne måde er kontinuiteten i projekterne bedre; også en læsbar kode hjælper os med at fejlsøge fejl og gør, at vi kan spilde mindre tid på forskellige faktorer end at nå vores mål.
Navngivningskonvention
Navngivningskonventionen er ekstremt vigtig, med dette kan vi hurtigt identificere klasse- og metodevariabler.
Det første vigtige aspekt er navnes skrivemåde, når vi har variabelnavne vi skal bruge små bogstaver og når vi har konstanter skal være i store bogstaver, Lad os se:
int [b] divisor [/ b] = 5; endelig dobbelt [b] PI [/ b] = 3,14;
Så når vi ser PI, ved vi, at det er en konstant, på den anden side, hvis vi ser en divisor, ved vi, at det er en variabel, og hvis vi skal manipulere det, kan vi gøre det velvidende, at vi ikke vil påvirke programmet.
Hvis vi har navne på flere ord, skal vi bruge kamelhusmetode det vil sige store bogstaver i det følgende ord i navnet.
Lad os se på følgende eksempler:
Rum og identitet
Når vi skriver indlejret kode, for eksempel klasser og deres metoder, skal disse gå indrykket, det vil sige, at de skal adskilles med en fane for at betegne deres rede, med dette letter vi identifikationen af, hvilke dele der tilhører hvilke.
Vi skal også passe på rummet mellem de forskellige elementer, der udgør erklæringerne, da misbrug kan skabe et læselighedsproblem.
Lad os se et eksempel på hver ting, for eksempel mellemrummet mellem elementer, på billedet ser vi den korrekte form i den nederste del, hvor hvert element er adskilt af et mellemrum, men i den øverste del på den forkerte måde ser vi, at der er ingen ensartethed i mellemrummene.
Som vi nævnte i begyndelsen dokumentation giver os mulighed for at angive vores kommentarer inden for koden, til dette vil vi bruge skriveværktøjerne kommentarer i Java; For eksempel, hvis vi vil dokumentere hvert trin, vi udfører inden for koden, kan vi bruge // til at generere en linje, der vil blive udeladt af kompilatoren, men som kan læses fra kildefilen.
Hvis vi i begyndelsen af klassen laver en kommentarblok ved hjælp af:
/** /* /* **/
Det, vi skriver inde i den blok, kan eksporteres og bruges til at generere HTML -dokumenter med værktøjerne til java dokumentation. Så vi skal bruge hver sag i overensstemmelse hermed.
I slutningen af vejledningen har vi en bredere forestilling om de bedste fremgangsmåder, når vi laver Java -programmer for at samarbejde med udvikling på et funktionelt niveau, men gå lidt ud over vores ansvar som en god udvikler.Kan du lide og hjælpe denne vejledning?Du kan belønne forfatteren ved at trykke på denne knap for at give ham et positivt punkt
