Arrghh ... het ligt op het puntje van m'n tong ... maar ik kan er niet op komen.
Ik heb op mijn server een mapje waarin alle "code" van de website staat. Simpel gezegd is dat alle php en html code (eigenlijk alles behalve media-bestanden). Dat mapje heet op dit moment "private" omdat het buiten de document root staat en dus onbereikbaar is via de browser.
Echter, ik vind "private" eigenlijk niet zo'n goede naam meer. Immers, alles wat op de server staat en niet bereikbaar is via de browser is in principe 'private'. Een beetje nietszeggend dus.
Ik wil de naam dus wijzigen in een naam die aangeeft dat in die map alle code staat. De naam "code" vind ik dan weer te algemeen. Ik zit aan iets te denken als 'app' of 'program', maar iets zegt me dat er nog een betere naam is ... alleen ik kan er dus ff niet opkomen. Grr...
De naam moet aangeven dat in die map de "intelligentie", "besturing" of "workflow" van de website staat ... iets in die richting. Het moet niet te algemeen en vaag zijn (zoals bijv. 'core') en het moet ook kort zijn. App en program zou kunnen, maar zijn er wellicht nog betere opties?
Thanks beiden. Ik denk dat je "binnen" een functie wellicht $char_pos kan gebruiken op het moment dat $character_position teveel ruimte inneemt. Persoonlijk vind ik $pos weer net wat te nietszeggend. Maar qua functienamen moet het idd duidelijk zijn wat het is, omdat je die moet kunnen aanroepen. Maar het valt me dus eigenlijk wel op dat iedereen het anders doet.
De een gebruikt dDir(), de ander delDir(), weer een ander deleteDir() en weer een ander deleteDirectoy(). Blijkbaar is er niet echt een conventie, en doet iedereen zomaar wat ie zelf op dat het moment het handigst vindt. Het mooie aan een korte omschrijving als delDir() vind ik dat het lekker compact is, wat Ben ook zegt ... short, sweet en to the point. Maar je moet bij het nalezen dan wel even nadenken wat delDir() ook al weer betekende. Dat probleem heb je bij deleteDirectory() dan weer niet, maar zo'n lange naam maakt je code wel "wolliger". Dus wat is wijsheid ... als die er überhaupt al is betreffende dit onderwerp?
Use Intention-Revealing Names
The name of a variable, function, or class, should answer all the big questions. It should tell you why it exists, what it does, and how it is used. If a name requires a comment, then the name does not reveal its intent.
Avoid Disinformation
Programmers must avoid leaving false clues that obscure the meaning of code. We should avoid words whose entrenched meanings vary from our intended meaning.
Use Pronounceable Names
Humans are good at words. A significant part of our brains is dedicated to the concept of words. And words are, by definition, pronounceable.
Use Searchable Names
Single-letter names and numeric constants have a particular problem in that they are not easy to locate across a body of text. […] My personal preference is that single-letter names can ONLY be used as local variables inside short methods. The length of a name should correspond to the size of its scope.
Avoid Encodings
We have enough encodings to deal with without adding more to our burden. Encoding type or scope information into names simply adds an extra burden of deciphering.
Avoid Mental Mapping
Readers shouldn’t have to mentally translate your names into other names they already know. This problem generally arises from a choice to use neither problem domain terms nor solution domain terms.
Class Names
Classes and objects should have noun or noun phrase […]
A class name should not be a verb.
Method Names
Methods should have verb or verb phrase names […]
Accessors, mutators, and predicates should be named for their value and prefixed with get, set, and is according to the javabean standard.
Don’t Be Cute
If names are too clever, they will be memorable only to people who share the author’s sense of humor, and only as long as these people remember the joke.
Pick One Word per Concept
Pick one word for one abstract concept and stick with it.
Use Solution Domain Names
Remember that the people who read your code will be programmers. So go ahead and use computer science (CS) terms, algorithm names, pattern names, math terms, and so forth.
Use Problem Domain Names
When there is no “programmer-eese” for what you’re doing, use the name from the problem domain.
Dus wat is wijsheid ... als die er überhaupt al is betreffende dit onderwerp?
Zoals met zoveel dingen: zo simpel mogelijk, maar niet simpeler.
delDir() is wat mij betreft even duidelijk als deleteDirectory(). Wel (of nog veel) belangrijk(er) is dat namen niet misleidend zijn. Het moet doen wat het zegt (of impliceert) dat (wat) het doet.
Hangt er vanaf hoe we aan het programmeren zijn en wat we aan het maken zijn.
Standalone script: delDir() lijkt mij goed genoeg? Denk aan importscript oid. Als je iets vaker dan 1x gebruikt -> maak een functie. Liefst met een omschrijvende naam.
Groter systeem (vaak onderhevig aan conventies): deleteDirectory() of wat er voorgeschreven wordt.
Maar als het een groter systeem betreft werk je vaak/vaker object georiënteerd, dus dan wordt het een delete() methode van een of andere klasse...
Ik kan hier (wederom :p) niet op voorhand zeggen (een eenduidig antwoord geven) wat ik zou gebruiken omdat ik het toepassingsgebied (de context) niet ken.
Nee klopt, ik maak het je een beetje lastig ;-)
Het gaat me eigenlijk ook meer om de besluitvorming die eraan ten grondslag ligt. Mijn idee is dat je altijd consistent moet zijn (mee eens?) en dat je dus op verschillende plekken hetzelfde doet.
Op het moment dat je dus in plaats van een class Directory met een method delete() kiest, je kiest voor een class Dir met de method del(), dan vind ik dat je overal in je applicatie of framework voortaan del moet gebruiken ipv delete en dir ipv directory. Het zou dan dus bijv. ook Cache::del() worden en niet Cache::delete(). Cache is echter weer veel korter dan Directory en de noodzaak om het woord te verkleinen is hier weer een stuk minder. Maaaaar ... je kan niet de ene keer del gebruiken en de andere keer delete. Mijn vraag is dus ... wanneer ga je afkorten? Of kun je functienamen gewoon beter helemaal nooit afkorten? Maar wat doe je dan met een functienaam als generateRandomColorScheme(). Laten we dat zo, of maken we daar genRandColScem() van? Om maar eens wat te verzinnen ...
Als je dan toch een van de twee op voorhand wilt kiezen :p schrijf dan alles uit. Code kan nooit duidelijk genoeg zijn.
Enne, generateRandomColorScheme() zal niet zo gauw voorkomen, het zal dan eerder iets worden als ColorScheme::generate($mode) ofzo :).
Als een naam "te lang" wordt dan zou er een lampje moeten gaan branden. Mogelijk doet je functie/methode dan te veel of sla je door in het proberen te vangen wat iets doet.
