Constanten
ik wou wel eens weten hoe schrijven jullie constanten/defines schrijven.
Alles in hoofdletters
Alles in kleine letters
Eerste letter per woord in hoofdletters en de est in kleine
nog iets anders
Jan
Merendeel constanten trouwens. Wel fijn als alles z'n eigen namespace heeft.
Code (php)
1
if($foo->status == Model\Foo::STATUS_BAR) ...
(voorkomt ook dat je binnen de class altijd enorme prefixen nodig hebt - dan is het gewoon self::STATUS_BAR).
Gewijzigd op 29/08/2020 11:02:37 door Rob Doemaarwat
- FOO_BAR : constante
- foo_bar : variabele/parameter
- FooBar : klasse
- fooBar : functie/methode
Of je je constante FOO_BAR noemt of foo_bar of FooBar is aan jou ... tenzij je in een team werkt en andere afspraken hanteert.
Wel is het vaak zo dat voor constanten alleen hoofdletters worden gebruikt. Op die manier zie je direct dat het om een constante gaat. Dus als ik je zou mogen adviseren, zou ik zeggen gebruik alleen hoofdletters, maar als je zelf iets anders prettiger vindt werken dan mag dat ook, zolang je het maar consequent toepast.
Misschien is ook een betere of minstens zo interessante vraag wanneer je constanten zou moeten inzetten. Ik zou hier terughoudend in zijn, het is lang niet altijd nodig om een variabele met een constante waarde maar te bombarderen tot constante.
Een eigenschap van constanten is dat deze een universele scope hebben. Wanneer je dus (de waarde van) een variabele (die constant is) in meerdere scopes gebruikt, dan zou dit een argument kunnen zijn om hier een constante van te maken.
>> Dan lijkt mij de aanpak van @Ward beter en breder geaccepteerd.
Beter en breder geaccepteerd dan wat?
>> Misschien is ook een betere of minstens zo interessante vraag wanneer je constanten zou moeten inzetten.
En hier je eigen antwoord :)
>> Een eigenschap van constanten is dat deze een universele scope hebben.
Je kunt ze in een class gebruiken als class constants. Ze worden vaak gebruikt om default waardes in te stellen. En in globale zin kun je ze gebruiken om bijv. een DEVELOPMENT_MODE in te stellen of een APPLICATION_PATH. Maar in het algemeen gebruik je ze inderdaad zo weinig mogelijk.
Ozzie PHP op 29/08/2020 22:58:23:
Beter en breder geaccepteerd dan wat?
Dan foo_bar of FooBar. Dat zorgt voor verwarring. Ontbreekt daar een $ of methode- of class-haken? Of wordt daar toch een constante bedoeld? Hoe dan ook, deze schrijfwijze zet je elke keer dat je die code ziet aan tot nadenken.
Als je bij ontwikkeling niet alert bent dan sluipen er mogelijk ook fouten doorheen door dit soort schrijfwijzen. Bij FOO_BAR is het meteen duidelijk en "zelfdocumenterend" door de vorm, het valt ook gewoon op vanwege de blokletters.
Je zou ook consequent een BrEeZaH-schrijfwijze kunnen hanteren, maar simpelweg iets consequent (op een onhandige manier) schrijven is nou niet bepaald een zelfrechtvaardigend argument.
edit
Ozzie PHP op 29/08/2020 22:58:23:
Je kunt ze in een class gebruiken als class constants.
Die zijn toch ook overal beschikbaar? Het feit dat ze in een klasse staan gedefinieerd doet hier niets aan af?
Gewijzigd op 29/08/2020 23:15:23 door Thomas van den Heuvel
Klopt, ik gebruik het ook en ik raad het ook aan. Maar het is geen verplichting. Misschien wil iemand graag FoO_BaR gebruiken. Dat kan en werkt ook. Ik bedoel te zeggen dat het soms lijkt alsof sommige zaken 'regels' zijn, terwijl het in feite handigheden zijn. Ja, ik raad in dit geval ook aan om hoofdletters te gebruiken, maar het is geen verplichting. Het is niet zo dat je code ineens niet meer werkt of slechter wordt als je niet alles in hoofdletters schrijft.
>> Je zou ook consequent een BrEeZaH-schrijfwijze kunnen hanteren, maar simpelweg iets consequent (op een onhandige manier) schrijven is nou niet bepaald een zelfrechtvaardigend argument.
Hehe lol ... dan bevind je je op een vlak van wat onhandig is. Misschien vindt iemand BrEeZaH wel handig, leuk of grappig en kan dat voor hem/haar een reden zijn om het wel zo te doen. Het is net zo consequent als BREEZAH.
>> Die zijn toch ook overal beschikbaar? Het feit dat ze in een klasse staan gedefinieerd doet hier niets aan af?
Jawel, maar dan roep je ze aan in relatie tot een class. Universele constanten kun je altijd gewoon in het wilde weg overal aanroepen. Daarom wordt het ook afgeraden, omdat er niet een bepaalde context/scope is.
Gewijzigd op 30/08/2020 00:38:38 door Ozzie PHP
• Class names MUST be declared in StudlyCaps.
• Class constants MUST be declared in all upper case with underscore separators.
• Method names MUST be declared in camelCase.
Het is maar een Recommendation, dus als je denkt dat je het beter weet, kun je ervan afwijken...
Ik zeg niet dat je altijd ABN zou moeten gebruiken (dit beweer ik ook nergens) maar ik vind het wel heel erg belangrijk dat communicatie altijd zo goed en makkelijk mogelijk verloopt. En daarmee heb je doorgaans het meeste succes wanneer je ABN gebruikt.
Heb je je eigen knutselproject: leef je uit. Maar ben je met iets groters bezig en werk je hier met anderen aan of communiceer je hier met anderen over, dan is het wel zo beleefd om zoveel mogelijk een algemeen geaccepteerde spreektaal (of programmeerwijze) te hanteren. Niemand heeft zin om rare constructies te ontcijferen en meestal hield dat al in dat de aanpak gewoon verkeerd was.
Zo had ik een buitenlandse collega in een vorige baan. Deze kerel had zijn inburgeringscursus met de hakken over de sloot gehaald en ging er zelf nogal prat op dat hij dit met enige handigheid voor elkaar had gekregen door bij het theoretische deel (het was een multiple choice toets) slim te gokken. Het praktijkdeel was nogal desastreus. Desalniettemin was hij geslaagd... maar sprak eigenlijk geen woord Nederlands.
Dit was verder ook helemaal niet erg, want wij communiceerden gewoon in het Engels en dat ging prima. Totdat ons bedrijf werd ingelijfd bij een ander bedrijf waarbij uitsluitend in het Nederlands werd gecommuniceerd. Ik heb de reden voor deze "regel" nooit kunnen achterhalen, waarschijnlijk was het ook echt nergens op gebaseerd en was het gewoon breinloze, stompzinnige kortzichtigheid. Maar goed, dit werkte dus averechts.
Het kan nooit de bedoeling zijn dat je een methode voorop stelt om een doel te behalen en dit doe ik ook niet. Het gaat erom dat de methode zorgt voor minimale weerstand bij het bereiken van het doel, of in ieder geval het zo dicht mogelijk in de buurt komen hiervan.
Geloof het of niet, maar hier zijn standaarden (mede) voor bedoeld.
Wat ik als toevoeging probeer aan te geven, is dat standaarden zinvol zijn om te volgen, maar dat het geen harde regels zijn. Vaak worden hier op het forum zaken als regels/verplichtingen gepresenteerd. Voor mensen die nog niet zo heel lang programmeren, is dit enerzijds interessant omdat het ze in de goede richting kan sturen. Maar anderzijds geeft het de indruk dat iets op een bepaalde manier móet ... omdat het anders niet werkt. Ik probeer daar zelf wat nuance in aan te brengen.
Nu gaat het over iets realtiefs kleins/simpels als naamgeving, maar dit soort discussies heb ik ook veelvuldig voorbij zien komen over de implementatie van een MVC-systeem, waarbij conventies werden gepresenteerd als keiharde regels die gevolgd móeten worden.
Dus, ja ... standaarden/conventies zijn super nuttig, maar er mag als daar behoefte is ook van worden afgeweken.
Programmeren is een beetje als het schrijven van een boek. Zet 10 mensen naast elkaar en ze zullen een bestaand verhaal allemaal op een andere manier opschrijven. En daar kunnen dan meerdere heel goede boeken uit voortvloeien.
Ozzie PHP op 30/08/2020 21:55:48:
Programmeren is een beetje als het schrijven van een boek. Zet 10 mensen naast elkaar en ze zullen een bestaand verhaal allemaal op een andere manier opschrijven. En daar kunnen dan meerdere heel goede boeken uit voortvloeien.
Syntaxisstandaarden zijn vergelijkbaar met spellingregels: schrijf gerust je eigen verhaal, maar begin een zin bij voorkeur met een hoofdletter.
Bedenk dat coding standards mede zijn bedoeld om discussie over dit soort beslissingen te voorkomen, daar zo min mogelijk over te hoeven nadenken en er geen tijd aan te hoeven verspillen.
Ward van der Put op 31/08/2020 11:19:02:
Bedenk dat coding standards mede zijn bedoeld om discussie over dit soort beslissingen te voorkomen, daar zo min mogelijk over te hoeven nadenken en er geen tijd aan te hoeven verspillen.
PSR-12, paragraaf 2.4 ... succes ;-)
Ward van der Put op 31/08/2020 11:19:02:
Richtlijnen zijn top, maar je kunt er vanaf wijken.
ervan afwijken :-)
Gewijzigd op 31/08/2020 12:51:26 door Ward van der Put
Ergens wel grappig weer, maar dat was natuurlijk niet de bedoeling.
Zie je ... ik week af van de richtlijnen, en toch begreep je precies wat ik bedoelde ;-)
Maareh ... plaats je de rest van mijn bericht weer even terug :-s
Er kan helaas wel meer niet.
Ozzie PHP op 30/08/2020 21:55:48:
Wat ik als toevoeging probeer aan te geven, is dat standaarden zinvol zijn om te volgen, maar dat het geen harde regels zijn.
Okay kapitein Barbossa. Ben het hier overigens mee eens, maar... (zie vervolg)
Ozzie PHP op 30/08/2020 21:55:48:
móet
Niets moet, maar als je geen beter idee hebt kun je net zo goed een werkwijze of voorstel volgen. Als de enige motivatie "dwarsliggen" is zou je je ook kunnen afvragen waarom iemand vragen stelt terwijl deze persoon het beter denkt te weten. Dan is er iets anders aan de hand lijkt mij, en dat kan alleen door de persoon in kwestie zelf opgelost worden, mits je een optimistische kijk op de wereld hebt.
Ozzie PHP op 30/08/2020 21:55:48:
Nu gaat het over iets realtiefs kleins/simpels als naamgeving, maar dit soort discussies heb ik ook veelvuldig voorbij zien komen over de implementatie van een MVC-systeem, waarbij conventies werden gepresenteerd als keiharde regels die gevolgd móeten worden.
Ik denk niet dat je dit echt kunt vergelijken met codeconventies. Ten eerste omdat het vele malen complexer is dan "simpelweg" conventies. Ten tweede omdat er op het internet een heleboel kampen bestaan die overtuigd zijn van hun eigen gelijk over hoe MVC er uit zou moeten zien (en dit probleem zit weer in hetzelfde straatje als hierboven). Dan is er al geen enkele ruimte meer mogelijk voor echte discussie of nuancering en sterker nog, dat zijn vaak simpelweg geen discussies. En ten derde omdat MVC een idee is. Eenzelfde idee kan op legio manieren geïmplementeerd worden al naar gelang de behoefte. Het laatste wat je zou moeten doen is MVC "voor de vorm" gebruiken omdat je gehoord had dat dat "de shit" was en dat je je vervolgens in allerlei bochten moet wringen om dingen voor elkaar te krijgen door de zelf opgeworpen MVC-muren. Dat is wederom de vorm voorop stellen / het paard achter de wagen spannen. En misschien moet je dat (vorm voorop stellen) bij conventies juist wel doen, het schrijft immers expliciet voor wat deze vorm -met goed beargumenteerde redenen- zou moeten zijn.
Ozzie PHP op 30/08/2020 21:55:48:
Dus, ja ... standaarden/conventies zijn super nuttig, maar er mag als daar behoefte is ook van worden afgeweken.
Standaarden zijn er om van af te wijken. Waar heb ik dit eerder gehoord.
kijk, als je alleen werkt kun je dingen zo programmeren dat je er mogelijk alleen zelf chocola van kunt maken, maar indien deze wordt hergebruikt en/of wordt gedeeld, dan zal deze gewoon moeten voldoen aan een bepaalde norm.
Misschien is het enkel discussiëren over conventies in afzondering ook nogal loos zonder het bekijken van toepassingen.
Daarbij, deze "behoefte" zal gemotiveerd moeten kunnen worden. Je moet jezelf en anderen kunnen overtuigen of op zijn minst kunnen uitleggen waarom jij denkt dat de afwijking een betere keuze is dan de standaard uitvoering. Als de behoefte niets meer is dan "laten we het eens over een andere boeg gooien" of "ik heb vanavond zin in chili con carne" dan zijn de argumenten natuurlijk niet zo sterk...
Ook het argument "ik wil kunnen afwijken van de norm" an sich is niet genoeg. Er moet een zekere noodzaak (reden) zijn om dit te doen waarbij de standaard aanpak tekort schiet.
Ozzie PHP op 30/08/2020 21:55:48:
Programmeren is een beetje als het schrijven van een boek. Zet 10 mensen naast elkaar en ze zullen een bestaand verhaal allemaal op een andere manier opschrijven. En daar kunnen dan meerdere heel goede boeken uit voortvloeien.
Maar zoals @Ward aangeeft: regels voor de opbouw van zinnen zullen nog steeds van toepassing zijn, anders kan niemand een touw vastknopen aan het verhaal. Dat is waar we het hier ook over hebben: de zinsopbouw, niet het verhaal. Hoe je deze bouwstenen verder tot lopende zinnen combineert en het verhaal wordt verteld is aan de auteur.
Daarover (hoe je goede verhalen zou moeten schrijven) bestaan overigens ook ideeën en best practises.
Gewijzigd op 31/08/2020 16:48:06 door Thomas van den Heuvel