Naamgevingsconventies, codeconventies

"Hallo, Amigo! Vandaag ga ik je vertellen over codestijlen en het belang van codestijl."

"Ik zal beginnen met wat het belangrijkst is.  Java-code moet gemakkelijk leesbaar zijn.  De algemene benadering van de code is deze: code wordt één keer geschreven maar honderd keer gelezen."

“Stel dat je met 10 andere programmeurs een applicatie aan het schrijven bent. Je werkt drie jaar aan de applicatie, met eens in de drie maanden een tussentijdse release.”

"Zo lang?"

"Dit is Java, mijn jonge sprinkhaan! "Wat dacht je van een bedrijfssysteem dat draait op een dozijn servers en geschreven is door 100 mensen gedurende meer dan 6 jaar? Dat gebeurt ook wel eens."

"Wauw."

"Hoe dan ook, de hoofdregel, de belangrijkste vereiste voor code is dat het voor andere ontwikkelaars gemakkelijk te lezen moet zijn."

"In andere programmeertalen werken mensen vaak in kleine teams aan kleine taken, dus misschien hebben ze nog een hoofdregel, zoals 'Het werkt? Uitstekend'."

"In de loop van een paar jaar zullen al je teamleden verschillende wijzigingen aanbrengen in de code die je hebt geschreven. En elke keer zullen ze moeten begrijpen hoe de code werkt."

"En onbegrijpelijke code die perfect werkt, is moeilijk te veranderen.  Ze gooien het weg en herschrijven het op hun eigen manier.  Schrijf dus code die anderen kunnen begrijpen.  Als je je code kunt verbeteren, verbeter hem dan. Als het verbeterd kan worden, dan moet het verbeterd worden! "

"Als je 15 minuten code schrijft en vervolgens twee uur besteedt aan het verbeteren ervan, doe je het goed. Hoeveel tijd bespaar je het team?"

"'2 uur om uw code te begrijpen' x 'de 100 keer dat mensen het moeten begrijpen' = 200 uur."

"Ik heb deze cijfers uit de lucht gehaald, maar ik wil dat je het probleem en de omvang ervan begrijpt.  Je code is gemaakt om door andere programmeurs te worden gelezen.  Al het andere is secundair."

"Werkt de code niet correct? We repareren het. Niet geoptimaliseerd? We optimaliseren het. Niet gedocumenteerd? We voegen opmerkingen toe."

" Is de code moeilijk te lezen? Gooi die onzin in de prullenbak en schrijf alles opnieuw vanaf nul! "

"Ik dacht niet dat het zo'n groot probleem was."

"Een van de redenen waarom Java een toonaangevende programmeertaal is, is dat alle Java-code is geschreven om door andere programmeurs te worden gelezen."

"Laten we nu verder gaan met de tweede vraag: hoe maak je je code zo gemakkelijk leesbaar mogelijk? "

"Iedereen kan het begrijpen wanneer iemand bekende woorden in zijn of haar moedertaal spreekt. Hetzelfde geldt hier. Code is gemakkelijk te lezen wanneer een programmeur het gemakkelijk kan raden:

A)  Wat elke methode doet

B)  Het doel van elke klasse

C)  Precies wat elke variabele opslaat.

Dit alles wordt gecommuniceerd in namen: klassenamen, methodenamen en variabelenamen. Bovendien is er stijl als het gaat om het benoemen van variabelen. En er is codestijl."

"Ik ben klaar om te luisteren."

" Programmeren is gebaseerd op goed Engels!  Een goed geschreven programma leest als gewone technische documentatie. "

" Laten we beginnen met namen. "

"Een methodenaam moet in het kort beschrijven wat de methode doet. Vervolgens kan de code worden gelezen als eenvoudig proza."

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;
}

"Hier is hoe zo'n programma wordt gelezen."

Lijn 1.

"De methode heet 'downloadPhoto'. Het lijkt erop dat het een fotobestand van internet downloadt. Waarheen wordt het gedownload? We weten het nog niet. Van waar? De methode heeft een parameter met de naam url - dat is waarschijnlijk de URL voor het downloaden."

Lijn 3.

"De variabele resultFileName wordt gedeclareerd en er wordt een waarde aan toegekend door TempHelper.createTempFileName();"

Dit moet dus het lokale pad zijn naar het bestand waar we ons gedownloade bestand zullen opslaan.

"De naam 'TempHelper' zegt ons niets. Het achtervoegsel 'Helper' zegt dat dit een soort utility-klasse is die geen belangrijke bedrijfslogica bevat, maar eerder wordt gebruikt om routinematige taken die vaak voorkomen te vereenvoudigen."

"De methodenaam 'createTempFileName' geeft aan dat deze methode de naam van een tijdelijk bestand (tijdelijk bestand) aanmaakt en retourneert. Een tijdelijk bestand is een tijdelijk bestand dat een tijdje wordt aangemaakt en vervolgens meestal wordt verwijderd tegen de tijd dat het programma wordt afgesloten. "

Lijn 5.

"Er wordt een SingleFileDownloader-object gemaakt en toegewezen aan de variabele downloader."

Dit is het object dat ons bestand van internet zal downloaden.

"Een SingleFileDownloader-object is toegewezen aan de variabele downloader. Uit de naam kunnen we aannemen dat het programma verschillende soorten downloaderklassen heeft. Eén is geschreven voor het downloaden van afzonderlijke bestanden en we kunnen waarschijnlijk verwachten andere downloaders tegen te komen in de code voor groepen van bestanden met namen als: MultiFileDownloader, FileGroupDownloader of DirectoryDownloader"

Lijn 6.

"We stellen de eigenschap resultFileName van het downloader-object gelijk aan de waarde van de variabele resultFileName. Met andere woorden, we vertellen de lader waar het gedownloade bestand moet worden opgeslagen. Zoals je zou verwachten. We voorspellen dus eigenlijk de code!"

Lijn 7.

"We noemen de startmethode. De download begint. Dat is logisch. Ik vraag me af hoe de download gebeurt: in delen, op een aparte thread, of het hele ding hier? Als we het hele ding hier downloaden, kan het even duren lange tijd en gevolgen hebben."

Regels 8-11.

"Ah. Hier zien we de standaardlus geschreven door iemand die wacht tot een download is voltooid. Het downloder-object heeft een eigenschap done, die wordt geretourneerd door de methode isDone(). Omdat de methode isDone() heet in plaats van getDone( ), concluderen we dat de done-variabele een boolean of misschien een Boolean is."

Regels 13-14.

"Als er een fout optreedt tijdens het downloaden, retourneert de downloadPhoto-methode null. Het is goed dat het fouten afhandelt. Het is slecht dat het alleen null retourneert - het is niet duidelijk wat de fout is. Het zou beter zijn om een ​​uitzondering te genereren met informatie over de fout."

Lijn 16.

"We geven het pad terug naar het lokale bestand dat het gedownloade bestand bevat."

"Wauw!"

"De code van dit programma maakt het absoluut duidelijk wat het doet. Je kunt zelfs raden hoe het programma is georganiseerd en welke andere klassen/methoden we zullen vinden."

"Nu begrijp ik hoe belangrijk namen zijn."

"Meer over namen. Je kunt vaak raden welke methoden een object/klasse heeft. Als een object bijvoorbeeld een verzameling is, dan zal het hoogstwaarschijnlijk een methode size() of count() hebben om het aantal elementen te krijgen. Ook , zal het waarschijnlijk een methode add() of insert() hebben. Elementen worden opgehaald uit verzamelingsklassen met behulp van get/getItem/getElement-methoden."

"Als een variabele i, j of k wordt genoemd, is het hoogstwaarschijnlijk een lusteller."

"Als een variabele m of n wordt genoemd, dan is het hoogstwaarschijnlijk de grootte van een array/verzameling."

"Als een variabele naam wordt genoemd, is het hoogstwaarschijnlijk een string die iemands naam bevat."

"Als een klasse FileInputStream heet, dan is het tegelijkertijd een bestand en een invoerstroom."

"Hoe meer code je ziet, hoe gemakkelijker het is om de code van anderen te lezen."

"Maar soms is er code die erg moeilijk te lezen is. In dit geval is hier een heel praktisch advies:"

"Dat is grappig en niet grappig tegelijk."

"Nu een klein beetje over de stijlen die worden gebruikt om variabelen een naam te geven."

"Java-ontwikkelaars proberen zeer informatieve namen te geven aan variabelen en methoden. Daardoor bestaan ​​namen vaak uit meerdere woorden. Er zijn 4 stijlen voor het hoofdlettergebruik van samengestelde namen."

1) Kleine letters  – Alle woorden worden met kleine letters geschreven. Bijvoorbeeld:

'Kas'  wordt 'kas'

'Hollywoodgirl'  wordt  'hollywoodgirl'

Deze stijl wordt gebruikt voor pakketnamen.

2) Hoofdletters  – Alle woorden zijn geschreven met hoofdletters en gescheiden door een onderstrepingsteken. Bijvoorbeeld:

'Maximale waarde'  wordt MAX_VALUE

'Aantal katten'  wordt CAT_COUNT

"Deze stijl wordt gebruikt voor de namen van constanten (laatste statische velden)."

3) CamelCase  – Alle woorden zijn geschreven met kleine letters, behalve dat de eerste letter van elk woord een hoofdletter is. Bijvoorbeeld:

'Green house'  wordt  'GreenHouse'

'Hollywoodgirl'  wordt 'HollywoodGirl'

Deze stijl wordt gebruikt voor de namen van klassen en interfaces.

4) Lower CamelCase (gemengde hoofdletters)  – Alle woorden worden geschreven met kleine letters, behalve de eerste letter van elk woord behalve de eerste is een hoofdletter. Bijvoorbeeld:

'GetWidth' wordt 'getWidth'

'Get Hollywood-meisjesnaam' wordt  'getHollywoodGirlName'

"Deze stijl wordt gebruikt voor de namen van variabelen en methoden."

"Dus er zijn niet al te veel regels."

1)  Alles is geschreven in Lower CamelCase.

2)  Namen van klassen en interfaces worden altijd met een hoofdletter geschreven.

3)  Pakketnamen zijn altijd kleine letters.

4)  Constanten zijn altijd in hoofdletters.

"Er zijn een paar nuances, maar in het algemeen is dat wat het is."

"Nu over methoden.  "Methodenamen beginnen bijna altijd met een werkwoord! 'count' is een slechte naam voor een methode. Het is beter om het getCount() te noemen. Een methode voert een actie uit op het object:  startDownload , interrupt  , sleep  , loadPirateMusic ."

"Zoals je al weet, zijn er getters en setters voor het werken met de eigenschappen/velden van een object:  getName / setName , getCount / setCount , etc."

"De enige uitzondering is voor booleans. Voor booleans gebruiken getter-namen 'is', niet 'get', bijvoorbeeld isDone, isEmpty. Op deze manier komt het dichter bij gewone spraak."

"Wat dacht je van twee uur per dag werken in plaats van acht? Verleid?"

"Ja!"

"Zoals het hoort. Voor een junior Java-ontwikkelaar is de basisvereiste een uitstekend begrip van de basisprincipes van Java, oftewel Java Core."

"Ik heb nog een vraag. Waarom hebben we deze verschillende methoden om het aantal elementen te krijgen?"

"Allereerst werd Java meer dan 20 jaar geleden uitgevonden, voordat vereisten zoals setCount / getCount waren vastgesteld, en er was een gemeenschappelijke aanpak vanuit de C-taal om 'het zo kort mogelijk te maken'."

"Ten tweede speelt semantiek hier een rol. Als we het over een array hebben, hebben we het over de lengte ervan. Als we het over een verzameling hebben, hebben we het over de omvang ervan."

"Wat een interessante les."

'Ik zou je graag meer willen vertellen, maar ik ben bang dat je het je niet allemaal tegelijk herinnert. Het is beter om het je in kleine porties voor te schotelen.'

"Maar ik wil het wel hebben over stijl met betrekking tot het gebruik van accolades: {}. Er zijn twee benaderingen:"

1)  De haak gaat elke keer op een nieuwe regel

2)  Het openingshaakje komt aan het einde van de vorige regel, terwijl het sluithaakje op een nieuwe regel komt. Deze stijl wordt 'Egyptische bretels' genoemd.

"Eerlijk gezegd kun je kiezen hoe je codeert. Veel mensen gebruiken een accolade openen op dezelfde regel. Veel mensen zetten het op een nieuwe regel. Het is net als het debat over welk uiteinde van het ei moet worden gebroken: het kleine uiteinde of het grote einde."

"Het enige dat ik kan aanbevelen, is om vast te houden aan de stijl die wordt gebruikt in het project waaraan u werkt. Verander de code van iemand anders niet zodat deze overeenkomt met uw favoriete stijl.  Mensen zijn onvolmaakt. Ik zeg u dit als dokter Bilaabo. "

'Bedankt voor de interessante les, Bilaabo. Ik zal gaan nadenken over wat je hebt gezegd.'