camelCase vs snake_case vs kebab-case: 2026 isimlendirme kuralları kılavuzu
userID mi yoksa userId mi? user_profile mi yoksa userProfile mi? URL’lerde - mi yoksa _ mi kullanılır? PR incelemelerini günde beş kez raydan çıkaran sorular bunlar. Cevap “kişisel tercih” değil — her ana akım dilin ve her web standardının yerleşik bir kuralı var ve hepsini tek sayfada gördüğünüzde gürültü sıfıra iniyor.
Bu kılavuz, kodda karşılaşacağınız altı case stilini (camelCase, PascalCase, snake_case, kebab-case, CONSTANT_CASE, dot.case / path/case / Header-Case), yedi dilli karar matrisini, gerçek GitHub verisiyle parseUrl-parseURL kısaltma tartışmasını, kebab-case URL’lerinin SEO gerekçesini ve case’ler arasında otomatik dönüşüm sırasında karşınıza çıkan altı tuzağı kapsıyor. Herhangi bir karakter dizisi için 15 case çıktısını aynı anda görmek isterseniz, Harf Dönüştürücü tümünü tarayıcınızda canlı işliyor.
Altı case’e bir bakış
Karşılaştırmaya geçmeden önce hızlı başvuru tablosu. Yazdırın, ekip wiki’sine yapıştırın veya bir sekmede açık tutun.
| Case stili | Örnek | Tipik kullanım | Köken / yaygınlaştıran |
|---|---|---|---|
| camelCase | userProfileImage | JS, TS, Java, Swift değişkenleri ve metotları | Smalltalk → Java |
| PascalCase | UserProfileImage | Sınıflar, React/Vue bileşenleri, TS tipleri | Pascal dili |
| snake_case | user_profile_image | Python, Ruby, Rust, SQL sütunları | C / erken Unix |
| kebab-case | user-profile-image | CSS sınıfları, URL slug’ları, HTML attr | Lisp / modern web |
| CONSTANT_CASE | USER_PROFILE_IMAGE | Ortam değişkenleri, üst düzey sabitler, makrolar | C makroları / Unix env |
| dot.case | user.profile.image | Java paketleri, MongoDB yolları, TOML anahtarları | Ad alanı kuralı |
| path/case | user/profile/image | URL yolları, dosya sistemi, Git ref’leri | Unix yolları |
| Header-Case | User-Profile-Image | HTTP/1.1 başlık adları (kanonik) | RFC 2616 |
Altı “gerçek” case için sekiz satır — dot.case, path/case ve Header-Case aynı temel tokenizasyonu farklı ayırıcılarla paylaşır; bu yüzden çoğu case kütüphanesi onları tek aile olarak ele alır.
Her case’i derinlemesine inceleyelim
camelCase: JS/Java varsayılanı
camelCase Smalltalk’ın fikriydi; ancak sektörün geri kalanına ihraç eden dil Java oldu. Sun’ın 1995 Java kod kuralları firstName, getUserProfile ve xmlParser yazımını varsayılan yaptı; Java’ya benzer görünmek isteyen her dil — JavaScript, ActionScript, Swift, Kotlin, Dart — aynı şekli devraldı.
Kural: ilk sözcüğü küçük harfle yazın, sonraki her sözcüğü büyük harfle başlatın, ayırıcıyı tamamen kaldırın. Alt çizgi yok, tire yok, boşluk yok. “camelCase” adı, küçük harf denizinden çıkan büyük harflerin engebeli silüetinden geliyor.
Yanlış yapılan iki uç durum: küçük harfle başlayan marka adları (iPhone, eBay, iOS) — bunlardan biri kodda göründüğünde, i harfini büyütmeye zorlamayın; markanın yazdığı gibi yazın ve biraz tuhaf görünen tanımlayıcıyı kabul edin. Bir de kısaltmalar var — aşağıda ele alındı.
PascalCase: sınıflar ve bileşenler
PascalCase, ilk harfi büyütülmüş camelCase’tir. Bazı stil kılavuzları bu yüzden ona “UpperCamelCase” der. Pascal dili onu 1970’lerde kullandı ve isim yapıştı.
Nerelerde geçer: her C ailesi OO dilinde sınıf adları (Java, C#, C++, Kotlin, Swift, TypeScript), React/Vue/Angular bileşen adları, TypeScript tip takma adları ve arayüzler (type UserProfile, interface AuthState), bazı ekosistemlerde modül/dosya adları (C#‘ta UserService.cs).
Sınıflar için ayrı bir case neden var? Tamamen görsel sinyal. new userProfile() ile new UserProfile() karşılaştırmasında ikincisi anında bir tip olarak okunur; ilkincisi yanlış yazılmış bir fonksiyon çağrısı gibi durur. Değer ve tip ad alanlarını karıştıran diller, anlam belirsizliğini gidermek için büyük harf kullanımına yaslanır.
snake_case: Python, Ruby, Rust, SQL
snake_case çoğu insanın sandığından daha eski — C ve erken Unix errno_h ve fopen_s tarzı adları kullandı çünkü PDP-11 terminallerindeki klavyeler alt çizgileri kolaylaştırıyordu, Pascal tarzı büyük harf kullanımı ise zahmetliydi. Python onu resmi PEP 8 kuralı olarak benimsedi, Ruby topluluğu organik biçimde buna yerleşti, Rust ise derleyici tarafından zorunlu kılınan varsayılan yaptı; değişkeniniz user_id yerine userId ise şikayet eden lint kuralıyla birlikte.
Kural: her şeyi küçük harfle yazın, sözcükleri alt çizgilerle birleştirin. user_profile_image, parse_html, max_retries.
Veritabanı açısı önemli ve çoğu dil eğitiminin atladığı bir kısım. Hemen hemen her SQL ORM — SQLAlchemy, Hibernate, Sequelize, TypeORM, Active Record — ana dilin kuralı ne olursa olsun varsayılan olarak snake_case sütun adları kullanır. Gerekçe taşınabilirlik: PostgreSQL tırnaksız tanımlayıcıları küçük harfe katlar, Linux üzerindeki MySQL büyük/küçük harfe duyarlıdır, macOS/Windows üzerindeki MySQL büyük/küçük harfe duyarsızdır ve SQLite sütun adlarını opak karakter dizileri olarak ele alır. snake_case, bunların tümünde tırnak kullanmadan hayatta kalan tek yazım biçimi.
kebab-case: web’in tercihi
Web, kullanıcıya görünen her şey için kebab-case’te birleşti: CSS sınıf adları (.user-profile-image), URL slug’ları (/blog/naming-conventions-guide), HTML özel öznitelikleri (data-user-id), Web Component etiket adları (<user-card>; spesifikasyon bir tire içermesini gerektirir).
İsmin kendisi eski belgelerde yaklaşık sekiz varyantta görünür — “dash-case”, “spinal-case”, “lisp-case”, “skewer-case”, “hyphen-case”. Hepsi aynı anlama gelir. “kebab-case” terimi, sözcüklerin şişe geçirilmiş et parçalarına benzemesine dair eski bir Stack Overflow şakasıyla kalıcı oldu.
Açık olmayan bir kural: HTML ve CSS sınıf adları pratikte büyük/küçük harfe duyarsızdır ama kanonik yazım küçük harftir. .User-Profile çoğu tarayıcıda çalışır; ne var ki sınıf adlarını hash’leyen sunucu tarafı araçları bozar, kod inceleyicilerin kafasını karıştırır. Küçük harfe bağlı kalın.
CONSTANT_CASE: ortam değişkenleri ve makrolar
CONSTANT_CASE (Rust çevrelerinde bazen SCREAMING_SNAKE_CASE), evrensel “bu değer çalışma zamanında değişmez” sinyalidir. MAX_RETRIES, API_KEY, DEFAULT_TIMEOUT_MS. Her dilin bunun için bir kuralı var ve her CI sistemi, konteyner çalışma zamanı ve kabuk, ortam değişkenlerini bu case’te bekler (DATABASE_URL, NODE_ENV, PATH).
Tuzak: JavaScript’in const anahtar sözcüğü “CONSTANT_CASE kullanın” demek değil. const result = await fetch(url) doğru bir camelCase. CONSTANT_CASE’i gerçek anlamsal sabitler için saklayın — C’de #define-lenecek değerler, çalışma zamanında değiştirilmesi hata sayılan türden şeyler. MAX_RETRIES = 3 uygundur; result değildir.
dot.case, path/case, Header-Case
Aynı tokenizer’ı farklı ayırıcılarla paylaşan üç kardeş.
dot.case hiyerarşik anahtarları temsil eder: Java paketleri (com.example.service), MongoDB alan yolları (user.profile.image), TOML/INI yapılandırma anahtarları ([database.primary]), Lodash metot yolları (_.get(obj, 'user.profile.image')). Bir dot.case karakter dizisini okurken “ad alanı, ad alanı, yaprak” şeklinde görmek gerekir.
path/case gerçek konumları temsil eder: URL yolları, dosya sistemi yolları, Git ref’leri (feature/add-auth). Nokta-mı-eğik-çizgi-mi seçimi anlamlıdır — eğik çizgiler “bu bir yerde gerçek bir şey”, noktalar “bu bir etiket” sinyali verir.
Header-Case, HTTP/1.1 kuralıdır: Content-Type, Access-Control-Allow-Origin, X-Forwarded-For. HTTP/1.1 başlıkları teknik olarak büyük/küçük harfe duyarsızdır (RFC 2616), dolayısıyla content-type çalışır; ne var ki her framework, her dokümantasyon ve her geliştirici Header-Case yazımını bekler. HTTP/2 ve HTTP/3 bunu değiştirdi — RFC 7540 §8.1.2, başlık sıkıştırmasını (HPACK) basitleştirmek için kablo üzerinde küçük harfli başlık adlarını zorunlu kılar. Pratikte uygulama koduna görünmez çünkü her HTTP/2 istemcisi ve sunucusu sizin için normalleştirir; ne var ki ham bir HTTP/2 çerçevesini incelerseniz, başlıklar tamamen küçük harfli kebab-case görünür.
Yedi dilli karar matrisi
Bir isimlendirme tartışmasını çözmenin en hızlı yolu, dilin standart kütüphanesinin ne yaptığına bakmaktır. Matris aşağıda.
| Dil | Değişken | Fonksiyon | Sınıf | Sabit | Dosya adı | DB sütunu |
|---|---|---|---|---|---|---|
| Python (PEP 8) | snake_case | snake_case | PascalCase | CONSTANT_CASE | snake_case.py | snake_case |
| JavaScript/TS | camelCase | camelCase | PascalCase | CONSTANT_CASE | kebab-case.js | snake_case |
| Go | camelCase* | PascalCase** | PascalCase | mixedCase*** | snake_case.go | snake_case |
| Rust | snake_case | snake_case | PascalCase | SCREAMING_SNAKE | snake_case.rs | snake_case |
| Java | camelCase | camelCase | PascalCase | CONSTANT_CASE | PascalCase.java | snake_case |
| C# | camelCase† | PascalCase | PascalCase | PascalCase | PascalCase.cs | snake_case |
| SQL | n/a | snake_case | n/a | n/a | n/a | snake_case |
*Go: küçük harfli ilk harf dışa aktarılmamış (paket-özel), büyük harfli ilk harf dışa aktarılmış (genel) demektir. Derleyici bunu zorunlu kılar.**Go: dışa aktarılan fonksiyonlar PascalCase’dir (http.NewRequest); paket-özel fonksiyonlar camelCase’dir (http.parseHeader).***Go: sabitler aynı dışa aktarılmış/dışa aktarılmamış büyük harf kuralına uyar — dışa aktarılanlar içinMaxRetries, dışa aktarılmayanlar içinmaxRetries. Go, CONSTANT_CASE’den bilinçli olarak kaçınır.†C#: yerel değişkenler ve özel alanlar camelCase’dir (bazı kod tabanları alanları_ile önekler:_userName); genel özellikler, metotlar ve tipler PascalCase’dir.
Her dili kesen üç katman:
HTML ve CSS: sınıf adları ve ID’ler kebab-case’dir (<div class="user-profile-card">). Özel HTML öznitelikleri, data- ön ekiyle kebab-case’dir (data-user-id). Satır içi CSS özellikleri kebab-case’dir (background-color); JS DOM eşdeğerleri camelCase’dir (element.style.backgroundColor).
HTTP: giden başlık adları HTTP/1.1 için Header-Case ('Content-Type': 'application/json'); HTTP/2 kablosunda küçük harfli kebab-case’dir. Çoğu fetch kütüphanesi her iki yazımı kabul eder ve içeride normalleştirir.
Ortam değişkenleri: her yerde CONSTANT_CASE — Node, Python, Go, Rust, Bash, Docker, Kubernetes. .env dosyası kuralı aynı: DATABASE_URL=postgres://....
Kısaltma işleme: Google vs Microsoft
Kod incelemelerinde en tartışmalı isimlendirme sorusu bu. parseUrl mı, parseURL mü? userId mi, userID mi? HtmlParser mı, HTMLParser mı? XmlHttpRequest mi, XMLHttpRequest mi?
İki ekol var; her ikisinin arkasında gerçek bir otorite duruyor.
Kısaltmayı-sözcük-olarak-ele-al (Google, Apple, modern JS): parseUrl, userId, HtmlParser. Google JavaScript Style Guide §5.3 açıkça bunu önerir. Apple’ın Swift API Design Guidelines aynısını yapar. lodash ve change-case paketleri varsayılan olarak bu çıktıyı üretir. Argüman gidiş-dönüş kararlılığı: parseUrl temiz biçimde parse / url olarak tokenize edilir, parse_url’e dönüştürülür ve bilgi kaybı olmadan tekrar parseUrl’e döner. parseURL ise parse / URL olarak tokenize edilir, naif bir tokenizer altında parse_u_r_l’ye ya da kısaltma-farkında bir tokenizer altında parse_url’e dönüştürülür — sonrasında parse_url, geri dönüşte parseUrl mi yoksa parseURL mü olacağına karar veremez çünkü tamamı küçük harfli yazım, kısaltma sinyalini kaybetmiştir.
Kısaltmanın büyük harflerini koru (Microsoft, .NET, eski Java): parseURL, userID, HTMLParser, XMLHttpRequest. Microsoft’un .NET Naming Guidelines bunu 2-3 harfli kısaltmalarla (IO, URL, XML) sınırlar ve daha uzun olanlar için sözcük-olarak-ele-al kuralını kullanır (Html katı okuma altında büyük-harfli-koru olurdu, ama Microsoft pratikte HtmlAgilityPack yazar). Win32 API’si, .NET BCL’si ve 2010 öncesi Java kodunun çoğu bu yolu izler. İngilizce konuşanlara daha doğal okunur — parseURL, “parse U-R-L” gibi görünür — gidiş-dönüş özelliği pahasına.
Python’un PEP 8’i nominal olarak sözcük-olarak-ele-al önerir; ancak Python standart kütüphanesi tarihsel olarak tutarsızdır: http.server.HTTPServer ve xml.etree.ElementTree kısaltmaları korurken json.JSONDecoder aynısını yapar. Yeni eklemeler (pathlib.PurePath, dataclasses) sözcük-olarak-ele-al’a meyleder. PEP 8 satırı şu: çevredeki kodun yaptığını izleyin.
2026 başında GitHub’ın genel külliyatından yapılan bir nokta kontrolü (BigQuery bigquery-public-data.github_repos örneği, 1k+ yıldıza sahip depolardan TypeScript ve JavaScript dosyalarıyla filtrelenmiş) yaklaşık 7:3 oranında parseUrl-parseURL ve 6:4 oranında userId-userID gösteriyor. Sözcük-olarak-ele-al stili JavaScript’te kazanıyor. C# büyük ölçüde Microsoft tarzında — C# dosyalarında parseURL hakim. Python gerçekten bölünmüş durumda.
Karar kuralı: (a) yazdığınız dilin standart kütüphanesini izleyin; (b) standart kütüphane tutarsızsa, gidiş-dönüş yaptığı için yeni projeler için sözcük-olarak-ele-al’ı seçin; (c) seçimi linter veya stil yapılandırmanıza yazın, tek bir proje içinde ikisini karıştırmayın. Harf Dönüştürücü tokenizer’ı, lodash ve change-case paketiyle eşleşmesi için sözcük-olarak-ele-al kuralını izler — XMLHttpRequest yapıştırın, camelCase, snake_case ve kebab-case çıktıları olarak xmlHttpRequest, xml_http_request, xml-http-request görün.
URL slug’ları: kebab-case neden snake_case’i yener
Google’ın URL yapısına dair resmi Search Central dokümantasyonunu okuduğunuzda tek bir belirli case önerisi verir: URL’lerdeki sözcükleri ayırmak için tire kullanın, alt çizgi kullanmayın. Gerekçe tokenizasyon. Google’ın arama dizini URL’leri tire üzerinde böler, alt çizgi üzerinde bölmez. https://example.com/buy-running-shoes, buy, running, shoes olarak tokenize edilir — bu sorgu sözcüklerinden herhangi biriyle eşleşebilecek üç dizinlenebilir terim. https://example.com/buy_running_shoes ise yalnızca tam karakter dizisiyle eşleşen tek bir buy_running_shoes terimi olarak tokenize edilir.
Sıralamalar üzerindeki pratik etki, yerleşik sayfalar için küçüktür (Google’ın başka sinyalleri var); ne var ki sıkı bir SERP’te yarışan yeni sayfalar için gerçektir. Eşit durumdaki bir sayfada, kebab-case URL daha yüksek sıralanır.
İkinci bir neden de var: büyük/küçük harf duyarlılığı. URL yolları Linux sunucularında büyük/küçük harfe duyarlıdır (web’in çoğunluğu Linux). /User-Profile ve /user-profile iki farklı URL, iki farklı önbellek girişi, iki farklı analitik satırıdır. Küçük harfli kebab-case, “ama benim Mac’imde çalışıyor” hatasını davet etmeyen tek yazım.
Her başlık için işe yarayan dört adımlı bir slug tarifi:
- Her şeyi küçük harfe çevirin.
- Boşluk ve noktalama dizilerini tek tireyle değiştirin.
- Baş ve sondaki tireleri kaldırın.
- İsteğe bağlı olarak, daha kısa URL’ler için durdurma sözcüklerini (
a,an,the,of,for) bırakın — bunu yalnızca CMS’iniz sayfa başlığı için orijinal başlığı tutuyorsa yapın.
İşlenmiş örnek: "10 Tips for Faster JavaScript: A Complete Guide" → 10-tips-faster-javascript-complete-guide. İki nokta ve durdurma sözcükleri (for, a) kaldırılır; sonuç 39 karakter, SERP gösterimi için 50-60 karakterlik ideal aralığın altında. URL uzunluğu ve platform karakter limitleriyle etkileşimi için Karakter ve Sözcük Limitleri Kılavuzu’na bakın.
Harf Dönüştürücü, tek bir yapıştırmayla her başlığın kebab-case çıktısını verir — bir CMS geçişi veya site haritası için toplu slug üretirken işe yarar.
Altı dönüştürme tuzağı
Case’ler arasında otomatik dönüşüm önemsiz görünür; değildir. Bozulduğu altı yer aşağıda.
1. Sayı-harf sınırları
snake_case dönüşümünden sonra file2x ne olur? Ana akım kural — lodash, change-case, PEP 8, Harf Dönüştürücü — her harf↔rakam geçişini bir token sınırı sayar; dolayısıyla file2x file / 2 / x olur ve snake_case’e file_2_x olarak çevrilir. parseUTF8 parse / utf / 8 olur ve parse_utf_8.
Bazı eski kütüphaneler (ve Stack Overflow’da rastlayacağınız bazı el yazısı re.sub parçacıkları) bu kuralı atlar; file2x → file2x ya da parseutf8 üretir. Uyuşmazlık yalnızca kodu kütüphaneler arasında geçirdiğinizde ortaya çıkar; semptom da şu: “tanımlayıcılarımın yarısı yeniden adlandırıldı, yarısı yeniden adlandırılmadı”. Bir tokenizer seçin, rakam-sınır kuralını izlediğini doğrulayın, ona bağlı kalın.
2. Ardışık büyük harfler
Kısaltma sınırı regex’i /([A-Z]+)([A-Z][a-z])/ — bir büyük harf dizisi ile yeni bir sözcüğü başlatan son bir büyük harf arasında bölünür. XMLHttpRequest, XML + HttpRequest olarak, sonra Http + Request olarak eşleşir ve XML / Http / Request token’larını verir.
Ters yönde canınızı yakar: XML / Http / Request tekrar PascalCase’lendiğinde XmlHttpRequest olur, XMLHttpRequest değil. Kısaltma title-case’lendi. Bu standart davranıştır çünkü alternatif — hangi token’ların başlangıçta kısaltma olduğunu hatırlamaya çalışmak — tokenizer’ların erişmediği bant dışı meta veri gerektirir. Kod tabanınız XMLHttpRequest tarzındaysa ve proje genelinde yeniden adlandırmayı sözcük-olarak-ele-al dönüştürücüsü üzerinden çalıştırırsanız, her kısaltmayı sessizce yeniden yazarsınız. Önce bir dalda test edin ya da kısaltmaları açıkça işaretlemenize izin veren bir tokenizer kullanın.
3. Unicode ve yerel ayar-farkında case eşleme
JavaScript’te 'I'.toLowerCase() genellikle 'i' döndürür. Aynı çağrıyı Türkçe yerel ayarı etkin biçimde çalıştırın, 'ı' (noktasız i, U+0131) döner çünkü Türkçede iki ayrı i harfi vardır ve büyük-I’nin küçüğü noktasız olanıdır. Bu tek hata sayısız uluslararasılaştırma yayınında karşımıza çıktı — kullanıcı adını karşılaştırma için büyütülmüş bir giriş formu, İrem adındaki her Türkçe-yerelleştirilmiş kullanıcıyı sessizce kilitler.
Bir o kadar tehlikeli iki mayın daha: Alman ß.toUpperCase() 'SS' döndürür — bir karakter ikiye dönüşür ve case dönüşümünün karakter dizisi uzunluğunu koruduğunu varsayan kod yanlıştır. Yunan Σ.toLowerCase() bağlama duyarlıdır: sözcük ortasında σ, sözcük sonunda ς.
Düzeltme: açık bir yerel ayarla toLocaleLowerCase() ve toLocaleUpperCase() kullanın ya da — kullanıcının yerel ayarını bilmiyorsanız — ASCII uyumlu davranışı elde etmek için 'en-US' geçin. Harf Dönüştürücü Intl-farkında metotları kullanır; bu nedenle üç girdinin de doğru işlenmesi sağlanır. Bunun regex tarafı için Regex Hızlı Başvuru \p{L} Unicode harf sınıfını kapsar.
4. Akıllı tırnak kirliliği
Microsoft Word, Google Docs veya macOS Notes’tan bir karakter dizisini case dönüştürücüsüne yapıştırdığınızda, görünmez yolcular taşıyabilirsiniz: U+2018 / U+2019 / U+201C / U+201D (kıvrımlı tırnaklar), U+2014 (em-tire), U+00A0 (kesilmez boşluk), U+200B (sıfır genişlikli boşluk). Dördü de çoğu yazı tipinde ASCII eşdeğerleriyle aynı görünür; ne var ki farklı kodlanır. U+00A0 içeren bir camelCase tanımlayıcısı bazı dillerde derlenir, bazılarında derlenmez; değişken adı için yaptığınız grep çağrısı bu oluşumu kaçırır.
Savunma: tokenize etmeden önce girdiyi normalleştirin. Tek satırlık input.normalize('NFKC').replace(/[“”‘’]/g, '"') çoğu suçluyu temizler. Ya da Metin Karşılaştırma Kılavuzu yaklaşımını kullanın — şüpheli karakter dizisini görsel ASCII ikiziyle karşılaştırın, hex görünümünde görünmezleri tespit edin.
5. URL’ler snake_case’lenmemeli
https://example.com/api/users bir snake_case dönüştürücüsüne yapıştırılınca https_example_com_api_users üretir. Teknik olarak geçerli bir snake_case tanımlayıcısı; anlamsal olarak felaket. URL’ler zaten kanonik case’lerindedir (küçük harfli kebab-case yol segmentleri ile path/case) ve URL’nin tamamını tek bir tanımlayıcı olarak ele almak yapısal bilgiyi kaybeder.
Düzeltme: URL’yi ayrıştırın, yol segmentlerini çıkarın, gerçekten gerekliyse her segmenti bağımsız olarak dönüştürün. Harf Dönüştürücü URL’leri kasıtlı olarak otomatik ayrıştırmaz çünkü kullanıcı niyetini tahmin etmek harf-harf olmaktan daha tehlikeli — URL yapıştırın, harf-harf dönüşüm alın; segment-segment davranış istiyorsanız, kendiniz yapın.
6. dot.case ile özellik erişimi karşılaştırması
user.profile.image karakter dizisi bağlama göre iki farklı şey. TOML dosyasında bir dot.case tanımlayıcısı olarak, üç segmentli bir addır. JavaScript ifadesi olarak, user’ın profile özelliğinin image özelliğidir.
Bir yapılandırma dosyasından dot.case karakter dizisini kopyalayıp bir JavaScript konsoluna yapıştırırsanız, çalışma zamanı onu bir özellik zinciri olarak değerlendirmeye çalışır; ya hata verir ya da şaşırtıcı bir şey döndürür. Tersine, JS özellik yollarını karakter dizisi olarak işleyen kod ('a.b.c'.split('.')) bazen başka yerlerden gelen dot.case tanımlayıcılarıyla başa çıkmak zorunda kalır ve bunları amaçlanandan daha derin yollar olarak ele alır. İkisinin ad alanlı kalması gerekir.
Kural: dot.case karakter dizileri verinin içinde kalır (yapılandırma dosyaları, MongoDB yolları, log anahtarları); tek tanımlayıcılı kod camelCase veya snake_case kullanır; kodda hiyerarşik bir şey gerekiyorsa, iç içe nesneler ve ana dilin nokta-özellik söz dizimini kullanın.
Diller arası geçiş tarifleri
JS camelCase’ten Python snake_case’e
En hızlı iş akışı: JS tanımlayıcısını kopyalayın, dönüştürücüye yapıştırın, snake_case çıktısını kopyalayın. Kod düzeyinde toplu dönüşüm için:
import { snakeCase } from 'change-case';
snakeCase('parseHTML'); // 'parse_html'
snakeCase('XMLHttpRequest'); // 'xml_http_request'
snakeCase('parseUTF8'); // 'parse_utf_8'
snakeCase('iPhone'); // 'i_phone'Sonuncusu tuzak — iPhone, camelCase sınırının yanıltıcı olduğu bir marka adı. Marka adları ve bir avuç tarihsel tanımlayıcı için dönüşümden sonra elle düzenleyin.
SQL snake_case’ten JS/Java API yanıtlarına
Çoğu ORM bunu sizin için otomatik yapar. Sequelize’de underscored: true, TypeORM’de SnakeNamingStrategy sınıfı, Hibernate’te ImplicitNamingStrategyComponentPathImpl vardır. Varsayılan eşleme user_profile_id ↔ userProfileId.
Neyi bozar: kısaltma içeren sütunlar. http_status_code adlı bir sütun temiz biçimde httpStatusCode’a gidip gelir; ne var ki kod tabanınız HTTPStatusCode’u tercih ediyorsa, ORM size karşı çalışır. Ya sütunu httpstatuscode_code olarak yeniden adlandırın (çirkin), ya ORM’yi kısaltmaları koruyacak şekilde yapılandırın (nadir) ya da standart kurala razı olun.
React PascalCase bileşenlerinden CSS kebab-case sınıflarına
// UserProfileCard.tsx
export function UserProfileCard({ user }) {
return <div className="user-profile-card">{user.name}</div>;
}/* UserProfileCard.module.css */
.user-profile-card { padding: 1rem; }
.user-profile-card__avatar { border-radius: 50%; }
.user-profile-card--featured { background: gold; }BEM (Block Element Modifier), React ile eşleşen en yaygın CSS-sınıf kuralıdır: blok kebab-case’te bileşen adıdır, element block__element’tir, modifier ise block--modifier’dır. Dosya düzeyinde: bileşen için UserProfileCard.tsx, kapsamlı stiller için UserProfileCard.module.css — her ikisi PascalCase ve bileşen adıyla eşleşir.
Ortam değişkenlerinden uygulama yapılandırmasına
# .env (CONSTANT_CASE)
DATABASE_URL=postgres://localhost/myapp
MAX_RETRIES=3
LOG_LEVEL=info// Node.js
const dbUrl = process.env.DATABASE_URL;
const maxRetries = parseInt(process.env.MAX_RETRIES, 10);# Python
import os
db_url = os.environ['DATABASE_URL']
max_retries = int(os.environ['MAX_RETRIES'])Ortam değişkeni adı CONSTANT_CASE olarak kalır; uygulama tarafındaki tanımlayıcı dilin değişken kuralına uyar. YAML/TOML yapılandırma anahtarları, çalışma zamanında aynı CONSTANT_CASE ortam değişkenlerine eşlenseler bile geleneksel olarak snake_case’dir (database_url, max_retries) — Spring, dotenv ve Pydantic gibi framework’ler case eşlemesini sizin için yapar.
Kütüphane ve araç karşılaştırması
| Araç | Diller | Desteklenen case’ler | Tokenizer davranışı |
|---|---|---|---|
lodash (_.camelCase, vb.) | JavaScript | 4 ana + startCase | Kısaltmayı-sözcük-olarak |
change-case npm paketi | JavaScript/TS | 8 programlama case’i | Kısaltmayı-sözcük-olarak |
inflection (Python) | Python | camelCase / snake_case | Kısaltmayı-sözcük-olarak |
convert_case crate | Rust | 12+ case | Yapılandırılabilir kısaltmalar |
Go strings + regex | Go | El yapımı | Proje tanımlı |
| VS Code (yerleşik) | Editör | Yalnız UPPER / lower / Title | Yalnız boşluk |
| VS Code “change-case” eklentisi | Editör | 8 programlama case’i | Kısaltmayı-sözcük-olarak |
| Harf Dönüştürücü | Tarayıcı | 15 case (7 metin + 8 kod) | Kısaltmayı-sözcük-olarak |
Günlük kod için change-case (JS) veya convert_case (Rust) kurun. Python için inflection paketi kanonik seçim; küçük bir el yazısı regex case’lerin %90’ını kapsar. Bir kod incelemesi veya yeniden düzenleme sırasında tek seferlik dönüşümler için Harf Dönüştürücü tek yapıştırmada 15 çıktının tamamını gösterir; böylece bir bakışta karşılaştırabilirsiniz. Token saymanız veya tanımlayıcı uzunluğunu doğrulamanız gerekiyorsa, Kelime Sayıcı bu tarafı halleder; tokenizer regex’ini doğrulamak için yukarıda bağlı hızlı başvurudaki desenlerle Regex Test Aracı’nı kullanın.
SSS
camelCase ile PascalCase arasındaki fark nedir?
camelCase küçük harfle başlar (userProfile); PascalCase büyük harfle başlar (UserProfile). Her ikisi de sonraki her sözcüğü ayırıcı olmadan büyük harfle yazar. camelCase çoğu C ailesi dilde değişkenler ve fonksiyonlar için kuraldır; PascalCase ise sınıflar, tipler ve React bileşenleri için kuraldır.
Python neden snake_case, JavaScript neden camelCase kullanır?
Python (1991) snake_case’i C ve ABC dilinden devraldı; ardından PEP 8 onu topluluk standardı olarak kodladı. JavaScript (1995) Java’nın camelCase stilini kopyaladı; Java camelCase’i Smalltalk’tan devralmıştı. İkisi de tarihsel yol bağımlılığı. Hiçbir kural teknik olarak diğerinden iyi değil — okunabilirlik çalışmaları yaklaşık eşit — ve bir ekosistem içindeki tutarlılık, seçimin kendisinden daha önemli.
camelCase’te kısaltmalar için parseUrl mı, parseURL mü kullanmalıyım?
parseUrl (kısaltmayı-sözcük-olarak-ele-al) modern varsayılan — Google, Apple, lodash ve change-case npm paketi tarafından kullanılır. parseURL (kısaltma-büyük-harflerini-koru) Microsoft .NET tarzı ve C# kodunda hakim. JavaScript, TypeScript veya Swift’te yeni bir proje için parseUrl’i seçin çünkü snake_case ve kebab-case dönüşümleri üzerinden temiz biçimde gidip gelir. Hangisini seçerseniz seçin, linter’ınıza kodlayın.
URL’ler için kebab-case snake_case’ten daha mı iyi?
Evet. Google’ın resmi Search Central rehberi URL’lerde alt çizgi değil tire kullanmak yönünde. Arama dizinleyicileri tire üzerinde tokenize eder, alt çizgi üzerinde tokenize etmez: /user-profile user + profile olarak dizinlenir, /user_profile ise tek user_profile terimi olarak dizinlenir. Sıralama etkisi sayfa başına küçük ama gerçek; küçük harfli kebab-case URL’ler Linux sunucularında büyük/küçük harf duyarlılığı hatalarından da kaçınır.
Veritabanı sütun adları hangi case’i kullanmalı?
snake_case. Her büyük ORM (SQLAlchemy, Hibernate, Sequelize, TypeORM, Active Record) varsayılan olarak onu kullanır ve her büyük SQL lehçesi onu aynı biçimde işler. PostgreSQL tırnaksız tanımlayıcıları küçük harfe katlar, MySQL Linux’ta büyük/küçük harfe duyarlıdır ve macOS/Windows’ta duyarsızdır, SQLite ise adları opak ele alır. Küçük harfli snake_case, her yerde aynı davranan tek yazım.
Bir projede isimlendirme kurallarını karıştırabilir miyim?
Evet — ve genellikle karıştırmak zorundasınız. Tipik bir web uygulaması JS değişkenleri için camelCase, veritabanı için snake_case, CSS sınıfları ve URL’ler için kebab-case ve ortam değişkenleri için CONSTANT_CASE kullanabilir. Kural “katman başına bir kural; tek bir katman içinde karıştırma” şeklinde. Katman başına seçimi linter’ınıza veya stil kılavuzunuza kodlayın; böylece PR incelemeleri bu konuyu tartışmayı bıraksın.
Case’ler arasında programatik olarak nasıl dönüşüm yaparım?
JavaScript ve TypeScript için change-case kurun veya lodash’in _.camelCase / _.snakeCase / _.kebabCase’ini kullanın. Python için inflection paketi veya kısa bir regex (PascalCase’ten snake_case’e için re.sub(r'(?<!^)(?=[A-Z])', '_', s).lower()). Rust için convert_case crate’i. Tek seferlik etkileşimli dönüşümler için Harf Dönüştürücü her girdi için 15 case çıktısını tek bir tarayıcı sayfasında gösterir.
CONSTANT_CASE yalnızca ortam değişkenleri için mi?
Hayır; ne var ki en yaygın kullanım ortam değişkenleri. CONSTANT_CASE herhangi bir “çalışma zamanı değişmezi” için kullanılır: MAX_RETRIES, API_BASE_URL, DEFAULT_PAGE_SIZE, enum değerleri, makro tanımları, üst düzey yapılandırma sabitleri. Kural şu: “bunu çalışma zamanında değiştirmek hata mı olur?” — evetse CONSTANT_CASE; hayırsa, dilin normal değişken kuralı. const result = await fetch(url) olduğu gibi iyidir.
dot.case ile path/case arasındaki fark nedir?
dot.case ayırıcı olarak . kullanır (user.profile.image) ve veri içindeki hiyerarşik bir anahtarı temsil eder: Java paketleri, MongoDB alan yolları, TOML yapılandırma anahtarları, Lodash get/set yolları. path/case / kullanır (user/profile/image) ve gerçek bir konumu temsil eder: URL yolları, dosya sistemi yolları, Git ref’leri. Nokta-mı-eğik-çizgi-mi seçimi, “veri etiketi” ile “gerçek konum” arasında sinyal verir.
30 saniyelik karar sayfası
Soruların %95’ini kapsayan üç kural:
-
Kod tanımlayıcıları için dilinizin standart kütüphanesini kopyalayın. Python: değişkenler ve fonksiyonlar için snake_case, sınıflar için PascalCase. JavaScript ve TypeScript: değişkenler ve fonksiyonlar için camelCase, sınıflar ve bileşenler için PascalCase. Go: paket-özel için küçük harfli ilk harf, dışa aktarılan için büyük harfli ilk harf. Rust: değişkenler ve fonksiyonlar için snake_case, tipler için PascalCase, sabitler için SCREAMING_SNAKE.
-
Çapraz kesen katmanlar için case, dilden bağımsız sabittir. URL’ler kebab-case’dir. CSS sınıfları kebab-case’dir. Veritabanı sütun adları snake_case’dir. Ortam değişkenleri CONSTANT_CASE’dir. HTTP/1.1 başlıkları Header-Case’dir (HTTP/2 kabloda küçük harfe normalleştirir).
-
Seçimi bir kez linter’ınıza yazın, tartışmayı bırakın. ESLint, Pylint, Clippy, golangci-lint ve Rubocop’un hepsinin bunun için kuralları var. Kuralı seçin, linter’ı yapılandırın; bir sonraki PR incelemesi
userIDileuserIdüzerine sözcük harcamasın.
Case’ler arasında dönüşüm yapmanız gerektiğinde — bir yeniden düzenleme, CMS geçişi, SQL-API eşlemesi için — Harf Dönüştürücü tek yapıştırmada 15 case çıktısının tamamını verir; böylece girdiyi elle tokenize etmeden doğru olanı kopyalayabilirsiniz. İlgili metin işleri için Kelime Sayıcı, Regex Test Aracı ve Metin Karşılaştırma Çevrimiçi’ye bakın. Daha derin okumalar için Regex Hızlı Başvuru tokenizer desenlerini kapsar, Metin Karşılaştırma Kılavuzu bir geçiş sırasında öncesi/sonrası karşılaştırmaları kapsar ve Karakter ve Sözcük Limitleri Kılavuzu SEO slug’ları için URL uzunluk bütçelerini kapsar.