[Fikir] saqut fmt — Otomatik Kod Biçimlendirici (Formatter) #93

New Issue

saqut · 2026-06-14T22:14:07+03:00

saqut commented

2026-06-14 22:14:07 +03:00

Giriş (Nedir, Neden Önemli?)

gofmt, rustfmt, prettier gibi araçlar artık modern bir dilin "olmazsa olmaz"ı haline geldi: kod her zaman aynı şekilde biçimlenir, "stil tartışmaları" ortadan kalkar. saQut'un AST'si zaten JSON'a serileştirilebiliyor — bu, bir formatter için iyi bir temel.

Gelişme (Olası Yaklaşımlar)

saqut fmt file:kaynak.sqt: dosyayı ayrıştırır (AST), AST'yi kanonik bir şekilde tekrar kaynak koda yazdırır (pretty-printer / AST → metin).
Yorumların (comment) korunması en zor kısım — AST yorum bilgisini taşımıyorsa (Faz 0-1 sırasında bu netleşmeli), formatter yorumları silebilir veya yanlış yere koyabilir. Bu, AST tasarımına şimdiden not edilmesi gereken bir kısıt.
"Öncesi/sonrası" felsefesiyle: saqut fmt --check (CI'da kullanılabilir — "bu dosya zaten formatlı mı?") ve saqut fmt --write (dosyayı yerinde değiştir) ayrımı yapılabilir.

Açık Sorular

Pretty-printer, AST'den mi yoksa doğrudan token akışından mı (yorumlar dahil tüm token'lar tokenizer'da zaten tutuluyor) üretilmeli — token-tabanlı yaklaşım yorum-koruma sorununu çözebilir.
Biçimlendirme kuralları (girinti, boşluk, satır uzunluğu) nasıl ve nerede sabitlenecek — docs/ altında bir "stil kılavuzu" mu yazılacak?

İmza/Yorum: AST tasarımı (Faz 1) sırasında "yorumlar AST'de nasıl temsil edilir" sorusu bu issue'yu doğrudan etkiler — şimdiden not düşülmeye değer bir bağımlılık.

### Giriş (Nedir, Neden Önemli?) `gofmt`, `rustfmt`, `prettier` gibi araçlar artık modern bir dilin "olmazsa olmaz"ı haline geldi: kod her zaman aynı şekilde biçimlenir, "stil tartışmaları" ortadan kalkar. saQut'un AST'si zaten JSON'a serileştirilebiliyor — bu, bir formatter için iyi bir temel. --- ### Gelişme (Olası Yaklaşımlar) - `saqut fmt file:kaynak.sqt`: dosyayı ayrıştırır (AST), AST'yi **kanonik bir şekilde** tekrar kaynak koda yazdırır (pretty-printer / AST → metin). - Yorumların (comment) korunması en zor kısım — AST yorum bilgisini taşımıyorsa (Faz 0-1 sırasında bu netleşmeli), formatter yorumları silebilir veya yanlış yere koyabilir. Bu, **AST tasarımına şimdiden not edilmesi gereken bir kısıt.** - "Öncesi/sonrası" felsefesiyle: `saqut fmt --check` (CI'da kullanılabilir — "bu dosya zaten formatlı mı?") ve `saqut fmt --write` (dosyayı yerinde değiştir) ayrımı yapılabilir. --- ### Açık Sorular - Pretty-printer, AST'den mi yoksa doğrudan token akışından mı (yorumlar dahil tüm token'lar tokenizer'da zaten tutuluyor) üretilmeli — token-tabanlı yaklaşım yorum-koruma sorununu çözebilir. - Biçimlendirme kuralları (girinti, boşluk, satır uzunluğu) nasıl ve nerede sabitlenecek — `docs/` altında bir "stil kılavuzu" mu yazılacak? *İmza/Yorum:* AST tasarımı (Faz 1) sırasında "yorumlar AST'de nasıl temsil edilir" sorusu bu issue'yu doğrudan etkiler — şimdiden not düşülmeye değer bir bağımlılık.

saqut added the

fikir

tooling-lsp

labels 2026-06-14 22:14:07 +03:00

saqut referenced this issue

2026-06-14 22:26:32 +03:00

[Fikir] Modernlik için Go Tarzı Tasarım Kararları (Basitlik, Hızlı Geri-Bildirim, Tek Binary) #110

saqut referenced this issue

2026-06-14 22:36:52 +03:00

[Fikir] CLI Komut Seti — Tam Araç Zinciri Vizyonu (Tier 0-3: check/fmt/test/repl/build/pkg/...) #107

saqut referenced this issue

2026-06-14 22:37:46 +03:00