Navnekonventioner, kodekonventioner

"Hej, Amigo! I dag vil jeg fortælle dig om kodestile og vigtigheden af ​​kodestil."

"Jeg starter med det, der betyder mest.  Java-kode skal være let at læse.  Den generelle tilgang til koden er denne: kode skrives én gang, men læses hundrede gange."

"Antag, at du og 10 andre programmører skriver en ansøgning. I arbejder på applikationen i tre år, med mellemliggende udgivelser hver tredje måned."

"Så længe?"

"Dette er Java, min unge græshoppe! "Hvad med et virksomhedssystem, der kører på et dusin servere og er skrevet af 100 mennesker over mere end 6 år? Det sker også nogle gange."

"Hov."

"I hvert fald, hovedreglen, hovedkravet til kode er, at det skal være nemt for andre udviklere at læse."

"På andre programmeringssprog arbejder folk ofte som små teams med små opgaver, så de kan have en anden hovedregel, såsom 'Det virker? Fremragende'."

"I løbet af et par år vil alle dine teammedlemmer foretage adskillige ændringer i den kode, du har skrevet. Og hver gang skal de forstå, hvordan koden fungerer."

"Og uforståelig kode, der fungerer perfekt, er svær at ændre.  De kasserer den og omskriver den på deres egen måde.  Så skriv kode, som andre kan forstå.  Hvis du kan forbedre din kode, så forbedre den. Hvis den kan forbedres, så skal det forbedres! "

"Hvis du skriver kode i 15 minutter og derefter bruger to timer på at forbedre den, gør du det rigtigt. Hvor meget tid sparer du holdet?"

"'2 timer til at forstå din kode' x 'de 100 gange, hvor folk skal forstå den' = 200 timer."

"Jeg trak disse tal ud af den blå luft, men jeg vil have dig til at forstå problemet og dets omfang.  Din kode er skabt til at blive læst af andre programmører.  Alt andet er sekundært."

"Fungerer koden ikke korrekt? Vi ordner den. Ikke optimeret? Vi optimerer den. Ikke dokumenteret? Vi tilføjer kommentarer."

" Er koden svær at læse? Smid det lort i skraldespanden og skriv alt igen fra bunden! "

"Jeg troede ikke, det var så stort en sag."

"En af grundene til, at Java er et førende programmeringssprog, er, at al Java-kode er skrevet til at blive læst af andre programmører."

"Lad os nu gå videre til det andet spørgsmål: hvordan gør du din kode så let at læse som muligt? "

"Enhver kan forstå, når nogen taler velkendte ord på hans eller hendes modersmål. Det samme gælder her. Koden er let at læse, når en programmør nemt kan gætte:

A)  Hvad hver metode gør

B)  Formålet med hver klasse

C)  Præcis hvad hver variabel gemmer.

Alt dette kommunikeres i navne: klassenavne, metodenavne og variabelnavne. Derudover er der stil, når det kommer til at navngive variable. Og der er kodestil."

"Jeg er klar til at lytte."

" Programmering er baseret på godt engelsk!  Et velskrevet program lyder som almindelig teknisk dokumentation. "

" Lad os starte med navne. "

"Et metodenavn skal kort beskrive, hvad metoden gør. Så kan koden læses som simpel prosa."

public String downloadPhoto(String url)
{
 String resultFileName = TempHelper.createTempFileName();

 Downloader downloader = new SingleFileDownloader(new Url(url));
 downloader.setResultFileName(resultFileName)
 downloader.start();
 while(downloader.isDone())
 {
  Thread.sleep(1000);
 }

 if (downloader.hasError())
  return null;

 return resultFileName;
}

"Sådan læses sådan et program."

Linje 1.

"Metoden hedder 'downloadPhoto'. Det ser ud til, at den downloader en fotofil fra internettet. Hvor downloades den hen? Vi ved det ikke endnu. Hvorfra? Metoden har en parameter, der hedder url — det er sandsynligvis URL'en til download."

Linje 3.

"Variablen resultFileName er erklæret og tildelt en værdi af TempHelper.createTempFileName();"

Så dette må være den lokale sti til filen, hvor vi gemmer vores downloadede fil.

"Navnet 'TempHelper' fortæller os ikke noget. 'Hjælper'-suffikset siger, at dette er en slags hjælpeklasse, der ikke indeholder vigtig forretningslogik, men derimod bruges til at forenkle rutineopgaver, der forekommer hyppigt."

"Metodenavnet 'createTempFileName' indikerer, at denne metode opretter og returnerer navnet på en midlertidig fil (temp-fil). En midlertidig fil er en midlertidig fil, der oprettes i et stykke tid og derefter normalt slettes, når programmet lukkes. "

Linje 5.

"Et SingleFileDownloader-objekt oprettes og tildeles til den variable downloader."

Dette er det objekt, der vil downloade vores fil fra internettet.

"Et SingleFileDownloader-objekt er tildelt variablen downloader. Ud fra navnet kan vi antage, at programmet har flere typer downloader-klasser. Den ene er skrevet til at downloade enkeltfiler, og vi kan formentlig forvente at støde på andre downloadere i koden for grupper. af filer med navne som: MultiFileDownloader, FileGroupDownloader eller DirectoryDownloader"

Linje 6.

"Vi sætter downloader-objektets resultFileName-egenskab lig med værdien af ​​variablen resultFileName. Med andre ord fortæller vi indlæseren, hvor den downloadede fil skal gemmes. Som du ville forvente. Så vi forudsiger grundlæggende koden!"

Linje 7.

"Vi kalder startmetoden. Downloaden starter. Det giver mening. Jeg spekulerer på, hvordan downloadingen sker: i dele, på en separat tråd eller det hele lige her? Hvis vi downloader det hele lige her, kan det tage en lang tid og har konsekvenser."

Linje 8-11.

"Ah. Her ser vi standardløkken skrevet af en person, der venter på, at en download er færdig. Downloder-objektet har en done-egenskab, som returneres af isDone()-metoden. Fordi metoden kaldes isDone(), snarere end getDone( ), konkluderer vi, at den udførte variabel er en boolsk eller måske en boolsk."

Linje 13-14.

"Hvis der opstår en fejl under download, så returnerer downloadPhoto-metoden null. Det er godt, at den håndterer fejl. Det er dårligt, at den bare returnerer null - det er ikke klart, hvad fejlen er. Det ville være bedre at smide en undtagelse med information om fejlen."

Linje 16.

"Vi returnerer stien til den lokale fil, der indeholder den downloadede fil."

"Hov!"

"Dette programs kode gør det helt klart, hvad det gør. Du kan endda gætte på, hvordan programmet er organiseret, og hvilke andre klasser/metoder vi finder."

"Nu forstår jeg, hvor vigtige navne er."

"Mere om navne. Du kan ofte gætte hvilke metoder et objekt/klasse har. Hvis et objekt f.eks. er en samling, så vil det højst sandsynligt have en size() eller count() metode til at få antallet af elementer. Også , vil den sandsynligvis have en add() eller insert() metode. Elementer hentes fra samlingsklasser ved hjælp af get/getItem/getElement metoder."

"Hvis en variabel kaldes i, j eller k, så er det højst sandsynligt en loop-tæller."

"Hvis en variabel kaldes m eller n, så er det højst sandsynligt størrelsen af ​​en matrix/samling."

"Hvis en variabel kaldes navn, så er det højst sandsynligt en streng, der indeholder en persons navn."

"Hvis en klasse hedder FileInputStream, så er den samtidig en fil og en inputstrøm."

"Jo mere kode du ser, jo lettere er det at læse andres kode."

"Men nogle gange er der kode, der er meget svær at læse. I dette tilfælde er her et meget praktisk råd:"

"Det er sjovt og ikke sjovt på samme tid."

"Nu lidt om de stilarter, der bruges til at navngive variabler."

"Java-udviklere forsøger at give meget informative navne til variabler og metoder. Som følge heraf består navne ofte af flere ord. Der er 4 stilarter til brug af store bogstaver i sammensatte navne."

1) Små bogstaver  – Alle ord skrives med små bogstaver. For eksempel:

'Grønt hus'  bliver 'drivhus'

'Hollywood-pige'  bliver  'hollywoodpige'

Denne stil bruges til pakkenavne.

2) Store bogstaver  – Alle ord er skrevet med store bogstaver og adskilt af en understregning. For eksempel:

'Maksimal værdi'  bliver MAX_VALUE

'Cat count'  bliver til CAT_COUNT

"Denne stil bruges til navnene på konstanter (endelige statiske felter)."

3) CamelCase  – Alle ord er skrevet med små bogstaver, undtagen det første bogstav i hvert ord er stort. For eksempel:

'Green House'  bliver  'GreenHouse'

'Hollywood-pige'  bliver til 'HollywoodGirl'

Denne stil bruges til navne på klasser og grænseflader.

4) Lavere CamelCase (blandet bogstav)  – Alle ord er skrevet med små bogstaver, undtagen det første bogstav i hvert ord, undtagen det første er stort. For eksempel:

'Get width' bliver 'getWidth'

'Get Hollywood girl name' bliver  'getHollywoodGirlName'

"Denne stil bruges til navnene på variabler og metoder."

"Så der er ikke for mange regler."

1)  Alt er skrevet i Lower CamelCase.

2)  Navne på klasser og grænseflader er altid med stort.

3)  Pakkenavne er altid små.

4)  Konstanter er altid store bogstaver.

"Der er et par nuancer, men generelt er det, hvad det er."

"Nu om metoder.  "Metodenavne starter næsten altid med et verbum! 'tælle' er et dårligt navn for en metode. Det er bedre at kalde det getCount(). En metode udfører en handling på objektet:  startDownload , interrupt  , sleep  , loadPirateMusic ."

"Som du allerede ved, findes der gettere og sættere til at arbejde med et objekts egenskaber/felter:  getName / setName , getCount / setCount , etc."

"Den eneste undtagelse er for booleanere. For booleanere bruger getternavne 'er', ikke 'get', f.eks. isDone, isEmpty. På denne måde er det tættere på almindelig tale."

"Hvad med at arbejde to timer om dagen i stedet for 8? Fristet?"

"Ja!"

"Som du burde være. For en junior Java-udvikler er det grundlæggende krav en fremragende forståelse af det grundlæggende i Java, dvs. Java Core."

"Jeg har et andet spørgsmål. Hvorfor har vi disse forskellige metoder til at få antallet af elementer?"

"Først og fremmest blev Java opfundet for mere end 20 år siden, før krav som setCount / getCount var blevet etableret, og der var en fælles tilgang taget fra C-sproget for at 'gøre det så kort som muligt'."

"For det andet spiller semantikken en rolle her. Når vi taler om en matrix, taler vi om dens længde. Når vi taler om en samling, taler vi om dens størrelse."

"Sikke en interessant lektion."

"Jeg vil gerne fortælle dig mere, men jeg er bange for, at du ikke husker det hele på én gang. Det er bedre at give dig det i små portioner."

"Men jeg vil gerne komme ind på stilen vedrørende brugen af ​​krøllede parenteser: {}. Der er to tilgange:"

1)  Beslaget går på en ny linje hver gang

2)  Åbningsbeslaget går i slutningen af ​​forrige linje, mens lukkebeslaget går på en ny linje. Denne stil kaldes 'egyptiske seler'.

"Helt ærligt, du kan vælge, hvordan du koder. Mange mennesker bruger en åbningsbøjle på samme linje. Mange mennesker sætter den på en ny linje. Det er ligesom debatten om, hvilken ende af ægget der skal knækkes: den lille ende eller den store ende."

"Det eneste, jeg kan anbefale, er at holde fast i den stil, der bliver brugt i det projekt, du arbejder på. Du må ikke ændre en andens kode, så den matcher din foretrukne stil.  Folk er uperfekte. Jeg fortæller dig dette som Doktor Bilaabo. "

"Tak for den interessante lektion, Bilaabo. Jeg vil gå og reflektere over, hvad du har sagt."