C’de yıllardır aynı döngüyü yaşarız. Bir değişken tanımlarsın, sağ tarafa bakarsın, soldaki tipe göz dikersin — sonra bir noktada “keşke bunu derleyici kendisi anlasaydı” diye iç geçirirsin. C23 ile gelen auto tam bu boşluğa oynuyor, ama dur bir dakika: burada C++’taki auto gibi bir sihir yok. Mesele daha çok tür çıkarımı falan değil, derleyicinin yerel değişken için tipi kendi belirlemesi.
İlk okuduğumda açık konuşayım, ben de “Bu kadar mı?” dedim (yanlış duymadınız). Çünkü dışarıdan bakınca küçük, hatta neredeyse önemsiz bir ekleme gibi görünüyor. Ama 2024 başında Paul J. Lucas’ın yazısını incelerken şunu fark ettim: C’nin yıllardır taşıdığı o katı. Biraz da inatçı yapıya, minik ama işe yarar bir esneklik geliyor. Küçük görünüyor, evet. Etkisi ise sandığınızdan büyük olabilir.
Geçen ay İstanbul’da bir gömülü sistem projesinde eski C kodlarını elden geçirirken benzer sıkıntıyı bizzat yaşadım. Mesela de uzun (söylemesi ayıp) ifade zincirlerinde dönüş tipini satır satır takip etmek insanı yoruyor — bir noktada “Şu değişkeni neden her seferinde elle yazıyoruz ki?” diye sordum kendi kendime. C23’ün auto hamlesi tam da bu iç çekişe cevap veriyor gibi.
İşte tam da bu noktada devreye giriyor.
C23’teki auto Tam Olarak Ne Yapıyor?
Lafı gevelemeden söyleyeyim: C23’te auto, yerel değişkenlerde türü başlatıcı ifadeden çıkarmaya yarıyor. Siz tipi doğrudan yazmak yerine değeri veriyorsunuz; derleyici geri kalanını hallediyor. Bu, özellikle uzun ve karmaşık türlerde ciddi rahatlık sağlıyor — fonksiyon işaretçileri, iç içe geçmiş struct kombinasyonları, okunması zaten zor olan pointer zincirleri — bence çok yerinde bir karar —. Bunları her defasında elle yazmak bazen resmen makineye not düşmek gibi hissettiriyor (inanın bana)
İşin garibi, Önemli bir ayrım var. Bu özellik global değişkenlerde çalışmıyor; iş local scope içinde anlamlı. Yani masa üstüne her şeyi bırakıp odadan çıkmak yok, düzen yine belli ölçüde korunuyor. Bence iyi tarafı da bu zaten — sınırsız özgürlük verseydi C dilinin karakteri biraz bozulurdu.
Hmm, bunu nasıl anlatsamdı…
C ve C++ Aynı Şeyi Mi Yapıyor?
Bilmem anlatabiliyor muyum, Kısa cevap: hayır (ciddiyim). İlk bakışta isim aynı olduğu için kafalar karışıyor ama işin aslı farklı. C++’ta auto modern kodun ana parçalarından biri haline geldi; C’de ise daha kontrollü ve dar kapsamlı kullanılıyor. C23 sürümündeki yaklaşım temkinli — bu bana biraz eski ustaların yeni alete mesafeli bakmasını hatırlatıyor. Önce şöyle bir tartıyorlar, sonra kabul ediyorlar. Açıkçası kötü de etmiyorlar.
Neden Şimdi Geldi?
Bence iki sebep var: okunabilirlik ve bakım maliyeti. Mesela büyük kod tabanlarında tip tekrarını azaltmak sadece yazmayı kolaylaştırmıyor, yanlış tipi kopyalama riskini de düşürüyor (ciddiyim). Bir de şu var: yeni başlayan biri için “type inference” fikri artık tuhaf değil — Python’dan Rust’a kadar pek çok dilde bunun izini görüyoruz. C hep daha sertti; şimdi ufak ufak yumuşuyor diyebiliriz.
C23’teki auto devrim değil; ama günlük kod yazarken parmak ağrısını azaltan cinsten bir iyileştirme.
Kod Yazarken Ne Değişiyor?
Bunu en iyi örnekle anlatırım. Diyelim ki elinizde uzun bir dönüş tipi var ve siz bunu üç ayrı dosyada tekrar ediyorsunuz. Bir yerde tek harflik hata yapmanız yeterli; derleyici size nazikçe değil, tokat gibi dönüyor zaten. auto burada kopyala-yapıştır kaynaklı hataları biraz törpülüyor.
Peki neden?
Editör masasında geçen hafta Ankara’daki küçük bir ekipten gelen kodu incelerken buna birebir denk geldim. Ekip lideri bana “Bunu elle yazınca her merge sırasında ufak sapmalar oluyor” dedi. Haklıydı. En çok da legacy projelerde aynı tipin farklı varyasyonlarını görmek sinir bozucu olabiliyor.
| Kullanım Senaryosu | Klasik Yaklaşım | C23 auto ile |
|---|---|---|
| Karmaşık pointer tipi | Uzun tip bildirimi | Daha kısa ve okunur ifade |
| Sık tekrar eden local değişkenler | Kopyalama hatası riski yüksek | Daha az tekrar, daha az sürpriz |
| Ekip içi bakım | Tip eşleşmesini takip etmek zor | Başlangıç ifadesi merkezde kalır |
Küçük Startup İçin Ne Anlama Geliyor?
Küçük ekiplerde hız önemli olur ya hani. Burada auto bayağı iş görüyor — geliştirici sayısı az olduğunda herkes hem yazar hem okur hem de debug eder, kodun daha kısa olması doğrudan zaman kazandırıyor. Ama küçük ekiplerin tuzağı da belli: “Madem kısa oldu, hadi her yere basalım.” İşte orada fren lazım. E peki, sonuç ne oldu? Her şeyi auto yapmak iyi fikir değil; bazen açık tip bildirmek ileride kafa karışıklığını önlüyor.
Kurumsal Projede Durum Ne?
İlginç olan şu ki, Enterprise tarafta mesele başka çalışıyor. Orada onlarca kişinin dokunduğu modüllerde tutarlılık kritik oluyor; bazı takımlar açık tip tercih eder çünkü denetim kolay olsun isterler.
Açık konuşayım, kurumsalda bu özellik fena değil ama politika olmadan bırakılırsa beklediğiniz kadar parlak sonuç vermez. Bir kısmı sever, bir kısmı “neden bunu gizledik?” diye sorar. Klasik ofis hikayesi yani.
Nerede Güzel Çalışır, Nerede Tökezler?
Bi saniye — En güzel çalıştığı yerler genelde lokal değişkenlerin çok net olduğu durumlar oluyor. Mesela fonksiyon içinde dönüş değeri belli olan hesaplamalar veya yardımcı nesneler — burada tip tekrarının azalması temiz hissettiriyor.
- Karmaşık ama kısa ömürlü local değişkenler
- Türevi bariz olan atamalar
- Ekip içinde aynı kalıbın sık tekrar ettiği kod parçaları
- Dönüş tipi satırları gereksiz uzatan yapılar
Peki nerede can sıkar? Tipin davranışı ilk bakışta anlaşılmıyorsa sorun çıkarabilir — doğruyu söylemek gerekirse bunu bizzat gördüm:
// Kötü örnek değil ama bağlam zayıfsa kafa karıştırabilir
auto x = get_something_complicated();
auto y = x->next->payload;
auto z = process(y);
Böyle satırlarda isimlendirme kötüyse auto kurtarıcı olmaz. Tam tersine sis perdesi oluşturur.
Bana Göre En Sağlıklı Kullanım Biçimi Ne?
Şunu söyleyeyim, Sade söyleyeyim: auto‘yu görünür mantığın olduğu yerde kullanın, görünmeyen mantığın olduğu yerde değil. Dur bir saniye — aslında önce şunu söyleyeyim: isimlendirme burada her şeyden önemli hale geliyor (şaşırtıcı ama gerçek). Değişken adı ne yaptığını anlatıyorsa auto rahatlatır; anlatmıyorsa yalnızca saklar. Yerelde Çalışan Sesli Yapay Zekâ: Nerede Tökezliyor? yazımızda bu konuya da değinmiştik. Bu konuyla ilgili 3D Baskı Savaşı: Jet Motorları Artık Başka Bir Lig yazımıza da göz atmanızı tavsiye ederim.
2023 sonbaharında İzmir’de çalıştığım bir IoT demo projesinde bunu net gördüm. Aynı modülde iki kişi vardı: biri açık tipleri seviyor, diğeri her yere kısa yollar basıyordu. Sonuç? İkincinin yazdığı bölüm ilk ay hızlıydı ama üçüncü ayda bakım maliyeti arttı. Yani hız kazanımı var diye kaliteyi çöpe atmayın.
Tuhaf ama, En pratik kural şu olabilir bence: Daha fazla bilgi için EKW’de API Yok, Çözüm Var: Tapu Verisine Akıllı Erişim yazımıza bakabilirsiniz.
- Tip apaçık belliyse
autokullan - API sınırlarında mümkünse açık tip göster
- Karmaşık pointer/struct zincirlerinde dikkat et
- Okunurluk düşüyorsa geri adım at
Bu arada benim beklentim biraz daha yüksekti doğrusu. auto güzel özellik ama henüz ham hissediyor. C’nin disiplinine uygun şekilde sınırlandırılmış olması iyi. Keşke standart kütüphanedeki bazı karmaşıklıkları da sadeleştirecek başka hamleler gelseydi.
C Dilinin Kültüründe Küçük Ama Anlamlı Bir Kayma
Açık konuşayım, C topluluğu yeniliğe genelde temkinli yaklaşır. Bu yüzden böyle özellikler dışarıdan bakınca minik görünse de kültürel olarak önemli. “Dili bozmayalım” refleksi ile “geliştiriciyi yormayalım” isteği arasında ince çizgi vardır ya — C23 o çizgide dikkatli yürüyor gibi duruyor.
Bir de şunu unutmayalım: modern araçların çoğu zaten türevsel rahatlık sunuyor (yanlış duymadınız). IDE otomatik tamamlıyor, statik analiz uyarıyor, derleyici daha akıllı davranıyor. auto bu ekosistemde yalnız başına kahraman değil; daha çok eksik parçayı tamamlayan sessiz oyuncu. LLM Wiki: Claude Code ile Unutmayan Bir Yapay Zekâ Hafızası yazımızda da bu konuya değinmiştik. Nylas timezone info: Terminalde Saat Karmaşasını Bitiren Komut yazımızda da bu konuya değinmiştik.
Tuhaf ama, Ben buna bazen mutfaktaki ölçü kaşığı benzetmesi yapıyorum. Yemeği pişiren o değil ama malzemeyi düzgün koymazsan tadı kaçıyor (evet, doğru duydunuz). auto da öyle — görünmez kalması iyi olduğunda değer kazanıyor.
Şunu söyleyeyim, Gel gelelim güvenlik ve bakım tarafına: tek başına mucize beklemeyin. Yanlış kullanırsanız kodu kompaktlaştırırken anlaşılmaz hale getirebilirsiniz. Kompakt olmakla sıkışık olmak aynı şey değil. Küçük fark, büyük dert yaratır.
Sessiz Kazanç mı, Yoksa Gereksiz Konfor mu?
Bence ikisi de olabilir. İşte olay tam burada düğümleniyor: doğru takımda sessiz kazanç, disiplinsiz takımda gereksiz konfor olur. Kendi test ettiğim örneklerde özellikle helper fonksiyonların içinde ciddi rahatlık verdiğini gördüm. Public interface tarafında fazla serbest bırakırsanız okuyucuya yük bindiriyorsunuz. Siz ne dersiniz? Yani fayda bağlama göre değişiyor.
Kısacası C23’ün auto‘su büyük manşetlik devrim değil. Ama günlük iş akışında eli hafifleten ufak bir iyileştirme. Ben bunu seviyorum çünkü gerçek dünya zaten böyle çalışıyor: her günkü küçük sürtünmeleri azaltan araçlar çoğu zaman gösterişli yeniliklerden daha değerli oluyor.
Sıkça Sorulan Sorular
C23’teki auto ile C++’taki auto aynı mı?
Tuhaf ama, Hayır, aynı değil.
İsim benziyor ama kullanım amacı farklı yönlere gidiyor.
C23’te local değişkende tür çıkarımı için geliyor; C++ tarafında ise çok daha geniş ve yerleşik biçimde kullanılıyor.
C23 auto her yerde kullanılmalı mı?
Hayır.
Tipin açık olması gerekiyorsa açık yazmak çoğu zaman daha iyi olur.
Kısacası, en çok da de ekip içinde okunurluk öncelikliyse seçici davranmak gerekiyor.
C23 auto hangi durumlarda en faydalı?
Bakın, Karmaşık türlerde ve lokal geçici değişkenlerde bayağı işe yarar. Uzun pointer ifadelerini kısaltıp kodu sadeleştirebilir. Ama isimlendirme kötüyse tek başına çözüm olmaz.
Ekip standardı yoksa auto kullanmak riskli mi?
Evet, risk olabilir.
Standardınız net değilse bazı geliştiriciler kolay okur, bazıları ise kafa karışıklığı yaşayabilir.
O yüzden kullanım kuralını önceden belirlemek iyi fikir.
Kaynaklar ve İleri Okuma
WG14 — ISO C Standardization Working Group
GitHub Ana Sayfası — Benzer örnek projeleri incelemek için başlangıç noktası
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
