EditorConfig ve Biçimlendirici: Kod Stili Tartışmasını Bitirmek

EditorConfig, farklı editör kullanan geliştiricilerin aynı temel biçim kurallarına uymasını sağlayan küçük bir dosyadır. Tek başına yeterli değildir, ama üç katmanlı bir düzenin ilk basamağıdır. Bu düzen kurulmadığında kod incelemeleri girinti ve satır sonu farklarıyla dolar; asıl tartışılması gereken mantık gözden kaçar.

Katman 1: .editorconfig

Bu dosya editörün davranışını belirler: kaydettiğinizde hangi girintiyi kullanacağı, dosya sonuna satır ekleyip eklemeyeceği, hangi satır sonu karakterini yazacağı.

# .editorconfig — depo kökünde
root = true

[*]
charset = utf-8
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true
indent_style = space
indent_size = 4

[*.{js,ts,json,yml,yaml,css,scss}]
indent_size = 2

[*.md]
trim_trailing_whitespace = false   # Markdown'da iki boşluk satır sonu demektir

[Makefile]
indent_style = tab                 # make sekme İSTER, seçenek değil

Çoğu modern editör bu dosyayı yerleşik olarak okur; bazıları için küçük bir eklenti gerekir. Eklenti bolluğunun kendi maliyeti olduğunu IDE eklenti şişkinliği yazımızda tartışmıştık — bu, gerçekten değen birkaç eklentiden biridir.

Katman 2: biçimlendirici

EditorConfig girintiyi ayarlar ama kodu yeniden yazmaz. Satır uzunluğu, parantez yerleşimi, dizi biçimi gibi kararlar için biçimlendirici gerekir.

// .php-cs-fixer.dist.php
return (new PhpCsFixer\Config())
    ->setRiskyAllowed(false)     // davranışı değiştirebilecek kurallar KAPALI
    ->setRules([
        '@PSR12'                  => true,
        'array_syntax'            => ['syntax' => 'short'],
        'ordered_imports'         => ['sort_algorithm' => 'alpha'],
        'no_unused_imports'       => true,
        'trailing_comma_in_multiline' => true,
        'single_quote'            => true,
    ])
    ->setFinder(
        PhpCsFixer\Finder::create()
            ->in(__DIR__ . '/app')
            ->exclude(['Views'])   // görünüm dosyaları HTML ağırlıklı
    );

Katman 3: satır sonu ve Git

Windows ve Linux karışık bir ekipte, satır sonu farkı tüm dosyayı "değişmiş" gösterir ve kod incelemesini kullanılamaz hâle getirir. EditorConfig editörü ayarlar, ama depoya ne yazılacağını Git belirler.

# .gitattributes
* text=auto eol=lf
*.bat text eol=crlf
*.sh  text eol=lf

# İkili dosyalar dönüştürülmesin
*.png binary
*.jpg binary
*.pdf binary

Bu dosyayı sonradan eklerseniz, mevcut dosyaları bir kez normalleştirmek gerekir:

git add --renormalize .
git commit -m "chore: satır sonlarını normalleştir"

Tek seferlik büyük biçimlendirme commit'i

Kuralları mevcut bir kod tabanına uygularken tüm dosyalar değişir. Bunu özellik commit'leriyle karıştırmayın: ayrı ve tek bir commit yapın, sonra o commit'i git blame geçmişinden gizleyin.

vendor/bin/php-cs-fixer fix
git commit -am "style: tüm kod tabanına biçimlendirici uygulandı"

# Bu commit'i blame'de atla
echo "$(git rev-parse HEAD)" >> .git-blame-ignore-revs
git config blame.ignoreRevsFile .git-blame-ignore-revs

Bu adım atlanırsa git blame çıktısı tamamen o commit'i gösterir ve "bu satırı kim, neden yazdı?" sorusunun cevabı kaybolur. İyi commit ayrımı konusunu iyi bir commit mesajı yazımızda ele almıştık.

CI ile zorunlu kılın

# CI adımı: biçim bozuksa derleme düşsün
vendor/bin/php-cs-fixer fix --dry-run --diff
npx prettier --check "resources/**/*.{js,css}"

Kontrolü otomatikleştirdiğiniz anda kod incelemeleri biçimden kurtulur ve gerçekten tartışılması gereken konulara yer açılır. Editör tarafındaki verimlilik ayarları için VS Code verimlilik ayarları yazımız tamamlayıcıdır. Desteklenen özelliklerin tam listesi için editorconfig.org resmî kaynaktır.

Sonuç

Kod stili tartışması, çözülmediği sürece her kod incelemesinde yeniden doğar. Üç katman bunu kalıcı olarak bitirir: EditorConfig editör davranışını hizalar, biçimlendirici kodu tek bir doğru biçime getirir, Git yapılandırması satır sonu gürültüsünü keser ve sürekli tümleştirme kuralı zorunlu kılar. Kurulum bir öğleden sonra sürer, üç dosya ekler ve karşılığında ekibin dikkatini biçimden mantığa taşır. Bir sonraki kod incelemenizde girintiyle ilgili tek bir yorum bile görmüyorsanız, düzen çalışıyor demektir.

Pratik Uygulama Kontrol Listesi

Bu yazıdaki önerileri kendi ekibinize uyarlarken aşağıdaki adımları sırasıyla uygulamanız, teoriden pratiğe geçişi kolaylaştırır:

1. Mevcut durumu ölçün. Değişiklik yapmadan önce bugünkü performansı/süreyi/hata oranını kaydedin; aksi halde iyileşmeyi kanıtlayamazsınız.
2. Küçük bir pilot seçin. Tüm sisteme veya tüm ekibe birden uygulamak yerine tek bir modülde veya tek bir sprintte deneyin.
3. Sonuçları ekiple paylaşın. Elde ettiğiniz veriyi (olumlu ya da olumsuz) kısa bir notla ekibe aktarın; kararın gerekçesi belgelenmemişse aynı tartışma birkaç ay sonra tekrar açılır.
4. Süreci tekrarlanabilir hale getirin. İşe yarayan pratiği bir kontrol listesine veya şablona dönüştürün ki yeni katılan ekip üyeleri de aynı standardı hızlıca öğrensin.

Sık Yapılan Yanlışlar

Bu konuda ekiplerin en çok düştüğü tuzak, çözümü tek bir kişiye ya da tek bir araca yüklemektir. Oysa kalıcı iyileşme, sürecin ekibin günlük rutinine (code review kontrol listesi, sprint planlama, onboarding dokümanı gibi) gömülmesiyle mümkün olur. İkinci yaygın hata ise "en iyi pratiği" olduğu gibi kopyalamaktır — başka bir ekipte işe yarayan bir yaklaşım, farklı bir ölçekte veya farklı bir teknoloji yığınında aynı sonucu vermeyebilir; önce kendi bağlamınızda küçük ölçekte test edin, sonra genişletin. Üçüncü tuzak ise ölçmeden karar vermektir: "daha iyi hissettiriyor" öznel bir gerekçedir, ekip içi tartışmalarda nesnel veriyle desteklenmeyen kararlar er ya da geç sorgulanır ve geri alınır. Son olarak, dokümantasyonu atlamak da sık görülen bir hatadır: bir kararın "neden" alındığı yazılı değilse, ekip altı ay sonra aynı tartışmayı sıfırdan yeniden yapmak zorunda kalır ve önceki deneyimden öğrenilenler kaybolur.

Sonuç

EditorConfig ve Biçimlendirici: Kod Stili Tartışmasını Bitirmek konusunda burada değindiğimiz noktalar, konuyu ilk kez ele alan ekipler için de deneyimli geliştiriciler için de pratik bir kontrol listesi görevi görür. editorconfig üzerine çalışırken en çok fayda sağlayan yaklaşım, tek seferde her şeyi mükemmelleştirmeye çalışmak yerine küçük, ölçülebilir adımlarla ilerlemektir. Ekibinizde bu konuyu bir sonraki sprint retrospektifinde veya teknik tartışma toplantısında gündeme getirmenizi, burada anlatılan pratiklerden hangilerinin sizin bağlamınıza uyduğunu birlikte değerlendirmenizi öneririz. Sonuç olarak, doğru araçları seçmek kadar bunları ekip kültürüne oturtmak da başarıyı belirleyen asıl etkendir.