Yan yana

LintingvsKod Biçimlendirici

Linter ile formatter (kod biçimlendirici) arasındaki fark nedir?

Güncellendi 6 Ekim 20262 dk okuma7 fark

Kısaca

Linter kodu olası hatalar ve riskli kalıplar açısından inceleyip raporlar; formatter ise yalnızca girinti ve satır sonları gibi düzeni yeniden yazar.

Test ve Kalites. 15

Linting

Linting, kaynak kodu çalıştırmadan otomatik olarak analiz edip olası hataları, stil sorunlarını ve şüpheli kalıpları kod yayına çıkmadan işaretleme işlemidir.

Linting sayfasını oku

Programlamanın Temelleris. 38

Kod Biçimlendirici

Kod biçimlendirici, kaynak kodu tek ve tutarlı bir düzene sokan araçtır; kodun ne yaptığını değiştirmeden girintiyi, boşlukları ve satır sonlarını düzeltir.

Kod Biçimlendirici sayfasını oku

Linting ve Kod Biçimlendirici karşılaştırması

Özellik	Linting	Kod Biçimlendirici
Neye bakar	Kodun ne yaptığına: olası hatalar, riskli kalıplar, kurallar	Kodun nasıl göründüğüne: girinti, boşluklar, satır sonları, tırnaklar
Çıktı	Bir kısmı otomatik düzeltilebilen uyarılar ve hatalar listesi	Tutarlı bir düzende yeniden yazılmış aynı kod
Yargı gerektirir mi	Evet: her uyarıyı bir insan düzeltir, yok sayar ya da kapatır	Hayır: sonucun tamamına araç karar verir
Yapılandırma	Her biri kapalı, uyarı ya da hata olarak ayarlanan birçok kural	Bilinçli olarak az seçenek; gofmt'nin stil için hiç ayarı yoktur
Hata yakalar mı	Evet; örneğin kullanılmayan bir değişkeni ya da eksik bir `await` ifadesini	Hayır; mantık hakkında hiçbir yargıda bulunmaz
Örnekler	ESLint, Pylint, Ruff, Clippy, golangci-lint	Prettier, Black, gofmt, rustfmt, clang-format
CI'da	Kurallar hata bildirdiğinde derlemeyi başarısız kılar	Bir dosya biçimlendirilmemişse derlemeyi başarısız kılar; `prettier --check` gibi

Fark, açıklamalı

İkisi de kaynak kodu çalıştırmadan okur, ama farklı şeyler arar. ESLint, Pylint, Ruff ya da Clippy gibi bir linter, kodu bir kural kümesine göre denetler ve olası hataları ve şüpheli kalıpları raporlar: kullanılmayan bir değişken, eksik bir await, bir koşulun içindeki atama. Prettier, Black, gofmt ya da rustfmt gibi bir formatter (kod biçimlendirici) ise kodun düzenini tek ve tutarlı bir stile göre yeniden yazar; girintiyi, boşlukları, satır sonlarını ve tırnakları düzeltir, ama kodun ne yaptığını değiştirmez.

Asıl fark, anlam ile görünüş arasındadır. Linter kodun ne yaptığını değerlendirir; her uyarının nasıl çözüleceğine bir insan ya da otomatik bir düzeltme karar verir. Kuralları yapılandırılabilir ve birçoğu doğrulukla ilgilidir. Formatter ise hiçbir yargıda bulunmaz: kodu ayrıştırır, eski düzeni bir kenara atar ve yeniden yazdırır; bu yüzden sonuç, kodu kim yazmış olursa olsun aynıdır ve tartışılacak bir şey kalmaz.

Ekipler genellikle ikisini birlikte, editörde kaydederken, bir pre-commit hook'unda ve CI'da bir denetim olarak çalıştırır; düzenle ilgili her kararı formatter'a bırakır ve ikisi çakışmasın diye linter'ın stil kurallarını kapatır. ESLint de bu nedenle 2023'te kendi biçimlendirme kurallarını kullanımdan kaldırdı (deprecated); eslint-config-prettier gibi yapılandırmalar da çakışan kuralları kapatır. Ruff ve Biome gibi bazı yeni araçlar, linter ile formatter'ı bir arada sunar.

Sık yapılan bir yanlış, formatter'ın linter'ı gereksiz kıldığı ya da bunun tersinin doğru olduğu düşüncesidir. Kusursuz biçimlendirilmiş kodda da kullanılmayan bir değişken ya da unutulmuş bir await olabilir; boşlukları zorunlu kılan bir linter ise formatter'ın işini yavaşça, uyarı uyarı yapar. İkisi de kodu çalıştırmadığı için hiçbiri testlerin yerini tutmaz.

Hangisini kullanmalısınız?

Linting şu durumlarda doğru seçim:

Kullanılmayan değişkenler ya da ele alınmamış promise'ler gibi olası hataları kod incelemesinden önce yakalamak istiyorsunuz.
Ekibin, yasaklı API'ler ya da adlandırma kuralları gibi kuralları zorunlu kılması gerekiyor.
Uyarıları yalnızca testler başarısız olduktan sonra değil, siz yazarken editörde görmek istiyorsunuz.

Kod Biçimlendirici şu durumlarda doğru seçim:

Stil tartışmaları ve boşluklarla ilgili yorumlar kod incelemesini yavaşlatıyor.
Diff'ler yeniden biçimlendirmeyi değil, yalnızca gerçek değişiklikleri göstermeli.
Birçok kişinin ve aracın yazdığı kod, neredeyse hiç yapılandırma gerektirmeden aynı görünmeli.

Aynı fonksiyon, bir linter'dan ve bir formatter'dan geçerken

Lintingjavascript

// Linter (ESLint): reports problems; the layout is left alone
async function save(user){
  const id=user.id
  db.write(user)
  return true
}

// 1:1  error  Async function 'save' has no 'await' expression  require-await
// 2:9  error  'id' is assigned a value but never used  no-unused-vars

Kod Biçimlendiricijavascript

// Formatter (Prettier): rewrites the layout; the problems are left alone
async function save(user) {
  const id = user.id;
  db.write(user);
  return true;
}

// Still unused, still not awaited: formatting doesn't judge the logic

Sık sorulan sorular

Hem linter'a hem formatter'a ihtiyacım var mı?

Genellikle evet, çünkü farklı şeyleri yakalarlar. Düzeni formatter'a bırakın, linter'ın stil kurallarını kapatın ve ikisini de kaydederken ve CI'da çalıştırın. Ruff ve Biome gibi araçlar ikisini bir arada sunar.

ESLint kod biçimlendirebilir mi?

Eskiden boşluk, tırnak ve noktalı virgül kurallarıyla biçimlendirebiliyordu; ama ESLint bu kuralları 2023'te kullanımdan kaldırdı ve ayrı bir formatter kullanmayı önerir. Bu kurallar, topluluk tarafından sürdürülen ESLint Stylistic projesinde yaşamaya devam ediyor.

Prettier bir linter mi?

Hayır. Prettier yalnızca kodu yeniden biçimlendirir ve hiçbir zaman hata raporlamaz. CI'da --check ile çalıştırmak, bir dosya biçimlendirilmemişse onun başarısız olmasını sağlar; bu linting'e benzeyebilir, ama yine de yalnızca düzeni denetler.