PHP CodeSniffer gebruiken met WordPress Code Smells begrijpen

Vaak hangt de manier waarop we code schrijven af ​​van hoe we zijn begonnen met programmeren.

Als iemand bijvoorbeeld een formele opleiding in informatica heeft, kent hij waarschijnlijk een aantal principes waardoor hij geen code van slechte kwaliteit kan schrijven. Dit is natuurlijk geen regel, maar een observatie. 

Evenzo eindigen degenen die zelfstandig beginnen met programmeren, buiten een formele omgeving, vaak om zichzelf te leren en van verschillende bronnen te leren. Soms kan dit problemen veroorzaken met het type code dat is geschreven.

Om helemaal duidelijk te zijn: ik zeg niet dat een formele opleiding in informatica iemand overtuigt die zichzelf onderwijst, en omgekeerd. Sommige fantastische programmeurs zijn degenen die zijn opgeleid; anderen zijn degenen die autodidactisch zijn. Maar het enige dat beide met elkaar gemeen hebben, is dat ze van tijd tot tijd niet zijn vrijgesteld van het schrijven van codegeuren.

In dit artikel gaan we in een inleidende blik naar code ruikt. We gaan onderzoeken wat ze zijn, hoe ze eruit zien en hoe ze zich vaak manifesteren in het werk dat we doen. We zullen PHP gebruiken voor onze voorbeelden.

In het tweede deel van deze serie gaan we kijken hoe we het vermijden van het schrijven van code ruikt. Concreet gebruiken we PHP, een paar hulpprogramma's en WordPress als voorkeursomgeving.

Maar eerst, laten we een inleiding hebben tot code ruikt.

Wat zijn Code Smells?

Afhankelijk van het type ontwikkelaar dat je vraagt, krijg je waarschijnlijk een variatie op de volgende definitie:

Code geur, ook bekend als een slechte geur, in computerprogrammeringscode, verwijst naar elk symptoom in de broncode van een programma dat mogelijk een dieper probleem aangeeft. 

Deze definitie komt rechtstreeks uit Wikipedia. Het is niet slecht, maar het is niet mijn favoriete kijk op het onderwerp. In plaats daarvan komt mijn favoriete definitie van een productieve en populaire programmeur met de naam Martin Fowler. Je kunt zijn hele kijk op het onderwerp van codegeur in dit artikel lezen, maar ik heb het tot de volgende punten gedestilleerd:

1. "Een lange methode is daar een goed voorbeeld van - gewoon kijken naar de code en mijn neus trillen als ik meer dan een dozijn regels Java zie."
2. "Geuren zijn op zich niet slecht, ze zijn vaak eerder een indicator van een probleem dan van het probleem zelf."
   
3. "Dataklassen (klassen met alle gegevens en geen gedrag) zijn goede voorbeelden."
   

Als je het artikel niet hebt gelezen, eindigt hij hiermee:

Een van de leuke dingen over geuren is dat het voor onervaren mensen gemakkelijk is om ze te herkennen, zelfs als ze niet genoeg weten om te evalueren of er een echt probleem is of om ze te corrigeren. 

En ik denk dat dat een fantastisch statement is, omdat dit betekent dat dit onderwerp perfect gepositioneerd is voor programmeurs, maar niet zeker weet waar te beginnen als het gaat om het identificeren en aanpakken van geurtjes.

Kortom, ervaring speelt hierbij geen grote rol. Zeker, degenen die meer ervaring hebben, zullen waarschijnlijk gemakkelijker geuren herkennen (omdat ze er meer van hebben gezien), maar minder ervaren ontwikkelaars moeten in staat zijn om ze te identificeren.

Heb je voorbeelden?

Natuurlijk, als het gaat om een ​​onderwerp als geurtjes van een code, is het vaak gemakkelijker om er op een abstract niveau over te praten, zodat je er echt iets aan kunt doen. Maar dat is niet praktisch en ook niet van toepassing op ons dagelijks werk.

Met dat gezegd, waarom niet eens een kijkje nemen naar een voorbeeld van code ruikt? We zullen onderzoeken waarom ze problematisch zijn en vervolgens een oplossing bieden voor hoe de geur kan worden verwijderd door de code te refactoren.

Voorbeeld 1: Clear Naming Conventions

Een van de gemakkelijkste codes om te herkennen is wanneer een programmeur ervoor heeft gekozen om onduidelijke namen van variabelen te gebruiken. Dat wil zeggen, in de context van de code is het niet duidelijk wat een gegeven variabele geacht wordt te vertegenwoordigen.

Natuurlijk zijn er tijden dat dit acceptabel is (zoals het gebruik van een ik in een voor lus). Maar op een langere methode is het niet helemaal hetzelfde als voor lus). 

Bijvoorbeeld:

Gegeven genoeg tijd zouden we waarschijnlijk kunnen achterhalen wat dit aan het doen is. Ten eerste is het een relatief eenvoudige methode. Ten tweede zouden we de variabelen, blokken en terugkeer waarde om een ​​beter idee te krijgen van wat er gebeurt.
Maar als we op zoek zijn naar schone code die makkelijker te begrijpen is als we ernaar terugverwijzen of als een andere programmeur ermee werkt, dan helpt het gebruik van duidelijke naamgevingsconventies altijd. En de bovenstaande code maakt geen gebruik van duidelijke naamgevingsconventies.
Laten we het in plaats daarvan refactiveren zodat het er zo uitziet:
Veel gemakkelijker te begrijpen, is het niet?
Merk op dat het algoritme zelf niet is veranderd, maar de functienaam en de variabelenamen hebben. Dit heeft gemaakt dat veel van een verschil in het lezen van deze code. Op de vraag wat deze code zou moeten doen, kunnen we gemakkelijk iets zeggen als:
Retourneert een array met items die zijn gemarkeerd als waar uit een vooraf gedefinieerde reeks items.
Vermijd zoveel mogelijk het gebruik van generieke variabelenamen en gebruik wat de meest duidelijke optie is voor u en uw leeftijdsgenoten.
Voorbeeld 2: Blijf droog
Tijdens het programmeren zou het moeilijk zijn om een ​​ontwikkelaar te vinden die nog nooit van KISS of DRY had gehoord (je weet wel, "herhaal jezelf niet"). Desondanks doen we het vaak do herhaal onszelf. 
Dit is een aanwijzing voor het feit dat een poging om zich aan de DROGE principes te houden, anders belandt bij verschillende soorten programmeurs. En dat is prima! Er is geen eenduidige manier om aan te tonen hoe we ons aan dit principe houden.
Maar omdat er meerdere manieren zijn om dit te doen, kunnen we een voorbeeld geven van hoe het er niet zou moeten uitzien en hoe het eruit zou moeten zien.
Neem voor het doel van het volgende voorbeeld aan dat we een functie hebben genaamd save_post en accepteert twee argumenten: een bericht-ID en een tekenreeks die de titel van het bericht vertegenwoordigt. Een codegeur zou er ongeveer zo uitzien:
Maar waarom zouden we handmatig een oproep typen naar save_post drie keer? Laten we in plaats daarvan een associatieve array opzetten, er doorheen herhalen, en de methode vervolgens eenmaal per iteratie aanroepen.
 'Hello World!', 2 => 'Goodbye World!', 3 => 'Wat is deze nieuwe wereld?',]; foreach ($ post als $ post_id => $ post_title) save_post ($ post_id, $ post_title); 
Hoewel het een leuke methode is om de methode een keer te gebruiken, kan de methode nog flexibeler worden gemaakt door de array posts als argument te accepteren en de methode te verlaten. foreach loop intact, hoewel dat niet echt het punt is van dit voorbeeld.
Als je merkt dat je dezelfde methode gebruikt, roep dan meerdere keren in een functie, maar met andere parameters, dan ruik je misschien een code. En als je dat doet, zoek dan naar manieren om het te refactiveren, zodat je de methode maar één keer belt. 
Je wilt jezelf immers niet herhalen.
Voorbeeld 3: lange parameterlijsten
Een van de meer algemene dingen die we blijven zien in het programmeren, ongeacht de taal, is wanneer een functie een groot aantal parameters accepteert. 
Verschillende programmeurs zullen meningen hebben over wat het ideale aantal parameters is dat een functie zou moeten accepteren, maar ik heb de neiging om te denken dat drie (geef of neem twee, misschien) een goed aantal is.
Laten we eerst eens kijken hoe een functie met een lange parameterlijst eruit zou zien. Er zijn waarschijnlijk geen verrassingen in de volgende code, en u heeft mogelijk iets te maken met dit in een van uw huidige projecten:
Merk op dat we in het bovenstaande voorbeeld niet bezig zijn met de implementatie van de functie. In plaats daarvan houden we ons bezig met het aantal parameters dat nodig is. Dat is veel informatie om te verzenden, en het zal de methode oproepen dat veel lelijker ook.
Het raakt zelfs niet aan het onderwerp verificatie en validatie. Maar daarover dwaal ik af.
Hoe kan deze worden opgeruimd? Persoonlijk ben ik een fan van het maken van lessen om dergelijke informatiecollecties te vertegenwoordigen. Voor dit specifieke voorbeeld zouden we een klas kunnen hebben met de contactgegevens van een persoon. Bovendien kan die persoon aan een creditcardnummer worden gekoppeld. 
De details hiervan kunnen worden afgedwongen met behulp van bedrijfslogica elders in de toepassing, maar de abstractie ziet er ongeveer zo uit:
Deze refactoring, hoewel klein, is de grootste die we in dit specifieke artikel hebben gedaan. Merk op dat we de volgende dingen hebben gedaan:
 
Gemaakt a Contactgegevens klasse waarmee we een object kunnen instantiëren dat alle betalingsinformatie voor een persoon bevat.
 
Gemaakt a Betalingsinformatie klasse waarmee we het creditcard- of bankpasnummer voor een persoon kunnen behouden, evenals andere details die verband houden met die betaalmethode.
 
Een gemaakt Bestellen klasse, plaatste de bevestig bestelling functie erin, hernoemde het om in te dienen (sinds bevestig bestelling zou overbodig zijn), en zijn parameterlijst hebben verlaagd tot twee waarden: een instantie van de Contactgegevens klasse en de Betalingsinformatie klasse).
 
Voor de duidelijkheid: dit voorbeeld behandelt de verificatie van de koppeling tussen contactgegevens en betalingsgegevens niet en toont ook geen andere klassen die nodig kunnen zijn (bijvoorbeeld of de betaling al dan niet is mislukt voor de transactie).
Maar dat is niet het punt van de oefening.
In plaats daarvan kijken we naar de code-geur van lange parameterlijsten en hoe we deze kunnen verminderen met behulp van praktische, beter te onderhouden methoden die voor ons beschikbaar zijn.
Telkens wanneer u een functie schrijft of belt naar een functie waarvoor een groot aantal argumenten vereist is, zoekt u naar manieren om die functie te refactoren. Het maakt de samenhang van de code groter en de geur vermindert.
Conclusie
Vergeet niet dat de voorbeelden die we hierboven hebben bekeken, precies dat zijn. De lijst is absoluut niet compleet, maar het zijn veelvoorkomende geuren die je waarschijnlijk ziet in code waarmee je werkt of die je zelf codeert. Ik zal de eerste zijn om toe te geven dat ik hier schuldig aan ben.
Bovendien zijn er vele, vele bronnen die beschikbaar zijn als het gaat om het identificeren en repareren van code geuren. Gelukkig hebben we ook een aantal tools tot onze beschikking die ons zullen helpen om ze automatisch te ontdekken en op te ruimen.
En dat is waar we naartoe gaan. In het bijzonder gaan we PHP CodeSniffer gebruiken om ons te helpen code-geuren in onze code te vermijden. Vervolgens gaan we bekijken hoe we de WordPress-regels kunnen opnemen in PHP CodeSniffer en dit koppelen aan onze IDE naar keuze.
Zoals eerder in dit artikel is vermeld, zal het volgende artikel in de serie meer aandacht besteden aan code-geuren bij het schrijven van code voor WordPress. We zullen een aantal hulpmiddelen en bronnen bekijken die beschikbaar zijn om ervoor te zorgen dat we geen codes ruiken en ervoor zorgen dat we sterkere code schrijven.
Bestudeer ondertussen de bovenstaande voorbeelden en bekijk de bronnen die ik heb verstrekt, omdat dit geweldige plaatsen zijn om meer te leren over geuren en code refactoring van mensen en plaatsen die opvallen in onze branche..
Onthoud dat je al mijn cursussen en tutorials op mijn profielpagina kunt vinden, en je kunt me volgen op mijn blog en / of Twitter op @tommcfarlin, waar ik het heb over verschillende softwareontwikkelingspraktijken en hoe we ze in WordPress kunnen gebruiken..
Aarzel niet om vragen of opmerkingen achter te laten in de feed hieronder, en ik zal ernaar streven om op elk van hen te reageren.



		
			
	   
	




Code