Natuurlijk! Hier is een voorstel voor een stijl- en conventiehandleiding voor je JavaScript frontend team, gericht op het bevorderen van clean code en het oplossen van de problematiek rondom inconsistente functienamen: --- # Stijl- en Conventiehandleiding voor JavaScript Frontend Team ## Inleiding Deze handleiding is bedoeld om consistentie, leesbaarheid en onderhoudbaarheid in onze JavaScript codebase te bevorderen. Door het toepassen van de hier beschreven principes en best practices zorgen we dat onze code duidelijk, voorspelbaar en makkelijk te begrijpen is voor alle teamleden. --- ## 1. Algemene Code Richtlijnen - **Gebruik duidelijke en beschrijvende namen** voor functies, variabelen en componenten. - **Schrijf korte, bondige functies** die één duidelijk doel hebben. - **Houd je aan het principe van "one level of abstraction"** binnen functies. - **Gebruik consistente indentatie en spaties** (bijvoorbeeld 2 of 4 spaties voor indentatie, afhankelijk van projectstandaard). --- ## 2. Naamgevingsconventies ### 2.1 Functienamen - **Werkwoorden en actiegericht** (bijvoorbeeld: `fetchData`, `handleClick`, `updateUser`). - **Gebruik camelCase** voor functienamen. - **Gebruik werkwoorden in de infinitief** om de actie te beschrijven. - **Voor event handlers** gebruik prefix `on` (bijvoorbeeld: `onFormSubmit`). ### 2.2 Voorbeelden: ```javascript // Correct function fetchUserData() { ... } const handleButtonClick = () => { ... } // Niet consistent function getuserdata() { ... } function clickHandler() { ... } ``` ### 2.3 Functies voor data manipulatie - Gebruik werkwoorden die duidelijk aangeven dat er een data-actie plaatsvindt (`calculate`, `generate`, `transform`). --- ## 3. Consistentie in Functienamen - **Gebruik altijd werkwoorden voor functies die acties uitvoeren.** - **Gebruik zelfstandige naamwoorden voor functies die teruggeven of ophalen (bijvoorbeeld: `getUser`, `fetchOrders`).** - **Gebruik `set` voor functies die data instellen (`setUserName`).** ### 3.1 Veelvoorkomende patronen: ```javascript // Ophalen data fetchUser() getUserDetails() // Verwerken of manipuleren calculateTotal() transformData() // Muteren of instellen setUserName() updateUI() ``` --- ## 4. Best Practices voor Functies - **Beperk functies tot maximaal 20-30 regels.** - **Gebruik duidelijke parameter- en returnwaarden.** - **Gebruik destructuring waar mogelijk** voor leesbaarheid. - **Gebruik async/await voor asynchrone operaties.** --- ## 5. Voorbeelden van goede en slechte functienamen ### Goede namen: ```javascript // Correct const fetchUserData = async () => { ... } const handleFormSubmit = (event) => { ... } const updateUserProfile = (user) => { ... } ``` ### Slechte namen: ```javascript // Incorrect const doIt = () => { ... } function handle() { ... } const process = (data) => { ... } ``` --- ## 6. Documentatie en Commentaar - **Gebruik commentaar spaarzaam en only waar nodig.** - **Gebruik JSDoc stijl** voor functies, inclusief parameters en returnwaarden. Voorbeeld: ```javascript /** * Fetches user data from API. * @param {string} userId - De ID van de gebruiker. * @returns {Promise<Object>} Gebruikersgegevens. */ async function fetchUserData(userId) { ... } ``` --- ## 7. Naming van Componenten - Gebruik PascalCase voor React componenten: `UserProfile`, `LoginForm`. - Functies binnen componenten blijven camelCase. --- ## 8. Specifieke aandacht voor functienamen Omdat het team worstelt met inconsistente functienamen, raden we aan: - **Gebruik altijd werkwoorden die de actie beschrijven.** - **Vermijd afkortingen tenzij algemeen bekend.** - **Hanteer een vaste structuur: werkwoord + zelfstandig naamwoord** (bijvoorbeeld: `loadData`, `saveSettings`). - **Maak onderscheid tussen functies die data ophalen/verwerken en die het doen zonder return.** --- ## 9. Conclusie Door deze richtlijnen consistent toe te passen, zorgen we voor een uniforme codebase die eenvoudig te lezen, te begrijpen en te onderhouden is. Bespreek openstaande vragen of onduidelijkheden tijdens teammeetings en pas de handleiding aan waar nodig. --- Als je verdere hulp nodig hebt bij het opstellen van documentatie, voorbeeldcode of specifieke regels, laat het me weten!

Hier is een gestructureerde handleiding voor uw JavaScript frontend-team, specifiek gericht op consistente naamgevingsconventies en clean code principes. --- ### **Clean Code Stijlhandleiding voor JavaScript Frontend** #### **1. Naamgevingsconventies (Prioriteit #1)** **Probleem:** Inconsistente functienamen **Oplossing:** Strikte conventies voor verschillende functietypes **Regels:** - **Verbs voor acties:** Functies die acties uitvoeren beginnen met een werkwoord - `getUserData()`, `calculateTotal()`, `validateForm()` - **Adjectives voor returns:** Functies die booleans retourneren gebruiken is/has/should - `isValid()`, `hasPermission()`, `shouldRender()` - **Nouns voor getters:** Functies die waarden retourneren gebruiken zelfstandige naamwoorden - `userProfile()`, `priceFormatter()` **Verboden patronen:** - ❌ `handle()` (te vaag) - ❌ `process()` (onduidelijk) - ❌ `doSomething()` (niet specifiek) **Voorbeelden:** ```javascript // Goed function fetchUserOrders() { ... } function isFormValid() { ... } function formatCurrency() { ... } // Slecht function user() { ... } // te vaag function check() { ... } // onduidelijk function stuff() { ... } // onacceptabel ``` #### **2. Functie-ontwerpprincipes** **Single Responsibility Principle:** - Elke functie doet één ding - Maximaal 20 regels code per functie - Duidelijke scheiding tussen business logic en UI manipulation **Voorbeeld:** ```javascript // Goed function validateRegistrationForm(data) { return { isValid: validateEmail(data.email) && validatePassword(data.password), errors: collectValidationErrors(data) }; } // Slecht function handleForm() { // doet te veel validateEmail(); updateUI(); sendData(); showNotifications(); } ``` #### **3. Variabelenamen** - **Descriptief:** Geen afkortingen (behalve algemeen geaccepteerde zoals `i` in loops) - **Contextueel:** Variabelenamen reflecteren hun inhoud - **Consistent:** Kies één patroon en houd dit vast **Voorbeelden:** ```javascript // Goed const userAuthenticationToken = ...; const isLoading = ...; const formattedPrice = ...; // Slecht const token = ...; // te vaag const loading = ...; // niet consistent const price2 = ...; // betekenisloos ``` #### **4. Commentaarstrategie** - **Waarom, niet wat:** Leg de intentie uit, niet de implementatie - **JSDoc voor complexe functies:** Parameters, return values en exceptions - **TODO comments:** Gebruik `// TODO: [beschrijving]` voor tijdelijke workarounds **Voorbeeld:** ```javascript /** * Valideert gebruikerswachtwoord volgens beveiligingsbeleid * @param {string} password - Te valideren wachtwoord * @returns {boolean} - Voldoet aan complexiteitsvereisten */ function validatePasswordComplexity(password) { // TODO: Implementeren multifactor requirements Q2-2024 return password.length >= 8 && /[A-Z]/.test(password); } ``` #### **5. Consistentie-checklist** - [ ] Functienamen volgen verb-noun patroon - [ ] Boolean functies beginnen met is/has/should - [ ] Geen functies langer dan 20 regels - [ ] Variabelenamen zijn volledig uitgeschreven - [ ] Commentaar verklaart complexe business logic - [ ] Geen dead code of console.log statements in productie #### **6. Implementatiestrategie** 1. **Code reviews:** Elke PR controleert naamgevingsconventies 2. **ESLint config:** Automatische checks voor naamgevingspatronen 3. **Gedeelde woordenschat:** Team-breed woordenboek voor veelgebruikte termen 4. **Refactoring cycles:** Wekelijkse tijd gereserveerd voor code-opschoning #### **7. Teamafspraken** - **Weekly naming review:** Korte bespreking van inconsistente patronen - **Shared vocabulary document:** Lijst met goedgekeurde termen - **Pair programming:** Voor complexe functies om consistentie te garanderen --- **Starthulp:** Begin met een "naming intervention" waarbij het team samen 10 kritieke functies refactort volgens deze regels. Gebruik deze sessie om teamconsensus te bouwen over de conventies. Wilt u dat ik specifieke secties uitbreid of ESLint regels toevoeg voor automatische enforcement?