Naming Best Practices
Goede namen maken code self-documenting. Deze best practices helpen je descriptieve, consistente namen kiezen.
Beschrijvende namen
Namen moeten onthullen bedoeling. "getUserData()" is beter dan "get()". "maxRetryCount" is beter dan "max". "isAuthenticated" is beter dan "flag". Vermijd abbreviaties tenzij universeel begrepen. "auth" is OK voor authentication, "usr" is niet OK voor user. Wanneer in twijfel, spell it out—de paar extra karakters verbeteren leesbaarheid enorm. Gebruik pronounceable namen. "genStamp" is moeilijker te bespreken dan "generationTimestamp". Code wordt gelezen en besproken—maak namen natuurlijk om te zeggen.
Consistentie
Gebruik dezelfde woorden voor dezelfde concepten. Als één functie heet "getUser()", naam geen andere "fetchProfile()"—beide moeten "get" of "fetch" gebruiken, niet mix. Volg taal-conventies. JavaScript gebruikt camelCase, Python gebruikt snake_case. Vechten tegen conventies maakt je code zich vreemd voelen voor anderen in de community. Wees consistent met pluralization. "users" voor arrays/lijsten, "user" voor single-items. Geen mixing "userList" en "users"—kies één conventie.
Lengte-overwegingen
Scope bepaalt appropriate naam-lengte. Lokale variabelen in kleine functies kunnen kort zijn ("i", "x"). Globale variabelen en publieke API's moeten descriptief zijn ("databaseConnectionPool"). Vermijd needlessly lange namen. "getUserAuthenticationStatusBoolean()" is overkill—"isAuthenticated()" is duidelijker. Conciseness met clarity is het doel. Class/type namen kunnen langer zijn dan methode-namen. "UserAuthenticationService" is fine voor een class, maar zijn methoden zouden "authenticate(user)" moeten zijn, niet "authenticateUserInAuthenticationService(user)".
Probeer de Tool
Tekst Case Converter