Navnekonvensjoner, kodekonvensjoner

"Hei, Amigo! I dag skal jeg fortelle deg om kodestiler og viktigheten av kodestil."

"Jeg starter med det som betyr mest.  Java-kode skal være lett å lese.  Den generelle tilnærmingen til koden er denne: koden skrives én gang, men leses hundre ganger."

"Anta at du og 10 andre programmerere skriver en søknad. Dere jobber med applikasjonen i tre år, med mellomliggende utgivelser hver tredje måned."

"Så lenge?"

"Dette er Java, min unge gresshoppe! "Hva med et bedriftssystem som kjører på et dusin servere og er skrevet av 100 personer over mer enn 6 år? Det skjer også noen ganger."

"Wow."

"Hovedregelen, hovedkravet for kode er uansett at det må være enkelt for andre utviklere å lese."

"I andre programmeringsspråk jobber folk ofte som små team med små oppgaver, så de kan ha en annen hovedregel, for eksempel "Det fungerer? Utmerket".

"I løpet av et par år vil alle teammedlemmene dine gjøre flere endringer i koden du har skrevet. Og hver gang må de forstå hvordan koden fungerer."

"Og uforståelig kode som fungerer perfekt er vanskelig å endre.  De vil forkaste den og omskrive den på sin egen måte.  Så skriv kode som andre kan forstå.  Hvis du kan forbedre koden din, så forbedre den. Hvis den kan forbedres, da må det forbedres! "

"Hvis du skriver kode i 15 minutter og deretter bruker to timer på å forbedre den, gjør du det riktig. Hvor mye tid sparer du laget?"

"'2 timer for å forstå koden din' x 'de 100 gangene folk trenger å forstå den' = 200 timer."

"Jeg trakk disse tallene ut av løse luften, men jeg vil at du skal forstå problemet og omfanget.  Koden din er laget for å kunne leses av andre programmerere.  Alt annet er sekundært."

"Fungerer ikke koden som den skal? Vi fikser den. Ikke optimalisert? Vi optimaliserer den. Ikke dokumentert? Vi legger til kommentarer."

" Er koden vanskelig å lese? Kast den dritten i søpla og skriv alt på nytt fra bunnen av! "

— Jeg trodde ikke det var en så stor sak.

"En av grunnene til at Java er et ledende programmeringsspråk er at all Java-kode er skrevet for å kunne leses av andre programmerere."

"La oss nå gå videre til det andre spørsmålet: hvordan gjør du koden din så lett å lese som mulig? "

"Alle kan forstå når noen snakker kjente ord på hans eller hennes morsmål. Det samme gjelder her. Koden er lett å lese når en programmerer lett kan gjette:

A)  Hva hver metode gjør

B)  Formålet med hver klasse

C)  Nøyaktig hva hver variabel lagrer.

Alt dette kommuniseres i navn: klassenavn, metodenavn og variabelnavn. I tillegg er det stil når det kommer til å navngi variabler. Og det er kodestil."

"Jeg er klar til å lytte."

" Programmering er basert på godt engelsk!  Et velskrevet program er som vanlig teknisk dokumentasjon. "

" La oss begynne med navn. "

"Et metodenavn skal kort beskrive hva metoden gjør. Da kan koden leses som enkel 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;
}

"Her er hvordan et slikt program leses."

Linje 1.

"Metoden kalles 'downloadPhoto'. Det ser ut til at den laster ned en bildefil fra Internett. Hvor lastes den ned til? Vi vet ikke ennå. Hvorfra? Metoden har en parameter som heter url — det er sannsynligvis URL-en til nedlastingen."

Linje 3.

"Variabelen resultFileName er deklarert og tildelt en verdi av TempHelper.createTempFileName();"

Så dette må være den lokale banen til filen der vi skal lagre den nedlastede filen.

"Navnet 'TempHelper' forteller oss ingenting. 'Helper'-suffikset sier at dette er en slags verktøyklasse som ikke inneholder viktig forretningslogikk, men som snarere brukes til å forenkle rutineoppgaver som forekommer ofte."

"Metodenavnet 'createTempFileName' indikerer at denne metoden oppretter og returnerer navnet på en midlertidig fil (temp-fil). En midlertidig fil er en midlertidig fil som opprettes for en stund og deretter vanligvis slettes når programmet lukkes. "

Linje 5.

"Et SingleFileDownloader-objekt opprettes og tilordnes til variabelnedlasteren."

Dette er objektet som vil laste ned filen vår fra Internett.

"Et SingleFileDownloader-objekt er tilordnet variabelen nedlaster. Ut fra navnet kan vi anta at programmet har flere typer nedlastningsklasser. En ble skrevet for nedlasting av enkeltfiler, og vi kan nok forvente å møte andre nedlastere i koden for grupper. av filer med navn som: MultiFileDownloader, FileGroupDownloader eller DirectoryDownloader"

Linje 6.

"Vi setter nedlastningsobjektets resultFileName-egenskap lik verdien av variabelen resultFileName. Med andre ord forteller vi lasteren hvor den nedlastede filen skal lagres. Som du forventer. Så, vi forutsier i utgangspunktet koden!"

Linje 7.

"Vi kaller startmetoden. Nedlastingen starter. Det gir mening. Jeg lurer på hvordan nedlastingen skjer: i deler, på en egen tråd, eller hele greia her? Hvis vi laster ned hele her, kan det ta en lang tid og får konsekvenser."

Linje 8-11.

"Ah. Her ser vi standardsløyfen skrevet av noen som venter på at en nedlasting skal fullføres. Downloder-objektet har en done-egenskap, som returneres av isDone()-metoden. Fordi metoden kalles isDone(), i stedet for getDone( ), konkluderer vi med at den utførte variabelen er en boolsk eller kanskje en boolsk."

Linje 13-14.

"Hvis det oppstår en feil under nedlastingen, returnerer downloadPhoto-metoden null. Det er bra at den håndterer feil. Det er dårlig at den bare returnerer null - det er ikke klart hva feilen er. Det ville være bedre å kaste et unntak med informasjon om feilen."

Linje 16.

"Vi returnerer banen til den lokale filen som inneholder den nedlastede filen."

"Wow!"

"Koden til dette programmet gjør det helt klart hva det gjør. Du kan til og med gjette på hvordan programmet er organisert og hvilke andre klasser/metoder vi finner."

"Nå forstår jeg hvor viktige navn er."

"Mer om navn. Du kan ofte gjette hvilke metoder et objekt/klasse har. For eksempel, hvis et objekt er en samling, så vil det mest sannsynlig ha en size() eller count() metode for å få antall elementer. Også , vil den sannsynligvis ha en add() eller insert() metode. Elementer hentes fra samlingsklasser ved å bruke get/getItem/getElement-metodene."

"Hvis en variabel heter i, j eller k, så er det mest sannsynlig en loopteller."

"Hvis en variabel kalles m eller n, så er det mest sannsynlig størrelsen på en matrise/samling."

"Hvis en variabel heter navn, er det mest sannsynlig en streng som inneholder noens navn."

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

"Jo mer kode du ser, jo lettere er det å lese andres kode."

"Men noen ganger er det kode som er veldig vanskelig å lese. I dette tilfellet er her et veldig praktisk råd:"

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

"Nå litt om stilene som brukes til å navngi variabler."

"Java-utviklere prøver å gi svært informative navn til variabler og metoder. Som et resultat består navn ofte av flere ord. Det er 4 stiler for bruk av store bokstaver i sammensatte navn."

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

"Grønt hus"  blir "drivhus"

'Hollywood-jente'  blir  'hollywoodjente'

Denne stilen brukes for pakkenavn.

2) Store bokstaver  – Alle ord er skrevet med store bokstaver og atskilt med et understrek. For eksempel:

'Maksverdi'  blir MAX_VALUE

'Cat count'  blir CAT_COUNT

"Denne stilen brukes for navn på konstanter (endelige statiske felt)."

3) CamelCase  – Alle ord er skrevet med små bokstaver, bortsett fra at den første bokstaven i hvert ord er stor. For eksempel:

"Green House"  blir  "GreenHouse"

«Hollywood-jente»  blir «HollywoodGirl»

Denne stilen brukes for navn på klasser og grensesnitt.

4) Lavere CamelCase (blandet bokstav)  – Alle ord er skrevet med små bokstaver, bortsett fra den første bokstaven i hvert ord, bortsett fra at den første er stor. For eksempel:

'Get width' blir 'getWidth'

'Get Hollywood girl name' blir  'getHollywoodGirlName'

"Denne stilen brukes for navn på variabler og metoder."

"Så, det er ikke så mange regler."

1)  Alt er skrevet i Lower CamelCase.

2)  Navn på klasser og grensesnitt er alltid store.

3)  Pakkenavn er alltid små bokstaver.

4)  Konstanter er alltid store bokstaver.

"Det er et par nyanser, men generelt er det det det er."

"Nå om metoder.  "Metodenavn begynner nesten alltid med et verb! 'telle' er et dårlig navn på en metode. Det er bedre å kalle det getCount(). En metode utfører en handling på objektet:  startDownload , interrupt  , sleep  , loadPirateMusic ."

"Som du allerede vet, finnes det gettere og settere for å arbeide med et objekts egenskaper/felt:  getName / setName , getCount / setCount , etc."

"Det eneste unntaket er for booleanere. For booleanere bruker getternavn 'er', ikke 'get', f.eks. isDone, isEmpty. På denne måten er det nærmere vanlig tale."

"Hva med å jobbe to timer om dagen i stedet for åtte? Fristet?"

"Ja!"

"Som du burde være. For en junior Java-utvikler er det grunnleggende kravet en utmerket forståelse av det grunnleggende i Java, dvs. Java Core."

"Jeg har et annet spørsmål. Hvorfor har vi disse forskjellige metodene for å få antall elementer?"

"Først og fremst ble Java oppfunnet for mer enn 20 år siden, før krav som setCount / getCount var etablert, og det var en vanlig tilnærming hentet fra C-språket for å 'gjøre det så kort som mulig'."

"For det andre spiller semantikk en rolle her. Når vi snakker om en matrise, snakker vi om lengden. Når vi snakker om en samling, snakker vi om størrelsen."

"For en interessant leksjon."

"Jeg vil gjerne fortelle deg mer, men jeg er redd du ikke husker alt på en gang. Det er bedre å dele det ut til deg i små porsjoner."

"Men jeg ønsker å komme inn på stil angående bruken av krøllete parenteser: {}. Det er to tilnærminger:"

1)  Braketten går på ny linje hver gang

2)  Åpningsbraketten går på slutten av forrige linje, mens lukkebeslaget går på en ny linje. Denne stilen kalles "egyptiske seler".

"Ærlig talt, du får velge hvordan du skal kode. Mange bruker en åpningsbøyle på samme linje. Mange setter den på en ny linje. Det er som debatten om hvilken ende av egget som skal knekkes: den lille enden eller den store slutt."

"Det eneste jeg kan anbefale er å holde deg til den stilen som brukes i prosjektet du jobber med. Ikke endre noen andres kode for å matche din foretrukne stil.  Folk er ufullkomne. Jeg forteller deg dette som doktor Bilaabo. "

"Takk for den interessante leksjonen, Bilaabo. Jeg skal gå for å reflektere over det du har sagt."