Steering Zig Fmt

• zig fmt, dosyada zaten bulunan sözdizimi biçimini yansıtarak aynı kodu birden fazla yerleşimde düzenleyebilen yönlendirilebilir bir formatter olarak kullanılabilir
• Fonksiyon çağrılarında trailing comma olup olmaması sonucu değiştirir; virgül yoksa tek satırda birleştirilir, varsa argümanlar satırlara dağıtılır
• Pratik akış, önce istenen kod yerleşimini belirleyip birkaç virgül eklemek, ardından biçimlendirme kısayoluna basarak gerisini zig fmt'ye bırakmak şeklindedir
• Dizilerde yalnızca trailing comma değil, ilk satır sonunun yeri de yansıtılır; ilk satır sonu üçüncü öğeden sonraysa öğeler 3'erli hizalanır
• ++ dizi birleştirmesi dikkatli kullanılırsa satır başına farklı sayıda öğe yerleştirilebilir; subprocess'e --key ve value çiftleri aktarılırken sabit argüman dizisiyle seçenek çifti dizisi birleştirilerek hizalama yapılabilir

---

zig fmt yönlendirme yöntemi

• zig fmt, mevcut dosyada zaten bulunan sözdizimi biçimine bakarak aynı sözdizimini birden fazla şekilde yerleştirebildiği için yönlendirilebilir bir formatter olarak kullanılabilir
• Fonksiyon çağrılarında trailing comma olup olmaması yerleşimi değiştirir

  f(1, 2,
        3);
  
  // -> zig fmt ->
  
      f(1, 2, 3);
  

  f(1, 2,
        3,);
  
  // -> zig fmt ->
  
      f(
          1,
          2,
          3,
      );
  

• Gerçek kullanım akışı, önce istenen kod yerleşimini belirleyip birkaç , eklemek, sonra biçimlendirme kısayoluna basarak gerisini zig fmt'ye bırakmak şeklindedir
• Formatter'ın yerleşimi tahmin etmesini beklemektense, kullanıcının temel seçimleri doğrudan bırakması daha uygun olabilir
• İyi biçimlendirmenin %90'ı mantıksal bloklar arasındaki boş satırlara ve uygun ara değişken seçimine bağlı olduğundan, bu seçimleri ortadan kaldırmak yerine onlardan yararlanmak daha iyi bir sonuçtur

Dizilerde sütun hizalı yerleşim

• Dizilerde trailing comma yalnızca her satıra bir öğe koymak anlamına gelmez; zig fmt, ilk satır sonunun yerini de dikkate alır

  .{ 1, 2, 3,
        4, 5, 6, 7, 8, 9, 10, 11,  };
  

• İlk satır sonu üçüncü öğeden sonraysa sonuç da öğeler 3'erli hizalanacak şekilde olur

  .{
          1,  2,  3,
          4,  5,  6,
          7,  8,  9,
          10, 11,
      };
  

• ++ dizi birleştirmesi dikkatli kullanılırsa satır başına farklı sayıda öğe yerleştirilebilir
• Subprocess'e --key ve value çiftleri aktarılırken sabit argüman dizisiyle seçenek çifti dizisi birleştirilerek aşağıdaki gibi hizalanabilir

  try run(&(.{ "aws", "s3", "sync", path, url } ++ .{
      "--include",            "*.html",
      "--include",            "*.xml",
      "--metadata-directive", "REPLACE",
      "--cache-control",      "max-age=0",
  }));
  

[GN⁺]

Lobste.rs görüşleri

• gofmtte de benzer bir biçimlendirmeyi yönlendirme davranışı olduğunu hatırlıyorum ve bu tür biçimlendiricileri rustfmtten daha çok seviyorum
  Yine de, hiç biçimlendirici olmamasındansa herhangi bir tür otomatik biçimlendirme olmasının daha iyi olduğunu düşünüyorum

  • “Hiç biçimlendirici olmamasındansa bir şey olması daha iyidir” lafını öylece geçmek zor
    Otomatik biçimlendiriciler sıradanlığı dayatır; biçimlendirmeyi iyi kullanamayanları yukarı çekerken iyi kullananları da aşağı çeker
    Ortak çalışmada, başkalarının bunu istemesi ya da onların kişisel biçimlendirme kurallarına güvenmenin zor olması durumunda kullanırım, ama tek başıma çalışırken asla kullanmam
    Benim de bir zevkim var, biçimlendiricinin de bir zevki var ve ikisi uzlaşmaz biçimde farklı
    Yine de bu yazıda gösterilen şeyin kendisi etkileyici
    O cümle bana Fiddler on the Roof’ta çöpçatan Yente’nin “Kötü bir koca bile—Tanrı korusun—kocasız olmaktan iyidir!” repliğini hatırlatıyor
  • Yanlış hatırlamıyorsam Elm biçimlendiricisi de benzer çalışıyordu ve özgün biçimlendirmeyi hiç dikkate almayan biçimlendiricilere kıyasla oldukça iyi hissettiriyordu
  • Bazı C++ projelerinde clang-format kullanıyoruz ve korkunç
    Sürümler arası istikrarı o kadar düşük ki clang-format yükseltmesi, kodun neredeyse her satırına dokunan bir biçimlendirme commit’ine dönüşüyor
    Bunun hiç biçimlendirici olmamasından daha iyi olup olmadığından gerçekten emin değilim
  • Eskiden uzun süre “hangi biçimlendirici olursa olsun hiç olmamasından iyidir” diye düşünürdüm ama son zamanlarda fikrim tamamen değişti
    Otomatik biçimlendiriciler esas olarak pull request’lerdeki bisiklet kulübesi tartışmalarını ortadan kaldırma gibi insan sorunlarını çözüyor
    Ama artık ajan tabanlı geliştirmeye geçerken bu sorun giderek daha az önemli hale geliyor
    Şu anda birkaç projede makineler işin çoğunu yapıyor ve böyle olunca biçimlendirici çalıştırmamanın daha iyi olduğu yönüne kayıyorum

• Python’da komut satırı argümanları oluştururken tuple’ları liste içine splat etmeyi seviyorum; yazının son örneğini muhtemelen şöyle yazardım

  [  
    "aws",  
    "s3",  
    "sync",  
    path,  
    url,  
          *("--include", "*.html"),  
    *("--include", "*.xml"),  
    *("--metadata-directive", "REPLACE"),  
    *("--cache-control", "max-age=0"),  
  ]  
  

• En son baktığımda zig fmtte 80 sütun sınırı kullanmayı seçme seçeneği yoktu; 100 sütun yerine 80 sütun kullanamıyordunuz, hâlâ öyle mi?
  Günde birkaç saatten fazla çalışıyorsam gözlerim daha az yorulsun diye terminal yazı tipi boyutunu büyütüyorum; böyle olunca 80 sütunla 100 sütun arasındaki fark, iki vim bölmesiyle nerd treeyi yan yana koyup koyamayacağımı belirliyor

  • zig fmtte sütun sınırı yok

• Hiç biçimlendiricisi olmayan bir ekibe rigid formatter getirmiş biri olarak, bazen biçimlendirmeyi elde biraz etkileyebilme yeteneğini özlüyorum
  Bu açıdan Zig’in esnek olması gerçekten harika

• Mükemmel!
  Bu tarz bir TS/JS biçimlendiricisi var mı?
  maplibre-gl kullanan bir projem var ve stil tanımı ifadeleri bazen öyle aşırı biçimlendiriliyor ki hiçbir şey seçilemiyor
  Şimdilik biçimlendirici kullanmayı bıraktım ama debug etme, kopyalama ve yorum satırına alma derken kod dağılmaya başladı
  Belki Zig biçimlendiricisi başka dilleri de biçimlendirecek şekilde yapılabilir :)

  • Prettier’da buna benzer bir şey var ama özellikle nesne literalleri ile sınırlı ve yalnızca “hepsi tek satırda” ile “her öğe ayrı satırda” arasında seçim yapabiliyorsunuz
    Örneğin, bir satıra dörder öğe koymasını biçimlendiriciye söylemenin bir yolu yok
    Ayrıca nesne literaliniz fazla uzunsa, girdi metni nasıl olursa olsun Prettier eninde sonunda bunu “her öğe ayrı satırda” biçimine dönüştürüyor

• Hafif türden biçimlendiricilerden, yani esasen yalnızca satır kıran biçimlendiricilerden hayal kırıklığına uğradım; bu yüzden daha katı örnekler içinde böyle bir esneklik fikrini kıskanıyor ve seviyorum :p
  Yakın zamanda fedi’de orantılı yazı tipleriyle Lisp yazıp biçimlendirme hakkında bir soruya yanıt verirken, anlamlı boşluk kullanan s-expression türevlerine, yani wisp, Readable/Sweet expressions, SRFI 119 ve 110’a değinmiştim
  Ayrıca bu sözdizimi ailesinin, isteğe bağlı infix notasyon uzantılarıyla satır kırmaları üzerindeki kontrolün bir kısmını geri verdiğini de not etmiştim

• İlginç bir tasarım ama hoşuma gidip gitmediğinden emin değilim
  Ben kendi biçimlendiricimde bunu farklı yapıyorum: biçimlendirici sondaki virgülü yok sayarak biçime karar veriyor, sonra çok satıra bölündüyse her zaman sondaki virgülü ekliyor, tek satırsa da her zaman kaldırıyor
  Bu yüzden “yönlendirme” yapılamıyor ama f(1, 2, 3) sondaki virgül olup olmamasına ya da token’lar arasındaki boşlukların miktarı ve türüne bakılmaksızın tutarlı biçimde biçimlendiriliyor
  Bir miktar yönlendirme gerekli
  Örneğin, uzun bir liste literaliniz [<expr1>, <expr2>, ..., <expr100>] varsa çoğu biçimlendirici her ifadeyi ayrı satıra koyar ama siz her satıra olabildiğince çok ifade sığdırmak isteyebilirsiniz
  Bunu sondaki virgülle belirlemek tuhaf görünüyor; genel olarak seçenekler 2 değil N tane olabilir
  Bu amaç için özniteliklerin daha uygun olduğunu düşünüyorum
  Örneğin, belki zaten vardır ama bir ifadenin başına #[rustfmt::list_layout(flow)] gibi bir şey koyup o ifadenin içindeki liste literalinin biçimlendirmesini etkileyebilmek güzel olurdu
  Çok fazla yönlendirme, tüm ekosistemde kod biçimini tutarlı kılma ve kod incelemelerini kolaylaştırma gibi biçimlendiricinin amacına zarar verir; bu yüzden yalnızca sınırlı durumlarda olmalı
  Uzun liste literalleri bunun için gerçekten iyi bir örnek
  Benim projelerimde de biçimlendirmenin test beklenen çıktılarını gözden geçirmeye yardımcı olduğu örnekler var; burada bunun bir örneği var
  Dart biçimlendiricisindeki başka bir “yönlendirme” davranışı da aklıma geliyor: uzun liste literallerinde satırları gruplamak için yorum satırları ekleyebiliyorsunuz
  Örneğin [1, 2, 3, ..., 1000] için her öğe ayrı satıra konuyor ama bunu elle şöyle gruplayabiliyorsunuz

  [1, 2, 3, 4, 5,  //  
   6, 7, 8, 9, 10, //  
   ...]  
  

  Bunun bilerek eklenmiş bir özellik mi yoksa yorum işleme biçiminden çıkan bir yan etki mi olduğunu bilmiyorum

  • Bu tam olarak rustfmtnin yaptığı şey ve beni deli ediyor
    Bazen satır uzunluğu sınırını aşsa bile bir fonksiyon çağrısını bölmemek daha okunaklı oluyor; buna dair kendi yargımı yansıtabilmeyi isterdim
    Aklıma gelen örneklerden biri OpenGL
    Genelde tek bir kaynağı değiştirirken ya da kullanırken, örneğin doku başlatma sırasında, peş peşe çok sayıda gl.* çağrısı yapıyorsunuz; rustfmt ise “satır çok uzun, bölmek gerek” gibi robotik bir amaç dışında hiçbir sezgi olmadan bunları zorluyor
    Bu örnek davranışı göstermek için yapay olarak hazırlanmış; gerçek rustfmt davranışıyla tamamen aynı değil
    Satırlar da o kadar uzun değil
    Şu an telefondan yazıyorum, o yüzden %100 doğru bir örnek hazırlayacak araçlarım yok

    gl.bind_texture(gl::TEXTURE_2D, tex);  
    gl.tex_parameteri(gl::TEXTURE_2D, gl::TEXTURE_MIN_FILTER, gl::NEAREST);  
    gl.tex_parameteri(gl::TEXTURE_2D, gl::TEXTURE_MAG_FILTER, gl::NEAREST);
    
    // -->
    
    gl.bind_texture(gl::TEXTURE_2D, tex);  
    gl.tex_parameteri(  
        gl::TEXTURE_2D,  
        gl::TEXTURE_MIN_FILTER,  
        gl::NEAREST,  
    );  
    gl.tex_parameteri(  
        gl::TEXTURE_2D,  
        gl::TEXTURE_MAG_FILTER,  
        gl::NEAREST,  
    );  
    

    Birbiri ardına gelen gl.tex_parameteri çağrılarını böyle çok satıra bölüyor ama aslında her çağrının tek satırda tamamen açık kalması daha iyi
    Çünkü sütunlar hizalandığında iki satır arasındaki farkları görmek çok daha kolay oluyor
    Bölünmüş sürümde görsel yakınlık azalıyor ve okumak zorlaşıyor
    İki satırı gözle kolayca karşılaştıramıyorsunuz
    Bir de, karakter sınırı içine sığdırarak biçimlendiremeyince tamamen pes etmesi gibi komik bir durum var
    Derleyici kodu yazarken tanı mesajlarını string literal olarak oluşturduğumda bu sık oluyor; çünkü mesajlar epey uzun olabiliyor
    rustfmt bunu nasıl böleceğini bilemediği için vazgeçiyor ve ilgili ifadenin tamamını biçimlendirmiyor
    Sıklıkla şöyle bir şey oluyor

    match something {  
        // ... match arms above this one ...  
        _ => emit_diagnostic(&mut state, "This is a very long message to try and illustrate the problem. Help: please consult a doctor.")  
    }  
    

    Burada emit_diagnostic çağrısı yalnızca bir ifade diye tüm match ifadesini biçimlendirmekten vazgeçmesi düpedüz saçma
    Kodumu illa 100 sütuna sıkıştırmaya çalışmasaydı bunların hepsi önlenebilirdi

• Son kısımdaki yorumu görüp benim gibi aratmak zorunda kalanlar için yazayım: ++, dizi birleştirme operatörü
  Dolayısıyla diziyi iki parçaya ayırırsanız bunları farklı biçimde biçimlendirebilirsiniz