Go fix kullanarak Go kodunu modernleştirmek

• Go 1.26 sürümünde baştan tamamen yeniden yazılmış go fix komutu kullanıma sunuldu; bu komut, en yeni dil ve kütüphane özelliklerinden yararlanarak kodu otomatik olarak iyileştirebilir
• Bu araç, onlarca analyzer aracılığıyla kod kalıplarını tespit eder ve minmax, rangeint, stringscut gibi çeşitli modernizer'ları uygulayarak tekrarlı veya eski kodu modern biçime dönüştürür
• Yeni new(expr) desteği için newexpr analyzer'ı eklendi; böylece newInt gibi yardımcı işlevler otomatik olarak sadeleştirilebilir
• go fix, birden fazla kez çalıştırıldığında sinerji etkisi yaratır; farklı analyzer'lar art arda iyileştirme önerebilir ve çakışma durumunda otomatik birleştirme ile gereksiz import kaldırma özelliklerini içerir
• Go ekibi, gelecekte 'Self-service' analiz paradigması ile geliştiricilerin kendi API'leri için modernizer tanımlayıp dağıtabilmesini sağlayacak şekilde bunu genişletmeyi planlıyor

---

go fix komutuna genel bakış

• Go 1.26'da go fix baştan tamamen yeniden uygulandı ve kod tabanını modern Go stiline otomatik olarak dönüştürme yeteneği sunuyor
  • go fix ./... komutu, geçerli dizinin altındaki tüm paketleri düzeltir
  • -diff seçeneğiyle değişiklikler önceden görüntülenebilir
• Kayıtlı analyzer listesi go tool fix help ile görülebilir; any, forvar, mapsloop, minmax gibi çeşitli dönüşüm kuralları içerir
• Yalnızca belirli bir analyzer'ı çalıştırmak için -any gibi bir bayrak kullanılır; hariç tutmak için -any=false belirtilir
• Platforma göre kod farklarını dikkate almak için GOOS, GOARCH birleşimlerine göre birden fazla kez çalıştırılabilir

Modernizer'lar — kod modernleştirme araçları

• Go 1.18 sonrasında generics'in kullanıma girmesi, kodu sadeleştirme olasılığını büyüttü
  • Örnek: map anahtarlarını toplamak için maps.Keys, string ayırmak için strings.Cut
• LLM tabanlı kod üretim araçlarının eski kalıpları koruma sorununu çözmek için, en güncel Go deyimlerini yansıtan açık kaynak kodun güncellenmesi gerekliliği vurgulanıyor
• go fix ve gopls içindeki modernizer'lar, kod okunabilirliğini ve öğrenme etkisini artırır
• Örnek modernizer'lar:
  • minmax: if ifadelerini min/max işlevleriyle değiştirir
  • rangeint: 3 bölümlü for döngüsünü range-over-int biçimine dönüştürür
  • stringscut: strings.Index tabanlı kodu strings.Cut ile sadeleştirir

Go 1.26'daki new(expr) özelliği

• new işlevi, değer argümanına izin verecek şekilde genişletildi; böylece new("go1.26") biçiminde ilklendirme yapılabilir
• newexpr analyzer'ı, newInt gibi yardımcı işlevleri bularak bunları return new(x) olarak sadeleştirir ve çağrı noktalarını new(expr) ile değiştirir
• Yalnızca minimum Go sürümü karşılandığında uygulanır (ör. go 1.26 yönergesi)
• $ go fix -newexpr ./... komutuyla tüm kod tabanına uygulanabilir
• Kullanımdan sonra gereksiz yardımcı işlevler deadcode aracıyla belirlenebilir

Sinerji ve çakışma yönetimi

• Bir düzeltmenin başka düzeltme fırsatları yarattığı sinerji etkisi vardır
  • Örnek: minmax uygulandıktan sonra ek dönüşüm önerileri
  • stringsbuilder → fmt.Fprintf şeklinde ardışık optimizasyon mümkündür
• go fix, düzeltme çakışmalarını 3-way merge algoritması ile otomatik olarak birleştirir
  • Sözdizimsel çakışma olduğunda ilgili düzeltme atlanır ve uyarı gösterilir
  • Anlamsal çakışmalar (ör. değişken kaldırma, kullanılmayan import) için manuel düzenleme gerekir
  • Gereksiz import'lar otomatik olarak kaldırılır

Go analiz çerçevesiyle bütünleşme

• go vet ve go fix, ortak bir analiz çerçevesini paylaşacak şekilde bütünleştirildi
  • vet hata tespitine, fix ise güvenli otomatik düzeltmelere odaklanır
• Analyzer'lar unitchecker, multichecker, gopls, staticcheck, Tricorder gibi çeşitli sürücülerde çalıştırılabilir
• fact sistemi sayesinde paketler arasında bilgi paylaşımı mümkündür
  • Örnek: log.Printf'in fmt.Printf için bir wrapper olduğunu çıkarabilmek
• gopls, gerçek zamanlı tanılama ve otomatik düzeltme önerileri sunar

Analiz altyapısındaki iyileştirmeler

• inspector paketi genişletilerek AST tarama verimliliği artırıldı; Cursor tipi ile yukarı, aşağı, sola ve sağa gezinme destekleniyor
• typeindex üzerinden işlev çağrısı indeksleme ile analiz hızı 1000 kata kadar artırıldı
• Ek iyileştirmeler:
  • standart kütüphane için bağımlılık grafiği sağlanması
  • dosya bazında Go sürümü sorgulama desteği
  • yorum satırı ekleme gibi güvenli kod değişikliklerini mümkün kılan refactoring primitive'lerinin genişletilmesi
• Bazı modernizer'lar, ince davranış değişiklikleri nedeniyle hariç tutuldu (append([]string{}, slice...) → slices.Clone(slice) örneği)
• Gelecekte pattern matching engine, otomatik test harness'i ve kesin düzeltme işleçleri kütüphanesi geliştirilmesi planlanıyor

Self-service paradigması

• Go 1.26'dan itibaren self-service analiz modelinin kullanıma gireceği duyuruldu
  • geliştiriciler kendi API'leri için modernizer tanımlayıp dağıtabilecek
  • merkezi bir onay süreci olmadan proje düzeyinde çalıştırılabilecek
• İlk adım olarak annotation-driven inliner özelliği önizleme olarak dahil edildi
• Gelecek planları:
  • dynamic loading ile kullanıcı tanımlı analyzer'ları çalıştırma (go fix veya gopls içinde)
  • kontrol akışı tabanlı denetimlerin genellenmesi; ör. “open'dan sonra close”, “lock'tan sonra unlock” gibi değişmez koşulların doğrulanması
• Amaç, bakım verimliliğini artırmak ve en yeni Go özelliklerinin hızlı benimsenmesini desteklemek

[GN⁺]

Hacker News yorumları

• 2024’ün sonlarında LLM kod asistanları hızla yaygınlaşırken, bu araçların eğitim verilerindeki mevcut Go kod stilini aynen yeniden üretme eğiliminde olması ilginçti
  En güncel sözdizimini kullanmaları söylense bile bunu görmezden geldikleri, hatta bazen böyle bir şeyin varlığını inkâr ettikleri oluyordu
  Gelecekteki modellerin en yeni Go 1.25 deyimlerini yansıtabilmesi için, tüm açık kaynak kodlarının da o stile güncellenmesi gerekiyor

  • PHP’de de geçmişte Stack Overflow’daki eski tavsiyeleri (ör. magic_quotes) temizlemeye yönelik girişimler olmuştu
    Ama LLM’e bir kez hatalı veri girdiyse, bunu sonradan düzeltmek neredeyse imkânsız
    Modelin hangi gerekçeyle sonuca vardığını izlemek zor ve sadece bir sonraki modelde düzelmesini umabiliyorsunuz
  • LLM’in ürettiği Go eşzamanlılık kodu özellikle tehlikeli
    Basit göründüğü için incelemeden geçiyor ama gerçekte hata işleme ve uç durumlar eksik oluyor
    İncelemeden sonra tekrar LLM’e verdiğinizde görünüşte düzeltilmiş kod dönüyor, ama bu kez içinde data race ya da deadlock oluşuyor
    Bu, neredeyse tüm modellerde tekrar eden bir sorun
  • Ben de bu sorunları sık sık yaşadım
    Go geriye dönük uyumluluğu iyi olduğu için derleniyor ama kod stili fazlasıyla farklılaşıyor
    Python’da ise API değişiklikleri yüzünden gerçek uyumluluk kırılmaları yaşanıyor
    Yine de Go, dil kararlılığı ve standart kütüphanesi sayesinde kod üretimi için bir dil olarak çok başarılı
  • Sonuçta LLM kullanımı tek tip ve sıradan kod üretilmesine yol açacak
  • Bence kodu LLM ile yazma fikrinin kendisini bırakmak gerek
    Rob Pike’ın uyarısında olduğu gibi, bu teknoloji yazılım ekosisteminin kirlenmesi
    Pek çok insan “kolaylık” denen slop istiyor ama sorunun özü de bu

• Kaynak kodunu otomatik olarak en güncel stile dönüştüren araçlar gerçekten harika
  Java’daki OpenRewrite bunun önde gelen örneklerinden biri ama başka dillerde benzerleri hemen akla gelmiyor
  Go’daki gibi bu özelliğin dilin içine gömülü olması, dil olgunluğunu ciddi biçimde artırıyor
  Gelecekte yeni dillerin Go’nun bu bütünleşik yaklaşımını örnek alacağını düşünüyorum

  • C dilinde Coccinelle var; 2009 tarihli LWN yazısında da anlatılmıştı
    JetBrains IDE’leri milyonlarca satır kodu tek seferde refactor edebiliyor ya da yeni sözdizimine otomatik dönüştürebiliyor
    ConvertToPrimaryConstructor gibi özellikler de var
    Ayrıca Structural Search and Replace, basit metin yerine dil sözdizimi düzeyinde çalışıyor
    .NET’in Roslyn analyzer’ları da IDE içinde kod düzeltme önerileri sunuyor
    Eğitim bağlantısı
  • Rust’ın clippy aracı güncel sözdizimini öneriyor ve bazı durumlarda otomatik düzeltme de yapabiliyor
    Bu sayede kod çok daha temiz hâle geldi
  • Haskell’in hlint aracı da uzun zamandır var
    concat ve map kullanımını concatMap ile değiştirebiliyor ya da gereksiz if ifadelerini sadeleştirebiliyor
  • TypeScript kod tabanını bu şekilde dönüştüren biri olup olmadığını merak ediyorum
    LSP sunucularının yetenekleri yetersiz ve argüman kaldırma gibi temel refactor işlemlerini bile desteklemiyorlar
    jscodeshift ya da Claude ile birleştirerek yapılabilir mi diye düşünüyorum

• Bu tür otomatik düzeltme araçları (go fix) sayesinde Go gerçekten müthiş bir dil
  Yeni özellik olan rangeint’in de go fix ile otomatik yansıtılacak olması heyecan verici
  Go ekibini tebrik ederim

  • Başka dilleri kullanmak istediğim zamanlar oluyor ama Go’nun build·test·lint araçları o kadar iyi ki sonunda yine Go’ya dönüyorum
    Derleme hızı da inanılmaz derecede yüksek
  • Eskiden for döngülerini kendim regex ile bulup düzeltirdim; artık bu araç bunu çok daha zarif bir şekilde yapıyor

• Yazıda değinilmemiş ama benim en sevdiğim özellik //go:fix inline yönergesi
  Tek satırlık bir fonksiyonu çağıranın içine inline olarak yerleştiriyor
  Böylece kütüphane yazarları eski sürüm fonksiyonlarını yeni sürüme doğal biçimde otomatik migrate edebiliyor
  semver değişse bile go fix ile otomatik yükseltme mümkün oluyor

• Yakın zamanda izlediğim Wes McKinney podcast’inde
  Go’nun hızlı derle-çalıştır döngüsü, güçlü tip sistemi ve çok iş parçacıklı güvenliği sayesinde kodlama ajanları için ideal olduğu söyleniyordu
  Bunu duyunca Go’ya yeniden ilgi duymaya başladım

• Go’nun yerleşik araç ekosistemi ve gelenekleri, ajan tabanlı geliştirmede çok yardımcı oluyor
  go run main.go ile geliştirme ortamını hemen ayağa kaldırabiliyor; birden çok worktree, merkezi yapılandırma ve migrate edilmiş veritabanı da destekleniyor
  housecat-inc/cheetah bu tür araçları paylaşıyor
  go generate, go build, go test, go vet içeren hızlı döngüye go fixi de eklemeyi düşünüyorum

  • Aşırı hızlı derleme süresi, LLM ile tekrarlı deneylerde de büyük avantaj sağlıyor

• Python öğrenirken, aynı işi yapmanın fazla çok yolu olduğunu ve bunun tutarsız olduğunu fark ettim
  C’deki gibi tek bir yolun olması bazen daha çok özleniyor
  Go’nun bu seviyeye ulaşıp ulaşmadığını merak ediyorum
  LLM yardımı olmadan da best practice izlenebilen bir dil mi, bunu bilmek istiyorum

  • Go oldukça görüş sahibi bir dil, bu yüzden çoğu şey için genelde tek bir yol var
    Karmaşıklığı artırmamak ve sadeliği korumak için gösterilen çaba etkileyici
    Python’un dağınıklığından yorulanlara tavsiye ederim

• Self-service analyzer kavramı gerçekten çok ilginç
  Büyük kütüphaneler ya da altyapı ekipleri tarafından aktif şekilde kullanılacak gibi görünüyor

• Böyle araçlar varsa, geriye dönük uyumluluğu olmayan dillerin bile mümkün olabileceğini düşündürüyor

• TypeScript dünyasında biome bu rolü üstleniyor
  Örneğin forEach yerine for...of kullanımını öneriyor ve ultracite ile birlikte kullanıldığında iş akışı çok daha akıcı oluyor
  agents.md dosyasına “düzeltmeden sonra biome fix çalıştır” diye yazdım; bu sayede kod kalitesi otomatik olarak korunuyor
  eslint’e kıyasla çok daha hafif ve verimli bir deneyim sunuyor