Boolean functie benaming (is, are, of juist niet?)

[Carharttguy]

Hoi

Een ietwat filosofische programmeervraag.
Wat doen jullie als je een booleaanse functie schrijft die je grammaticaal in het meervoud zou schrijven? Begint de functienaam dan met Are ipv Is?

Voorbeeldje:

Normaal gezien gebruik ik IsOpen() of IsInitialized() omdat ik dan onmiddellijk zie dat deze functies een booleaanse waarde teruggeeft. Dit lijkt ook de meest gebruikte conventie als ik wat op het internet zoek.

Maar ik zat daarnet nu heel concreet met een functie waar ik niet goed uit geraak: Een functie waarbij je een gebruikersnaam en wachtwoord doorgeeft, en dan een True of False terug geeft, afhankelijk of de gegevens juist zijn.

Origineel had ik IsPasswordCorrect(), maar dat dekt de lading niet, want die functie checkt ook gewoon of een gebruikersnaam uberhaupt wel voorkomt in de tabel. Twee functies schrijven (IsUsernameCorrect() en IsPasswordCorrect()) lijkt een oplossing, maar dat vind ik wel een erg slechte oplossing gewoon om de naming convention te kunnen houden.

Ik zat dus te denken richting AreCredentialsCorrect(), maar ergens wringt dat toch ook.

Ik zou natuurlijk ook heel het Is() verhaal kunnen laten vallen, voor sommige functies zou dat beter lezen in een If structuur, bijvoorbeeld hier:

code:

If UserExist()..

Maar dan vind ik voor mijn credentials functie nog altijd geen goede benaming.

Ik heb al meer tijd gestoken in die functiebenaming dan het eigenlijk schrijven van de functie

Insights, ideeën, opinies.. Alles is welkom..

[KoningsGap]

14. is prefix should be used for boolean variables and methods.
isSet, isVisible, isFinished, isFound, isOpen
This is the naming convention for boolean methods and variables used by Oracle for the Java core packages.
Using the is prefix solves a common problem of choosing bad boolean names like status or flag. isStatus or isFlag simply doesn't fit, and the programmer is forced to chose more meaningful names.

Setter methods for boolean variables must have set prefix as in:

void setFound(boolean isFound);
There are a few alternatives to the is prefix that fits better in some situations. These are has, can and should prefixes:

boolean hasLicense();
boolean canEvaluate();
boolean shouldAbort = false;

Dit wordt genoemd in (een van) de java conventies, hier te vinden.

Als ik verder zoek kom ik eigenlijk nergens gebruik van 'are' tegen, en zou dit zelf dan ook niet zo heel snel doen. Ik zou in dit geval denk ik voor iets gaan als isEmailPasswordValid() of isEmailPasswordCombinationValid() oid.

[ThomasG]

Een handige vuistregel: wanneer je moeite hebt met een methode een naam te geven, klopt er iets niet. Meestal ben je dan dus in de verkeerde klasse bezig, of is er een denk/ontwerp fout gemaakt.

In het geval van IsUsernameCorrect en IsPasswordCorrect: wat wil je hiermee gaan doen? en In welke klasse ga je dit plaatsen? Aangezien het rare namen zijn hint het er al op dat er iets niet klopt. Als je er dieper over nadenkt heb je ze ook eigenlijk helemaal niet nodig. Een correcte manier zou in dit geval dus zijn om bijvoorbeeld authenticate(username, password); oid. aan te roepen, en als het niet gelukt is throwt het een exception (bijv BadCredentialsException).

Edit: in sommige gevallen heb je zoiets natuurlijk wel nodig, maar dan is het geen getter/setter maar een normale methode wat een boolean returned. Dus niet IsPasswordCorrec), maar bijv passwordMatches.

[ Voor 13% gewijzigd door ThomasG op 08-05-2019 12:39 ]

[Gomez12]

ThomasG schreef op woensdag 8 mei 2019 @ 12:32:
In het geval van IsUsernameCorrect en IsPasswordCorrect: wat wil je hiermee gaan doen? en In welke klasse ga je dit plaatsen? Aangezien het rare namen zijn hint het er al op dat er iets niet klopt. Als je er dieper over nadenkt heb je ze ook eigenlijk helemaal niet nodig. Een correcte manier zou in dit geval dus zijn om bijvoorbeeld authenticate(username, password); oid. aan te roepen, en als het niet gelukt is throwt het een exception (bijv BadCredentialsException).


Edit: in sommige gevallen heb je zoiets natuurlijk wel nodig, maar dan is het geen getter/setter maar een normale methode wat een boolean returned. Dus niet IsPasswordCorrec), maar bijv passwordMatches.

IsPasswordCorrect is wmb een 100% geldige method name, mits je business rules hebt die bepalen wanneer een password correct is.
Hetzelfde geldt voor IsUsernameCorrect.

Dus zeg jij dat een password minimaal 8 tekens moet zijn, een hoofdletter en kleine letters moet bevatten etc dan kan je gewoon de correctheid van die business rules valideren met een isPasswordCorrect

passwordMatches vind ik juist een rare naam, want ik verwacht daar een password in op te kunnen geven en een match-patroon en niet dat er 10 business rules gevalideerd worden.

voor wat de TS wenst zou je wmb kunnen zeggen : Authenticate(username, password) alleen verwacht ik dan geen true false terug te krijgen maar meer een session-token oid.
En op dat session token object kan je dan weer een method zetten .IsValid() wat true/false terug geeft en die checked dan of het session token nog wel geldig is.

Je wilt namelijk niet overal en nergens met je username en password rond gaan strooien in je code, je wilt die 1x gebruiken om te authenticeren en daarna met een intern token object verder werken. Als dat token ergens in je code uitlekt is het niet zo'n ramp, die is toch maar x uur/minuten geldig, terwijl als je username en password uitlekt dan heb je wel een ramp.

[ThomasG]

Gomez12 schreef op woensdag 8 mei 2019 @ 13:20:
[...]

IsPasswordCorrect is wmb een 100% geldige method name, mits je business rules hebt die bepalen wanneer een password correct is.
Hetzelfde geldt voor IsUsernameCorrect.

Dus zeg jij dat een password minimaal 8 tekens moet zijn, een hoofdletter en kleine letters moet bevatten etc dan kan je gewoon de correctheid van die business rules valideren met een isPasswordCorrect

passwordMatches vind ik juist een rare naam, want ik verwacht daar een password in op te kunnen geven en een match-patroon en niet dat er 10 business rules gevalideerd worden.

voor wat de TS wenst zou je wmb kunnen zeggen : Authenticate(username, password) alleen verwacht ik dan geen true false terug te krijgen maar meer een session-token oid.
En op dat session token object kan je dan weer een method zetten .IsValid() wat true/false terug geeft en die checked dan of het session token nog wel geldig is.

Je wilt namelijk niet overal en nergens met je username en password rond gaan strooien in je code, je wilt die 1x gebruiken om te authenticeren en daarna met een intern token object verder werken. Als dat token ergens in je code uitlekt is het niet zo'n ramp, die is toch maar x uur/minuten geldig, terwijl als je username en password uitlekt dan heb je wel een ramp.

Ik ging er vanuit dat het ging over authenticatie toen ik IsPasswordCorrect zag. Maar als het gaat om validatie dan is het nog steeds geen goede naam. Waar ga je dit in stoppen? Inplaats van een IsUsernameCorrect en IsPasswordCorrect heb je dan waarschijnlijk UsernameValidator en PasswordValidator klassen met een generieke isValid methode. Ik kan namelijk geen situatie bedenken waarbij een IsUsernameCorrect een goede keuze is.

[Mavamaarten]

ThomasG schreef op woensdag 8 mei 2019 @ 12:32:
Een handige vuistregel: wanneer je moeite hebt met een methode een naam te geven, klopt er iets niet. Meestal ben je dan dus in de verkeerde klasse bezig, of is er een denk/ontwerp fout gemaakt.

In het geval van IsUsernameCorrect en IsPasswordCorrect: wat wil je hiermee gaan doen? en In welke klasse ga je dit plaatsen? Aangezien het rare namen zijn hint het er al op dat er iets niet klopt. Als je er dieper over nadenkt heb je ze ook eigenlijk helemaal niet nodig. Een correcte manier zou in dit geval dus zijn om bijvoorbeeld authenticate(username, password); oid. aan te roepen, en als het niet gelukt is throwt het een exception (bijv BadCredentialsException).

Edit: in sommige gevallen heb je zoiets natuurlijk wel nodig, maar dan is het geen getter/setter maar een normale methode wat een boolean returned. Dus niet IsPasswordCorrec), maar bijv passwordMatches.

Ik ging net hetzelfde antwoorden, maar dat is idd enkel van toepassing als TS ook effectief het inloggen afhandelt en daar een method name voor zoekt.

Wanneer deze functie enkel gebruikt wordt om credentials te valideren en niet om in te loggen, is een andere oplossing ook nog een mogelijkheid: ValidationResult validateCredentials(username, password)

[Verwijderd]

Meervoud altijd vermijden, al was het maar vanwege de conventie. Ik zoek altijd op "is" in de auto-complete en ik verwacht niet iets onder "are".

Net zo min ga ik op zoek naar getters en setters onder "give / take" maar onder "set / get", om maar een debiele zijstraat te noemen.

Om het grammaticaal enigzins netjes te maken zou ik zeggen isLoginCombination / isUserDataSet?

Vind hem nog een beetje ambigu zoals je hem zelf inzet maar je vraag was niet ontwerp-technisch dus daar laat ik de rest van de users in topic topic over ruzie maken.

Sowieso: "are" niet gebruiken.

[Verwijderd]

stel je zit in een user class:

en je wil de gebruikersnaam samen met wachtwoord "valideren"

code:

$valid = false;
$username = 'pietje';
$pasword = '***';
$user = User::getByUsername($username);
if($user !== null){
    $valid = $user->validatePassword($password);
}

heb je geen user object, maar wil gewoon een functionele approach:

code:

$username = 'pietje';
$pasword = '***';
$valid = user_validate($username, $password)

ik zou persoonlijk voorkomen om de methode / functie de naamgeving van de parameter die mee moet worden gestuurd te gebruiken tenzij die parameter het onderwerp is (set / get / has / with ).

je zou bijvoorbeeld user_credential_validate kunnen gebruiken, maar dan moet je je weer af gaan vragen, waarom zou ik credential toevoegen aan de functie naam, is er een andere mogelijkheid bijvoorbeeld token, dan kun je (kwestie van smaak) keuzes maken:

code:

function user_validate($type, $value){
    switch($type){
        case 'credential':
            return user_validate_credential($value);
        break;
        case 'token':
            return user_validate_token($value);
        break;
    }
}

function user_validate_credential($credential){
  //code
}

function user_validate_token($token){
  //code
}

[DJMaze]

Carharttguy schreef op woensdag 8 mei 2019 @ 11:51:
Een ietwat filosofische programmeervraag.

Hoezo filosofisch?
Kijk eens naar de engelse zinsopbouw:

1a are you logged in?
1b you are logged in.
2a is the user logged in?
2b the user is logged in.


User::areYouLoggedIn()
User::isLoggedIn()


In het nederlands:
1. ben jij ...?
2. is de gebruiker ...?


Ik denk dat je er dan wel achter komt hoe taal werkt

[ Voor 6% gewijzigd door DJMaze op 08-05-2019 15:19 ]

[li3283]

Binnen de context van username + password zou dit sneller binnen een "validation" passen dus bijv. validate_user. Je zou bijv: https://symfony.com/doc/current/validation.html kunnen gebruiken om dit te doen.

[Carharttguy]

KoningsGap schreef op woensdag 8 mei 2019 @ 12:14:
[...]


Dit wordt genoemd in (een van) de java conventies, hier te vinden.

Als ik verder zoek kom ik eigenlijk nergens gebruik van 'are' tegen, en zou dit zelf dan ook niet zo heel snel doen. Ik zou in dit geval denk ik voor iets gaan als isEmailPasswordValid() of isEmailPasswordCombinationValid() oid.

Dit vind ik echt een goede benadering, het 'klopt' inderdaad wel met de conventions dan.

ThomasG schreef op woensdag 8 mei 2019 @ 12:32:

In het geval van IsUsernameCorrect en IsPasswordCorrect: wat wil je hiermee gaan doen? en In welke klasse ga je dit plaatsen? Aangezien het rare namen zijn hint het er al op dat er iets niet klopt. Als je er dieper over nadenkt heb je ze ook eigenlijk helemaal niet nodig. Een correcte manier zou in dit geval dus zijn om bijvoorbeeld authenticate(username, password); oid. aan te roepen, en als het niet gelukt is throwt het een exception (bijv BadCredentialsException).

Persoonlijk zou ik dat nooit doen, een Exception is in mijn ogen echt wel een uitzondering, een fout. Ik zou dat niet onmiddellijk gebruiken om gewone code flow te structureren. Als bijkomstigheid kan ik het in mijn geval ook niet, omdat er niet zoiets bestaat als inheritance (ik kan dus geen echte custom exceptions maken)

Gomez12 schreef op woensdag 8 mei 2019 @ 13:20:
[...]

voor wat de TS wenst zou je wmb kunnen zeggen : Authenticate(username, password) alleen verwacht ik dan geen true false terug te krijgen maar meer een session-token oid.
En op dat session token object kan je dan weer een method zetten .IsValid() wat true/false terug geeft en die checked dan of het session token nog wel geldig is.

Dat zou ik inderdaad ook kunnen doen, want ik moet toch sowieso een token hebben (het is een soort van API dat ik aan het proberen maken ben). Ga ik eens bekijken.

Verwijderd schreef op woensdag 8 mei 2019 @ 13:30:
Sowieso: "are" niet gebruiken.

Understood, was mijn gevoel ook al. Juist om dezelfde reden die je aangeeft, je (of men) verwacht het niet.

@Verwijderd Jouw methode kan in principe ook, maar wordt het normaal niet aangeraden juist wél te kunnen zien aan de methodname wat je juist verwacht?

DJMaze schreef op woensdag 8 mei 2019 @ 15:16:
[...]

Hoezo filosofisch?
Kijk eens naar de engelse zinsopbouw:

1a are you logged in?
1b you are logged in.
2a is the user logged in?
2b the user is logged in.


User::areYouLoggedIn()
User::isLoggedIn()

Filosofisch in de zin van: Er is geen juist of fout antwoord. Het enige juiste antwoord op mijn vraag is wat ik uiteindelijk het beste vind, mijn vraagstelling was daarom ook eerder een soort van gedachtenwisseling (en dat lukt ook, erg veel zinvolle respons)

Hetgeen je erna zegt over User::IsLoggedIn() heeft minder met mijn vraag te maken denk ik. Ik wil niet weten van het UserObject of die loggedIn is, ik wil vragen aan het database object of de credentials correct zijn

[Lethalis]

Credentials controleren doe je meestal wanneer een user zich aanmeldt en meestal wil je daarna ook meteen informatie over de user hebben.

Dus vaak heb ik simpelweg een UserService.GetUserByCredentials(Credentials credentials) die een User class teruggeeft.

Of iets dat daar op lijkt. Het komt zelden voor dat ik alleen een wachtwoord of gebruikersnaam controleer.

Carharttguy schreef op woensdag 8 mei 2019 @ 16:38:
[...]
Persoonlijk zou ik dat nooit doen, een Exception is in mijn ogen echt wel een uitzondering, een fout. Ik zou dat niet onmiddellijk gebruiken om gewone code flow te structureren. Als bijkomstigheid kan ik het in mijn geval ook niet, omdat er niet zoiets bestaat als inheritance (ik kan dus geen echte custom exceptions maken)

Exceptions zijn juist heel handig om control flow te structureren in een OO taal. Pas wanneer je in een functionele programmeertaal werkt met pattern matching en Either types kan het handig zijn om het anders te doen.

Heb je dat niet, dan krijg je hetzelfde als in Golang en tik je 500 if statements om alle situaties af te dekken.

[ Voor 50% gewijzigd door Lethalis op 08-05-2019 16:46 ]

[Christoxz]

Ik zat dus te denken richting AreCredentialsCorrect(), maar ergens wringt dat toch ook.

Trouwens een username + password = 1 credential, niet credentials. Dus blijft het enkelvoud.

[Gomez12]

Lethalis schreef op woensdag 8 mei 2019 @ 16:38:
Exceptions zijn juist heel handig om control flow te structureren in een OO taal. Pas wanneer je in een functionele programmeertaal werkt met pattern matching en Either types kan het handig zijn om het anders te doen.

Heb je dat niet, dan krijg je hetzelfde als in Golang en tik je 500 if statements om alle situaties af te dekken.

Ik hoop niet dat jij ooit een serieus programma gaat schrijven. Exceptions... De naam zegt het al...

Je kan elke performancewens overboord gooien als je die gaat gebruiken voor control flow.

Exceptions zijn gewoon in elke zinnige taal extreem duur om te gooien en dat is normaal gesproken ook helemaal niet erg, aangezien de punten waarop ze geworpen worden ook de exceptions zijn en niet de standaard flow.

Ik zou zeggen pak er nog eens een boekje OO voor beginners bij, want daar hoort dit gewoon al uitgelegd te worden...

[.oisyn]

Gomez12 schreef op woensdag 8 mei 2019 @ 16:57:
[...]

Ik hoop niet dat jij ooit een serieus programma gaat schrijven. Exceptions... De naam zegt het al...

Je kan elke performancewens overboord gooien als je die gaat gebruiken voor control flow.

Dat zei hij niet. Hij zij dat exceptions handig zijn om control flow te structureren. En idd, een parse error rapporteren middels een exception in een recursive descent parser (ik noem maar wat) is een stuk gestructureerder dan de code volpeperen met if-statements (= control flow).

[ Voor 3% gewijzigd door .oisyn op 08-05-2019 17:19 ]

[Gomez12]

.oisyn schreef op woensdag 8 mei 2019 @ 17:19:
[...]

Dat zei hij niet. Hij zij dat exceptions handig zijn om control flow te structureren. En idd, een parse error rapporteren middels een exception in een recursive descent parser (ik noem maar wat) is een stuk gestructureerder dan de code volpeperen met if-statements (= control flow).

Het voorbeeld wat genoemd werd was een BadCredentialsException na bijv een aanroep van authenticate(username, password);

Dat is imho gewoon een mogelijke verwachte uitkomst en niet een exceptie.

Bij een recursive descent parser verwacht ik dat hij er wel uitkomt en is de parse error dus de exception.

[.oisyn]

Meh, ik zie niet zo'n verschil tussen foute invoer bij een parser en foute invoer bij login credentials

[incaz]

@Gomez12, Python raadt het gebruik van exceptions voor flow aan als het de zaken leesbaarder maakt. Dat dit in bepaalde talen veel overhead geeft zou je ook kunnen zien als een implementatienadeel van de talen waarin dat zo is.

Verder denk ik dat het juist bij het inloggen wel prima is om exceptions te gooien: dat gebeurt namelijk niet in een loop die makkelijk explodeert, dus wat de overhead ook is, is nauwelijks relevant, en bovendien wil je dat het ook echt fout gaat als je vergeet te definieren wat je bij niet-inlog wilt doen. Als dit een functie is die je vaker gebruikt, dan wil je dat die vooral niet in stilte een leeg object teruggeeft, maar juist dat het in de errorlogs komt, en in grote letters op je scherm bij het testen, etc.

En het maakt de code ook veel leesbaarder, omdat je altijd expliciet maakt wat je doet met falende inlogs, en met een beetje IDE krijg je ook nog gratis de check erbij in je editor dat je een functie aanroept maar de exception niet afhandelt.

Dus waar de afweging in een dure taal als Java zeker kan zijn om exceptions niet te snel te gebruiken, is dit alsnog een case waar ze heel goed passen. Hoe verwacht het ook is dat het mis gaat: dat stop je dan in de catch.

[ThomasG]

Gomez12 schreef op woensdag 8 mei 2019 @ 16:57:
[...]

Ik hoop niet dat jij ooit een serieus programma gaat schrijven. Exceptions... De naam zegt het al...

Je kan elke performancewens overboord gooien als je die gaat gebruiken voor control flow.

Exceptions zijn gewoon in elke zinnige taal extreem duur om te gooien en dat is normaal gesproken ook helemaal niet erg, aangezien de punten waarop ze geworpen worden ook de exceptions zijn en niet de standaard flow.

Ik zou zeggen pak er nog eens een boekje OO voor beginners bij, want daar hoort dit gewoon al uitgelegd te worden...

Het hele "dont use exceptions, they are slow" gebeuren is toch zo'n hardnekkig fabeltje wat eindeloos herhaald blijft worden,; en in de meeste real-world gevallen ook niet met feiten onderbouwd kan worden. Wanneer exceptions een grote overhead geven, zijn de performance problemen door de exceptions een gevolg van een groter probleem, en niet de oorzaak (als in: grote ontwerpfout); een aantal uitzonderingen daargelaten natuurlijk. Een programmeur die roept: "Ik gebruik geen exceptions want ze zijn langzaam" is, zeker anno 2019, helaas niet serieus te nemen. In veruit de meeste gevallen zijn de nadelen van de potentiele overhead verwaarloosbaar, vooral met de vele voordelen die het biedt.

Stel je hebt een methode: User getUserByUsername(String), en de user met het opgegeven username bestaat niet. Wat doet de methode dan? Returned het null, zodat je of null-pointers krijgt of dat er overal in de codebase waar het gebruikt wordt null-checks gedaan moet worden? Vervang je met met een Optional<User>, wat effecief een gedwongen sugar-coating is voor null-checks? Of throwd het een UserNotFoundException, omdat User object nodig is in de code waar het gebruikt wordt en dus zonder User object niet werkt; en dus de fout kan afhandelen. In gevallen waarbij het daadwerkelijk optioneel is, is een opional echter beter.

Je moet natuurlijk niet gaan overdrijven en overal waar het kan exceptions gebruiken. In de meeste gevallen is "performance" echter geen valide argument met merkbare en meetbare resultaten om exceptions te vermijden. Tenzij je natuurlijk "fake-world" benchmarks gaat draaien met try-catch statements in een for-loop, maar dat geeft een zeer vertekend beeld voor real-world gevallen.

[EddoH]

Als je zeker geen Exception gaat gooien, kun je nog de 'try' prefix overwegen. 'tryAuthenticate' bijvoorbeeld.

Of een methode voor authenticatie wel een boolean moet teruggeven is een andere vraag. Een token of user object zoals reeds geopperd lijkt mij logischer, maar dat ligt maar helemaal aan de rest van de context en het design van de applicatie.

[farlane]

incaz schreef op woensdag 8 mei 2019 @ 18:04:
@Gomez12, Python raadt het gebruik van exceptions voor flow aan als het de zaken leesbaarder maakt. Dat dit in bepaalde talen veel overhead geeft zou je ook kunnen zien als een implementatienadeel van de talen waarin dat zo is.

Python heeft performance ook niet echt bovenaan op de wensenlijst staan *kuch*.

[HollowGamer]

Ik zou gewoon als method iets als authenticate gebruiken. In PHP wordt ook vaak isAble gebruikt, dus je zou ook daarmee iets mee kunnen doen.

Zelf gewoon simpel houden en een exception gooien bij invalide authenticatie.

[Gomez12]

ThomasG schreef op woensdag 8 mei 2019 @ 18:44:
[...]
Het hele "dont use exceptions, they are slow" gebeuren is toch zo'n hardnekkig fabeltje wat eindeloos herhaald blijft worden,; en in de meeste real-world gevallen ook niet met feiten onderbouwd kan worden.

Ehm, tja sorry maar we leven in totaal verschillende werelden.
In mijn wereld moet er meer als 1 regel per seconde uitgevoerd worden en daarom kan je googlen op dat excepties slow zijn, je kan het ook gewoon zelf uittesten door gewoon 10.000 x een exceptie te gooien vs dat niet te doen.

Maar idd als je in een wereld leeft waarin 1 regel code uitvoer per seconde acceptabel is, dan zijn het fabeltjes etc.

Exceptions zijn alleen niet slow als je ze nooit throwed / catched / try'ed. Maar dan doen ze ook niets / heb je het over een exceptionele situatie. Bad Username or Password is geen exceptionele situatie.

ThomasG schreef op woensdag 8 mei 2019 @ 18:44:
[...]
Stel je hebt een methode: User getUserByUsername(String), en de user met het opgegeven username bestaat niet. Wat doet de methode dan? Returned het null, zodat je of null-pointers krijgt of dat er overal in de codebase waar het gebruikt wordt null-checks gedaan moet worden?
...
Of throwd het een UserNotFoundException, omdat User object nodig is in de code waar het gebruikt wordt en dus zonder User object niet werkt; en dus de fout kan afhandelen. In gevallen waarbij het daadwerkelijk optioneel is, is een opional echter beter.

Wat jij hier eigenlijk zegt is dat je je null-checks vervangt door een veel duurdere catch.
Je verandert niets aan de manier waarop je de fout afhandelt, je verandert niets aan de eisen van de uitkomst.

Er valt best wel iets te zeggen voor Excepties voor control flow, omdat je het er explicieter mee kan maken. En zolang het de uitzondering blijft is het performance verlies niet erg.
Echter jij komt alleen maar de meest slechte voorbeelden, gewoon standaard responses vervangen door excepties, null-checks vervangen door excepties. Allemaal zaken waarbij je het niet moet gebruiken omdat het enkel maar meer kost en niets bijdraagt.

Als een object verplicht is, dan moet je idd een null-check doen want dat is simpelweg goedkoper dan een exceptie.
Is echter een object op plaats x nodig met eigenschap y en op plaats a nodig met eigenschap b dan kan je excepties gaan gooien om aan te geven dat je eigenschap y mist en daardoor geen geldig object kan retourneren.

Je moet natuurlijk niet gaan overdrijven en overal waar het kan exceptions gebruiken.

Mwah, als je het als vervanger van null-checks gaat zien dan zit je wmb al lang en breed in die category hoor...

In de meeste gevallen is "performance" echter geen valide argument met merkbare en meetbare resultaten om exceptions te vermijden. Tenzij je natuurlijk "fake-world" benchmarks gaat draaien met try-catch statements in een for-loop, maar dat geeft een zeer vertekend beeld voor real-world gevallen.

Tja, ik moet even een bulk-actie doen over 20 miljoen data-rows, of ik moet een export genereren met 20 miljoen objecten erin.
Nu zou ik natuurlijk null-checks kunnen gebruiken, maar daarnet vond jij het nog beter om exceptions te genereren, et voila nu hebben we opeens een fake-world benchmark gecreeerd.

Stel t.net of een facebook of weet ik veel wie die wil een actie over alle users doen, die creeert dus een loopje met daarin getUserByUsername(String) en heeft vanwege reden x/y/z een grote kans dat die strings foutief zijn, oh shit, zitten we weer in de fake-world natuurlijk...

[NMe]

Gomez12 schreef op woensdag 8 mei 2019 @ 20:18:
[...]

Ehm, tja sorry maar we leven in totaal verschillende werelden.
In mijn wereld moet er meer als 1 regel per seconde uitgevoerd worden en daarom kan je googlen op dat excepties slow zijn, je kan het ook gewoon zelf uittesten door gewoon 10.000 x een exceptie te gooien vs dat niet te doen.

Maar idd als je in een wereld leeft waarin 1 regel code uitvoer per seconde acceptabel is, dan zijn het fabeltjes etc.

Je maakt je argument niet sterker door te roepen dat het met exceptions ineens de boel vertraagt tot een regel per seconde. Daarnaast kun je volgens ditzelfde argument ook beter geen function calls gebruiken...

[incaz]

Gomez12 schreef op woensdag 8 mei 2019 @ 20:18:
[...]

Ehm, tja sorry maar we leven in totaal verschillende werelden.

Dat blijkt duidelijk, alleen je doet het voorkomen alsof jouw wereld de juiste is? Een beetje minder stellig kan best. Vooral omdat je nogal gecharcheerde voorbeelden neemt. Ik bedoel, ik neem aan dat je weet dat een try-catch geen seconde duurt, en dat het alleen maar retorische overdrijving is, maar daar doe je de discussie geen goed mee.

In mijn wereld moet er meer als 1 regel per seconde uitgevoerd worden en daarom kan je googlen op dat excepties slow zijn, je kan het ook gewoon zelf uittesten door gewoon 10.000 x een exceptie te gooien vs dat niet te doen.

Je bent vast ook bekend met "premature optimisation is the root of all evil"? Ook lekker stellig, zeker, maar er zit wel een punt onder. Een van die punten is dat het niet zinvol is om iets te gaan programmeren alsof het 10.000 keer in loop wordt uitgevoerd als het realistisch gezien maar een zeer beperkt aantal keren is. Dat geldt zeker voor credential-check, en al helemaal niet als die faalt.

Exceptions zijn alleen niet slow als je ze nooit throwed / catched / try'ed. Maar dan doen ze ook niets / heb je het over een exceptionele situatie. Bad Username or Password is geen exceptionele situatie.

Maar er is dus niet 1 standaard wat een exceptionele situatie is. Geen absolute maatstaf, geen onuitwisbare regel... en je zou eigenlijk best kunnen stellen dat een gefaalde inlog net zo goed een exceptionele situatie is als bv een netwerkfout als je aan de gang gaat met netwerken, of het verliezen van een filehandle als je naar bestanden gaat schrijven: je weet vooraf dat het gaat gebeuren, hoe dan ook, maar het is niet de bedoeling dat het voorkomt, dus als het voorkomt zit je in een situatie die exceptioneel is voor de omstandigheden en waarbij het prima is dat je een exception gooit: omdat er iets fundamenteel niet klopt.

Of daar sprake van is bij een inlog hangt een beetje af van de context van de applicatie, maar gezien het belang van veiligheid lijkt me dat het meestal wel degelijk een exceptionele situatie is, want ongewenst. En daarna handel je het dus af, zoals je dat ook met andere problemen doet (en daar waar je het niet juist doet, is het prima dat het escaleert naar de logfiles en de errormonitoring enzo.)

Wat jij hier eigenlijk zegt is dat je je null-checks vervangt door een veel duurdere catch.
Je verandert niets aan de manier waarop je de fout afhandelt, je verandert niets aan de eisen van de uitkomst.

Maar je verandert wel wat aan de verwachtingen van de coder. En dat is een belangrijk deel van code schrijven.
Dat is ook precies de context waarin de 'premature optimisation' uitspraak vandaan komt: optimalisatie is iets te vaak de reden dat leesbaarheid van de code onderschikt wordt. En waar dat nodig is, prima. Als je weet dat het een bottleneck in je code is en de performance echt achterblijft: onderzoek het en pas aan. Maar je stelligheid waarmee je het hier van tafel schuift is niet gepast: er is veel meer nuance rond dit onderwerp.

Tja, ik moet even een bulk-actie doen over 20 miljoen data-rows, of ik moet een export genereren met 20 miljoen objecten erin.

Da's gek, want dat is niet echt de context die hier gegeven werd... en bovendien is de kans groot dat als je werkelijk met 20 miljoen objecten werkt, je van je high level taal overgaat naar directere interactie (rechtstreeks de database aanspreken, rechtstreeks memorymanagement, etc, want objecten en functions hebben zelf ook overhead, dus als je echt moet gaan optimaliseren voor snelheid dan maak je al andere keuzes.)
Dat geldt zeker ook voor je voorbeeld van een actie over alle t.net users, want dat gaat vrijwel zeker via de database.

(Hoe dat precies gaat bij nosql storage weet ik niet, maar ook daar heb je bij dergelijke grootschalige operaties waarschijnlijk iets anders nodig dan 1 voor 1 al je objecten af gaan.)

[Lethalis]

Gomez12 schreef op woensdag 8 mei 2019 @ 20:18:
[...]
Ehm, tja sorry maar we leven in totaal verschillende werelden.
In mijn wereld moet er meer als 1 regel per seconde uitgevoerd worden en daarom kan je googlen op dat excepties slow zijn, je kan het ook gewoon zelf uittesten door gewoon 10.000 x een exceptie te gooien vs dat niet te doen.

In mijn wereld wil je graag dat een reactie op verkeerde credentials lang duurt

Het geven van verkeerde credentials behoort niet tot de success path waarbij performance van belang is, noch elke andere uitzonderingssituatie.

Dat exceptions "traag" zijn is dan ook geen echte issue.

[Alain]

Ik zou bij het checken van een inlogfunctie toch geen exception verwachten. Ik zie een exception toch meer als "kut, er is iets mis gegaan" en niet "een user heeft verkeerde gegevens ingevuld".

[Richh]

Er zijn meerdere wegen naar Rome. Met, en zonder exceptions. Ik zou niet snel zeggen dat één van de twee fout is in de context usercredentials. Je plus- en minpunten kan je wel afwegen aan de hand van de programmeertaal (en daarbij de cost van een exception) en hoe de rest van een eventueel bestaande applicatie er mee omgaat, ik zou altijd structuur volgen.

Anyhow, de vraag ging om naamgeving volgens mij

Puur theoretisch? Volgens mij is er niks mis met het 'is'-prefix.
Ik merk wel zelf dat ik vaak neig naar 'has' (hasValidCredentials in deze context denk ik).

[Lethalis]

Alain schreef op woensdag 8 mei 2019 @ 23:37:
Ik zou bij het checken van een inlogfunctie toch geen exception verwachten. Ik zie een exception toch meer als "kut, er gaat iets mis gegaan" en niet "een user heeft verkeerde gegevens ingevuld".

Zoals ik het zie, kunnen er meerdere dingen verkeerd gaan die een succesvolle inlog hinderen, waarvan het geven van verkeerde credentials er 1 van is. Een database die een timeout geeft, kan een andere reden zijn bijvoorbeeld. Of een service die niet bereikbaar is. Enzovoorts.

Dat kun je dan simpelweg met een try catch allemaal afvangen en een nette melding geven.

Ga je de uitzonderingssituaties - want dat zijn het - afzonderlijk afhandelen (stukken die wel met exceptions werken en andere niet), dan vergroot je alleen maar de kans dat je ergens een foutje maakt en daarmee wellicht de verkeerde mensen toegang geeft in een specifieke situatie.

Als iets niet vaak hoort te gebeuren, is een exception gebruiken geen enkel probleem.

Verkeerde credentials afhandelen hoort dan ook niet vaak te gebeuren. Als dat gebeurt, is er iets goed mis En doe je er goed aan accounts tijdelijk te blokkeren, het authenticatie mechanisme langer te laten duren (hashing functies worden niet voor niets met 10000 of zelfs meer iteraties aangeroepen), te controleren of er wel een echt persoon de credentials invult, enzovoorts.

In de wereld van beveiliging kan optimalisatie de vijand zijn

Dat maakt dat de passie waarmee bepaalde personen in dit topic reageren op dit specifieke onderwerp, eerlijk gezegd zelfs enigszins amusant is.

Ik wil bijna weten aan welke serieuze projecten ze hebben gewerkt

[Xiphalon]

Alain schreef op woensdag 8 mei 2019 @ 23:37:
Ik zou bij het checken van een inlogfunctie toch geen exception verwachten. Ik zie een exception toch meer als "kut, er is iets mis gegaan" en niet "een user heeft verkeerde gegevens ingevuld".

Een exception is meer 'er is iets mis *buiten* de concerns van de huidige functie'.

Een ValidateCredentials zou dus geen exceptie moeten geven als de user niet bestaat, want deze functie zou de informatie al geleverd moeten krijgen (username, hashed password, salt, hashmethode, etc).
Zou HasValidCredentials een functie op het object User zijn, dan is die info dus ook al beschikbaar.

Doe je bv een GetUser en is er tijdens het uitvoeren van die functie geen netwerk, dan zou die functie een exceptie moeten gooien, want die functie weet niet hoe ze dit moet oplossen.

[.oisyn]

ThomasG schreef op woensdag 8 mei 2019 @ 18:44:
[...]
Het hele "dont use exceptions, they are slow" gebeuren is toch zo'n hardnekkig fabeltje wat eindeloos herhaald blijft worden,; en in de meeste real-world gevallen ook niet met feiten onderbouwd kan worden.

Ok, even de feiten dan . Er zijn grofweg twee verschillende manieren om de exception bookkeeping te doen: het (de)registreren van een handler bij scope entry/exit, of een lookup table op basis van de instruction pointer.

De stack unwind bij het optreden van een exception is natuurlijk sneller in het eerste geval (want je hebt effectief een linked list van handlers), maar dit voegt wel runtime overhead toe, ook bij code die nooit iets met exceptions doet. Zeker in een taal als C++, die garandeert dat destructors van lokale variabelen en temporaries aangeroepen worden. Dit is de voornaamste reden dat wij performance-kritieke code compileerden zónder exception support, want helaas was deze methode de standaard in x86 Windows.

De andere manier voegt geen enkele runtime overhead toe als er geen exceptions worden gegooid, wat ook meer in lijn is met de C++ filosofie: als je een feature niet gebruikt, dan kost het ook niets. Het nadeel is dan wel dat áls er dan een exception optreedt, je tijdens de stack unwind binary searches moet doen in de handler table aan de hand van het returnadres. Het moge duidelijk zijn dat dit een stúk minder efficient is dan gewoon een if in de code, met dien verstande dat het wel louter wordt uitgevoerd als er daadwerkelijk een exception optreedt. Oftewel, het normale codepath is sneller, het uitzonderlijke codepath is langzamer. Deze methode is standaard in x64-Windows en vziw in code gecompileerd met GCC en Clang.

[ThomasG]

.oisyn schreef op vrijdag 10 mei 2019 @ 12:06:
[...]

Ok, even de feiten dan . Er zijn grofweg twee verschillende manieren om de exception bookkeeping te doen: het (de)registreren van een handler bij scope entry/exit, of een lookup table op basis van de instruction pointer.

De stack unwind bij het optreden van een exception is natuurlijk sneller in het eerste geval (want je hebt effectief een linked list van handlers), maar dit voegt wel runtime overhead toe, ook bij code die nooit iets met exceptions doet. Zeker in een taal als C++, die garandeert dat destructors van lokale variabelen en temporaries aangeroepen worden. Dit is de voornaamste reden dat wij performance-kritieke code compileerden zónder exception support, want helaas was deze methode de standaard in x86 Windows.

De andere manier voegt geen enkele runtime overhead toe als er geen exceptions worden gegooid, wat ook meer in lijn is met de C++ filosofie: als je een feature niet gebruikt, dan kost het ook niets. Het nadeel is dan wel dat áls er dan een exception optreedt, je tijdens de stack unwind binary searches moet doen in de handler table aan de hand van het returnadres. Het moge duidelijk zijn dat dit een stúk minder efficient is dan gewoon een if in de code, met dien verstande dat het wel louter wordt uitgevoerd als er daadwerkelijk een exception optreedt. Oftewel, het normale codepath is sneller, het uitzonderlijke codepath is langzamer. Deze methode is standaard in x64-Windows en vziw in code gecompileerd met GCC en Clang.

Er zijn natuurlijk altijd situaties waarbij je wilt dat de code zo snel mogelijk is. Maar dat bereik je niet door enkel geen exceptions te gebruiken. Er wordt dan een trukedoos opengehaald om, bijvoorbeeld het renderen in een spel, zo snel mogelijk te krijgen. Ik zou in z'n geval dus ook geen exceptions gebruiken. Dat heeft dan een specifiek doel, en levert sowieso al andere code op dan wat je normaal gesproken zou doen met betrekking tot onderhoud, e.d. Maar het is een verdedigbare situatie.

Ook in situaties waarbij de kans dat het fout gaat heel erg groot is, en zul je waarschijnlijk dus tot een ander ontwerp komen. Helemaal als het repareerbare fouten zijn die logischerwijs te verwachten zijn. Weer een specifieke reden.

Echter, in de meeste gevallen - zoals bij business logic - is de overhead die exceptions opleveren het probleem helemaal niet. En als je het afweegt tegen de voordelen, zoals eenvoudigere code, beter leesbare code, beter onderhoudbare code, beter herbruikbare code, e.d. zijn de overhead van exceptions niet eens een punt van discussie. Als performance dan een probleem wordt komt dat in veruit de meeste gevallen niet omdat er exceptions gebruikt worden, maar zijn er structurele ontwerpfouten gemaakt.

Het is zoals met veel dingen een trade-off, maar in veruit de meeste use-cases die een (gemiddelde) programmeur tegen komt wegen de (potentiele) nadelen van exceptions gewoon niet op tegen de voordelen. En is er dus geen goede reden om het niet te gebruiken.

[Haan]

Programma flow laten regelen door exceptions zou ik zelf nooit doen. Nog even los van de performance wat een beetje grijs gebied is of dat een issue is:
Zoals al gezegd, heet het niet voor niets exception, dus anticiperen op een exception is haast al een contradictio in terminis. (Daarmee bedoel ik natuurlijk niet dat je geen exception handling nodig hebt, maar alleen voor de 'echte' uitzonderingen of aanroepen van externe code waar exceptions uit kunnen komen.)
Bovendien heb je dan eigenlijk een soort verkapte 'goto' gecreëerd, waarvan de meesten het er wel over eens zijn dat we dat liever niet meer willen.
Maar dit dwaalt allemaal wel een beetje af van de oorspronkelijke vraag van de TS 😉

[ Voor 14% gewijzigd door Haan op 10-05-2019 21:31 ]

[.oisyn]

Haan schreef op vrijdag 10 mei 2019 @ 21:27:
Bovendien heb je dan eigenlijk een soort verkapte 'goto' gecreëerd, waarvan de meesten het er wel over eens zijn dat we dat liever niet meer willen.

Hier ben ik het toch wel zo enorm niet mee eens. Als je dat vindt, dan vind je dat toch ook bij iets als een for-lus? Exceptions zijn gestructureerd, net als andere geaccepteerde flow control. Goto niet.

[Haan]

Een for loop spring je toch niet zomaar uit? Als ik een exception gooi, spring ik naar het eerste catch blok dat er iets mee kan, bij een goto spring ik naar een label, lijkt toch best op elkaar.

[armageddon_2k1]

Haan schreef op vrijdag 10 mei 2019 @ 21:33:
Een for loop spring je toch niet zomaar uit?

Continue? Break?

[.oisyn]

Return?

[Janoz]

Haan schreef op vrijdag 10 mei 2019 @ 21:33:
Een for loop spring je toch niet zomaar uit? Als ik een exception gooi, spring ik naar het eerste catch blok dat er iets mee kan, bij een goto spring ik naar een label, lijkt toch best op elkaar.

Ja, je springt naar het eerste catch blok, maar dat zit gewoon lineaur in je stack omhoog. Een goto beweegt niet door de stack, maar door je code. Theoretisch zou je met een goto gewoon een compleet andere functie binnen kunnen springen.

[.oisyn]

Janoz schreef op maandag 13 mei 2019 @ 13:26:
[...]


Ja, je springt naar het eerste catch blok, maar dat zit gewoon lineaur in je stack omhoog. Een goto beweegt niet door de stack, maar door je code. Theoretisch zou je met een goto gewoon een compleet andere functie binnen kunnen springen.

Dit is trouwens precies de casus die Dijkstra aanhaalde in zijn beroemde paper. Je moet zijn houding ook wel een beetje in die context zien - er waren nog geen gestructureerde talen, en doodleuk in en uit procedures springen is natuurlijk vragen om (stackgerelateerde) problemen. Moderne talen met goto support doen voldoende statische checks om ervoor te zorgen dat je bijvoorbeeld niet over een variabele-initialisatie heen kunt springen.

[RoestVrijStaal]

Ik zat dus te denken richting AreCredentialsCorrect(), maar ergens wringt dat toch ook.

Waarom wringt dat dan? Omdat het niet voldoet aan een regel die één bedrijfje (wellicht zelfs één persoontje) zonder overleg met de rest van de wereld opgeschreven heeft? En de "schapenkudde" volgt maar?

Het voeldoet mijns inziens aan de intentie van de guideline, want het is een vervoeging van "to be". En het hint erop dat op een gehele collectie een eenduidige uitspraak kan worden gedaan (waar, of onwaar).
Bij een functie- of methode-naam is het vragen naar de booleaanse toestand van een, of meerdere dingen die in een bepaalde context als gelijken behandeld dienen te worden.

[Flapmo]

Wat ik mij afvraag is waarom je ergens een username/pw combinatie wil valideren zonder het over inloggen of permissies te hebben .

Als je wilt weten of een gebruiker ergens toegang tot heeft voldoet een IsLoggedIn of HasPermissions oid wel.

Als je wil controleren of het wachtwoord en/of gebruikersnaam aan een aantal regels voldoet zou ik een IsValid verwachten, een voor ieder.

Het wachtwoord is geen eigendom van je applicatie maar van de gebruiker. Tijdens inloggen valideer je of de gebruiker het weet en is wie hij zegt dat hij is. Erna regelt je applicatie alles tegen de identiteit en rechten van de gebruiker.

Dus iets meer context, wat proberen we te maken?

[Daos]

Ik vind het persoonlijk meestal prettiger lezen zonder de is/are. Dat het een boolean returnt kan je wel opmaken uit de rest van de naam. Je krijgt dan zoiets:

code:

if (CredentialsCorrect()) {
  ...
}

is/are is een soort hungarian notation (= variabelen beginnen met type) wat algemeen wordt afgeraden omdat het niets toevoegt. (hungarian notation gebruik ik trouwens wel voor ui-elementen zoals lblResult )

[Kalentum]

In Ruby is dit gebruikelijk:

code:

thing = [1, 3, 4]
thing.empty? # false

Dus als een functie een boolean terug geeft dan geef je dat aan met een vraagteken in de naam. En doorgaans dus geen is_ prefix.

Bedenk ineens dat er een uitzondering is voor de methode die checkt of een variabele van een bepaald type is:

code:

thing = [1, 2, 3]
thing.is_a? Array # true

[ Voor 36% gewijzigd door Kalentum op 20-07-2019 09:20 ]

[NMe]

Daos schreef op vrijdag 19 juli 2019 @ 23:50:
Ik vind het persoonlijk meestal prettiger lezen zonder de is/are. Dat het een boolean returnt kan je wel opmaken uit de rest van de naam. Je krijgt dan zoiets:

code:

if (CredentialsCorrect()) {
  ...
}

is/are is een soort hungarian notation (= variabelen beginnen met type) wat algemeen wordt afgeraden omdat het niets toevoegt. (hungarian notation gebruik ik trouwens wel voor ui-elementen zoals lblResult )

Dit topic vraagt naar functienamen, niet variabelenamen. En bij functies is het meestal toch wel gangbaar om werkwoorden als prefixes te hebben.

[Daos]

NMe schreef op zaterdag 20 juli 2019 @ 13:35:
[...]

Dit topic vraagt naar functienamen, niet variabelenamen. En bij functies is het meestal toch wel gangbaar om werkwoorden als prefixes te hebben.

Mijn if-voorbeeld had een functie-call.

Maar niet alleen ik gebruik wel eens een functienaam zonder werkwoord. C#/.net heeft bijvoorbeeld in linq de functies FirstOrDefault, Where, Any, All (Any en All geven boolean terug). Bij String heb je IndexOf, Substring, ToUpper. Bij Random heb je Next.

Je moet alleen oppassen met dingen als Empty(). Geeft dat een boolean terug of iets leeg is of voert het een leegmaakactie uit?

edit:
Mijn punt was dat altijd functies beginnen met Is als het een boolean returnt net zoiets is als de hungarian notation. What's next? Functies die een string returnen altijd eindigen met String?

In dit geval voegt het woordje Is of Are niet zoveel toe voor de leesbaarheid/begrijpbaarheid. Ik zou het hier weg laten.

[ Voor 19% gewijzigd door Daos op 20-07-2019 22:47 ]

[Ben(V)]

Wel grappig hoe een simpele vraag zo kan ontsporen naar en volkomen ander onderwerp.
Om even op de oorspronkelijke vraag terug te komen.

Als je twee items probeert te checken in een enkele functie, kan het resultaat nooit een boolean zijn want zo'n check geeft namelijk vier mogelijke resultaten.

Dus de beste oplossing is gewoon twee functies (IsUsername en IsPassword).
Keep It Simple S....

Vaak wil je namelijk ook wel weten welke van de twee niet correct was, om dat aan de gebruiker te kunnen melden en zo niet dan kun je gewoon vervolgen door een simpele "and" van die twee functies te gebruiken.

[Merethil]

Ben(V) schreef op maandag 5 augustus 2019 @ 14:40:
Wel grappig hoe een simpele vraag zo kan ontsporen naar en volkomen ander onderwerp.
Om even op de oorspronkelijke vraag terug te komen.

Als je twee items probeert te checken in een enkele functie, kan het resultaat nooit een boolean zijn want zo'n check geeft namelijk vier mogelijke resultaten.

Dus de beste oplossing is gewoon twee functies (IsUsername en IsPassword).
Keep It Simple S....

Vaak wil je namelijk ook wel weten welke van de twee niet correct was, om dat aan de gebruiker te kunnen melden en zo niet dan kun je gewoon vervolgen door een simpele "and" van die twee functies te gebruiken.

Al wil je in dit specifieke geval een algemene "username or password incorrect" teruggeven omdat je het anders van buitenaf wel heel makkelijk gaat maken als je aangeeft "password incorrect, but your username was spot on!" (gechargeerd). Hierdoor kan een "aanval" op je loginscherm een stuk makkelijker gebeuren omdat ze direct al weten dat je username/emailadres geregistreerd staat en dus al juist is. Scheelt een variabele die ze moeten testen/aanpassen tijdens de aanval.

[Ben(V)]

Of je wel of niet aan wil geven wat er verkeerd ingevoerd wordt is ook weer een ander onderwerp.

Waar het om gaat dat als je syntactisch een Boolean functie naam wilt gebruiken door hem met "Is" te laten beginnen, je ook geen verwarring moet stichten en dus ook iets Booleans moet testen en geen twee dingen gelijktijdig.

[ThomasG]

Ben(V) schreef op maandag 5 augustus 2019 @ 16:22:
Of je wel of niet aan wil geven wat er verkeerd ingevoerd wordt is ook weer een ander onderwerp.

Waar het om gaat dat als je syntactisch een Boolean functie naam wilt gebruiken door hem met "Is" te laten beginnen, je ook geen verwarring moet stichten en dus ook iets Booleans moet testen en geen twee dingen gelijktijdig.

Zelfs dan zijn namen als isUsername en isPassword gewoon fout. Is-ers moeten eindigen op een adjective (bijvoeglijk naamwoord) , en niet op een noun (zelfstandig naamwoord). Getters en setters eindigen daarentegen wel op een noun.

Zo zijn getUsername en getPassword correct, als is een getter voor een wachtwoord questionable.

Een isser als isUsername is raar, wat is er met de username? Als je wilt weten of een username valid is, is dat al helemaal een rare naamgeving. Dan wordt het isUsernameValid. Maar op dat moment stuit je op een ander probleem, de methode bevind zich waarschijnlijk in de verkeerde klasse. Als je wilt weten of de username voldoet aan de gestelde eisen voor een username (dus niet of hij wel of niet bestaat), hoort het in een UsernameValidator klasse met een isValid methode, of misschien wel beter: een validate(String username) methode (al wordt het dan ook al tricky).

[Ben(V)]

Het is maar hoe je het bekijkt.

Als de username gewoon opgezocht wordt in een lijst van bestaande users dan is een functienaam zoals IsUserName volkomen correct, maar IsValidUserName uiteraard ook.
Maar misschien ben ik wel van de oude stempel en niet zo dol op die ellenlange namen die soms maar in een karakter verschillen.

Maar als je echter bij bijvoorbeeld het aanmaken van een nieuwe user moet valideren volgens bepaalde regels dan is jouw opmerking correct.

[EddoH]

Een functie als 'isUserName' zou bij ons nooit het review proces doorkomen. Het is een perfect voorbeeld van een foute naam; het beschrijft totaal niet wat het doet en zorgt alleen maar voor verwarring.

[kluyze]

Ben(V) schreef op maandag 5 augustus 2019 @ 16:46:
Het is maar hoe je het bekijkt.

Als de username gewoon opgezocht wordt in een lijst van bestaande users dan is een functienaam zoals IsUserName volkomen correct, maar IsValidUserName uiteraard ook.

IsUserNAme zou ik hier nog steeds niet gebruiken, ik zou dan een 'exists' method maken.

[Koffie32]

Carharttguy schreef op woensdag 8 mei 2019 @ 11:51:

Een ietwat filosofische programmeervraag.
Wat doen jullie als je een booleaanse functie schrijft die je grammaticaal in het meervoud zou schrijven? Begint de functienaam dan met Are ipv Is?

Toch maar eens ingelogd om mijn antwoord hierop te geven.

Als je kijkt vanuit de predicatenlogica dan zou ik denken dat er hier 2 verschillende benamingen mogelijk zijn afhankelijk van wat je functie exact controleert.

Je hebt de existentiekwantor en de universele kwantor. Beide werken op verzamelingen (dus op meervouden). De existentiekwantor, kijkt of er een element in de verzameling bestaat waarvoor geldt dat een eis waar is. De universele kwantor kijkt of een eis voor alle elementen in de verzameling geldt.

In taal kun je dit uit drukken als "er bestaat een X in de verzameling Y waar is" en "Voor alle X in de verzameling Y geldt dat Z waar is" (X is een element uit de verzameling Y en Z is de eis).

Daarop voortbouwend zijn er dus twee mogelijkheden voor functies die op een verzameling een eis controleren.

De functie controleert of er een element bestaat in de verzameling waarvoor geldt dat.....
Bij dergelijke functies zou ik het woord Exists in de naam verwerken.
Voorbeeld:

code:

nameExists(collection of names) // kijkt of een naam bestaat in een verzameling met namen.

De functie controleert of alle elementen in een verzameling voldoen aan de eis....
Bij dergelijke functies zou ik het woord All in de naam verwerken.
Voorbeeld:

code:

AllUsersAreDancing(collection of users) // kijkt of alle gebruikers dansen.

kluyze schreef op maandag 5 augustus 2019 @ 16:58:
[...]
IsUserNAme zou ik hier nog steeds niet gebruiken, ik zou dan een 'exists' method maken.

Dit sluit ook op jouw verhaal aan.

[ Voor 6% gewijzigd door Koffie32 op 07-08-2019 11:20 ]