SQL Formatlayıcı

Code review'a düşen 200 karakterlik tek satır

Pull request'te tek satırlık bir değişiklik var ve o satır 200 karakter. İçinde üç JOIN, dört koşul ve bir alt sorgu geçiyor. Yorum yazacaksınız ama önce sorguyu kafanızda parçalamanız gerekiyor, çünkü nerede bittiğini görmek için yatay kaydırmanız lazım. İnceleme burada fiilen duruyor: kimse o satırı okumuyor, herkes onaylıyor. Biçimlendirme meselesi estetik değil, gözden geçirilebilirlik meselesi.

Neden regex ile SQL biçimlendirilmez

İnternetteki biçimlendiricilerin çoğu ham metin üzerinde arama değiştirme yapıyor ve bu üç ayrı yerden sızdırıyor. Birincisi: string literal içindeki bir kelime anahtar kelime sanılıp büyütülür, sorgu artık farklı bir satırı sorgular. İkincisi: -- yorumunun ortasına satır sonu eklenirse yorumun devamı gerçek SQL haline gelir ya da tersi olur. Üçüncüsü: tek tırnak içinde geçen '' kaçış dizisi naif bir tarayıcının senkronunu bozar, o noktadan sonra bütün belge yanlış sınıflandırılır.

1-- Girdi2select * from posts where title = 'select' and note = 'it''s fine'3 4-- Regex tabanlı biçimlendirici (bozuk)5SELECT * FROM posts WHERE title = 'SELECT' AND note = 'it''S FINE'6 7-- Tokenize eden biçimlendirici (doğru)8SELECT9  *10FROM11  posts12WHERE13  title = 'select'14  AND note = 'it''s fine'

Çözüm üç sorun için de aynı: metni bir kez düzgün tokenize edip string literalleri, tırnaklı tanımlayıcıları ve yorumları bayt bayt geçen opak parçalar olarak ele almak. Bu araçta yalnızca anahtar kelime olarak sınıflandırılan tokenlerin büyük küçük harfi değişiyor, yerleşim kararları da yalnızca token sınırlarına bakıyor. Çıktının bir başka özelliği idempotent olması: biçimlendirilmiş çıktıyı tekrar biçimlendirdiğinizde aynı metin çıkıyor, bu da tokenizer'ın kendi çıktısını okuyabildiğinin kanıtı.

Okunabilir clause yapısı ve diff kalitesi

Araç SELECT, FROM, WHERE, JOIN türevleri, GROUP BY, ORDER BY gibi clause başlangıçlarını tanıyıp her birini yeni satıra alıyor, gövdelerini de bir seviye içeri kaydırıyor. UNION bu kuralın dışında: iki sorguyu aynı seviyede ayırdığı için gövdesi içeri alınmıyor, aksi halde olmayan bir iç içelik ima edilirdi. LEFT OUTER JOIN gibi çok kelimeli açılışlar LEFT JOIN'den önce sınanıyor, yoksa kısa eşleşme kazanır ve artakalan kelimeler yanlış satırda kalır.

Her SELECT kolonunu ayrı satıra almanın somut faydası versiyon kontrolünde ortaya çıkıyor. Tek satırdaki elli kolonluk listeye bir kolon eklediğinizde diff o satırın tamamını değişmiş gösterir ve gözden geçiren kişi farkı gözüyle aramak zorunda kalır. Kolonlar ayrı satırlardaysa eklenen kolon tek bir yeşil satır olarak görünür. Aynı mantık AND ile ayrılan koşullar için de geçerli.

Anahtar kelime yazımı ve dialekt farkları

Anahtar kelimeleri büyük harfle yazmak yaygın gelenek, çünkü tablo ve kolon adlarından görsel olarak ayrılıyor. Küçük harf tercih eden ekipler de var ve teknik olarak ikisi de doğru: hiçbir veritabanı anahtar kelimelerde büyük küçük harfe duyarlı değil. Seçimin kendisinden çok tutarlılık önemli, çünkü karışık yazım gereksiz diff üretiyor. Araç yalnızca tanıdığı anahtar kelime listesindeki sözcükleri dönüştürüyor; status adlı bir kolon ya da public adlı bir şema yazdığınız gibi kalıyor.

Biçimlendirme performansı etkilemez

Sık gelen bir endişe, girintili sorgunun daha yavaş çalışacağı. Öyle bir şey yok. Veritabanı sorguyu kendi ayrıştırıcısından geçirip bir plana çeviriyor ve boşluklar o ayrıştırmanın ilk adımında düşüyor. Tek satırlık sorgu ile yirmi satırlık biçimlendirilmiş hali aynı planı üretir, aynı sürede çalışır. Ağ üzerinden birkaç yüz bayt fazla metin gider, ölçülebilir bir farkı yoktur. Kazanç tamamen sorguyu okuyacak insanda.