← Blog · 30 april 2026 · ConvertCaseHQ-team · 7 min lezen

camelCase of PascalCase: wat is het verschil?

Het enige verschil tussen camelCase en PascalCase is de eerste letter. camelCase begint met een kleine letter en geeft elk volgend woord een hoofdletter (userName, parseResponse). PascalCase geeft elk woord een hoofdletter, ook het eerste (UserName, ResponseParser). Volgens afspraak markeert PascalCase types (klassen, interfaces, enums, React-componenten) en camelCase waarden en acties (variabelen, functies, methoden, eigenschappen).

Die ene hoofdletter zegt meer dan je denkt. Hieronder lees je wat hij aangeeft, in welke talen hij wordt afgedwongen in plaats van alleen netjes verwacht, en het onderdeel waar niemand het over eens is: afkortingen.

camelCase en PascalCase in één oogopslag

Let op de terminologie als je stijlgidsen leest. Veel mensen zeggen ‘camel case’ voor beide stijlen, en PEP 8 noemt CamelCase zelfs als andere naam voor CapWords, de eigen term voor PascalCase. Is niet duidelijk wat een gids bedoelt, kijk dan naar de voorbeelden.

Waarom de eerste letter ertoe doet: types en waarden

Dankzij de conventie kun je code lezen zonder iets op te zoeken. In const invoice = new Invoice(order) zie je in één oogopslag dat Invoice datgene is wat je construeert en invoice datgene wat je terugkrijgt. TypeScript-signaturen werken net zo: in function total(order: Order): Money is de naam met een kleine letter de waarde en zijn de namen met een hoofdletter types.

Zo kan één woord ook zowel een type als een waarde benoemen zonder conflict, en dat gebeurt voortdurend: user: User, config: Config, request: Request. In een hoofdlettergevoelige taal zijn dat verschillende identifiers, en de hoofdletter vertelt de lezer welke welke is.

Waar de taal het afdwingt

In JavaScript, Java, C# en Python is de schrijfwijze van een klassenaam alleen een conventie. Niets houdt je tegen om class invoice te schrijven. In JavaScript kun je de conventie omzetten in een controle met de regel new-cap van ESLint: standaard markeert die new invoice(), en ook het aanroepen van een functie met een hoofdletter zoals Invoice() zonder new, wat meestal een bug is. Een paar talen en frameworks gaan verder en bouwen de regel in.

Go: de eerste letter is de zichtbaarheidsregel

Go heeft geen sleutelwoorden public of private. Een naam op pakketniveau, een struct-veld of een methode wordt geëxporteerd als de eerste letter een hoofdletter is, en is privé voor zijn pakket als die een kleine letter is. Zo kies je tussen PascalCase en camelCase.

package shapes

import "math"

// Circle is exported, so other packages can use it.
type Circle struct {
	Radius float64 // exported field
	label  string  // unexported field
}

// Area is exported.
func Area(c Circle) float64 { return math.Pi * square(c.Radius) }

// square is unexported: only code inside package shapes can call it.
func square(x float64) float64 { return x * x }

c := shapes.Circle{Radius: 2}
fmt.Println(shapes.Area(c))   // fine
fmt.Println(shapes.square(2)) // compile error: square is not exported

Daarom zegt Effective Go ook dat een getter voor een niet-geëxporteerd veld owner Owner moet heten en niet GetOwner. De hoofdletter vertelt je al dat het de publieke toegang is.

React: componenten moeten met een hoofdletter beginnen

De documentatie van React is er duidelijk over: namen van componenten moeten met een hoofdletter beginnen, anders werken ze niet. JSX behandelt een tag met een kleine letter zoals <section> als een HTML-element en een tag met een hoofdletter zoals <OrderSummary /> als jouw component.

Ruby: klassenamen zijn constanten

In Ruby is elke naam die met een hoofdletter begint een constante, en klassenamen moeten constanten zijn. class Invoice werkt; class invoice is een syntaxisfout (‘class/module name must be CONSTANT’).

Welke je gebruikt, taal voor taal

• JavaScript en TypeScript: camelCase voor variabelen, functies, methoden en eigenschappen; PascalCase voor klassen, interfaces, type-aliassen, enums en componenten.
• Java en Kotlin: dezelfde verdeling, plus hoofdletters met underscores voor echte constanten (MAX_RETRIES).
• C#: PascalCase komt veel vaker voor dan in andere talen. Methoden, eigenschappen, events, publieke velden, namespaces en zelfs constanten zijn PascalCase; camelCase is voor parameters en lokale variabelen, met _camelCase voor privévelden. Een typische signatuur ziet eruit als public decimal CalculateTotal(decimal taxRate).
• Swift: PascalCase voor types en protocollen, camelCase voor al het andere.
• Go: de stijl die past bij de zichtbaarheid die je wilt.
• Python: PascalCase alleen voor klassen. Functies en variabelen zijn snake_case, en PEP 8 staat camelCase alleen toe waar het al de heersende stijl in oudere code is.
• PHP (PSR-1): klassen in PascalCase, methoden in camelCase.

Voor constanten, bestanden en de rest kun je terecht bij ons spiekbriefje voor naamgevingsstijlen voor ontwikkelaars.

Het lastige deel: afkortingen

Is het userId of userID? HttpClient of HTTPClient? De grote stijlgidsen geven verschillende antwoorden:

Ons standpunt: heeft de gids van je taal een regel, volg die dan, want dat is wat de standaardbibliotheek en je collega's verwachten. Heeft hij er geen, behandel afkortingen dan als woorden (HttpClient, userId). Woordgrenzen blijven zichtbaar als twee afkortingen naast elkaar staan (vergelijk XMLHTTPRequest met XmlHttpRequest), en de namen overleven automatische omzetting tussen stijlen. Zelfs de XMLHttpRequest van de browser zelf mengt beide benaderingen in één naam.

Voor meer achtergrond zijn de conventies voor hoofdlettergebruik van Microsoft een goed voorbeeld van een complete set regels die op één pagina is opgeschreven.

Omzetten tussen camelCase en PascalCase

Voor een eenvoudige naam is de omzetting één teken: verander de letterstand van de eerste letter.

const toPascal = (s) => s.charAt(0).toUpperCase() + s.slice(1);
const toCamel = (s) => s.charAt(0).toLowerCase() + s.slice(1);

toPascal("orderTotal"); // "OrderTotal"
toCamel("OrderTotal");  // "orderTotal"
toCamel("HTMLParser");  // "hTMLParser" (acronyms need a smarter split)

Die laatste regel is waarom tools namen eerst in woorden splitsen. Dit is wat de hoofdletter-converter van ConvertCaseHQ maakt van een paar lastige invoeren:

De converter splitst bij bestaande hoofdletters en schrijft afkortingen als woorden, wat overeenkomt met de regel van Google. Volgt je project de afkortingsregels van Go, .NET of PEP 8, corrigeer die namen dan achteraf met de hand (getUserId wordt getUserID in Go). Merknamen zijn de andere valkuil: geen enkel algoritme weet dat IPhone er verkeerd uitziet.

Twee gemakkelijke uitglijders om te vermijden

De eerste is een instantie met een hoofdletter schrijven: const Cart = new ShoppingCart() laat Cart eruitzien als een tweede klasse, en de volgende lezer gaat op zoek naar de definitie ervan. De tweede is een hulpfunctie in PascalCase in JavaScript, zoals function FormatPrice(). Tenzij het een constructor of een React-component is, nemen lezers aan dat er new of JSX bij nodig is, en new-cap gaat klagen als je de functie aanroept zonder een van beide.

Een vuistregel

Is het een type, of iets wat je met new construeert, gebruik dan PascalCase. Is het een waarde of een actie, gebruik dan camelCase. Laat de gids van je taal de afkortingen beslechten en laat een linter de rest onthouden. Voor JavaScript-specifieke zaken, zoals constanten en privévelden, kun je terecht bij onze gids voor naamgeving in JavaScript.