• çok büyük mesele. ne bu mesele? basic ve assembly gibi istisnalar dışında programlama dillerinde kod öbeklerini kolayca ayrıştırmak için bir öbeğe ait kodlar daha içerden yazılır. öyle yazılmadığında sözlükteki kod örnekleri gibi okunaklık düşer. hatta bazı dillerde python, f# düzgün girintili yazılmadığında kodu çalıştırmak bile mümkün olmaz. mesela kodu dümdüz yazsaydık:

    void main(void) {
    if (x > y) {
    switch(x) {
    case 5:
    y = 3;
    break;
    case 10:
    y = 4;
    break;
    }
    else {
    if (x == y) {
    y = 5;
    } else {
    y = 7;
    }
    }

    kodu derinlikli göremiyoruz, haliyle hangi kod satırları hangi kapsama ait, hangi süslü parantez neyi kapatıyor falan anlamıyoruz. oysa ki girintili kodda:

    void main(void) {
    .....if (x > y) {
    ..........switch(x) {
    ...............case 5:
    ....................y = 3;
    ....................break;
    ...............case 10:
    ....................y = 4;
    ....................break;
    ..........}
    .....else {
    ..........if (x == y) {
    ...............y = 5;
    ..........} else {
    ...............y = 7;
    ..........}
    .....}

    bak mesela girintili yazınca iki tane kıvrığı* kapamayı unuttuğumu fark ettim. kodun işleyiş mantığı, her ne kadar mantıklı bir iş yapmıyor olsa da daha anlaşılır oldu.

    bu girinti boşluklarını sözlükte mecburen noktalı yazmam gerekse de normalde iki şekilde ifade edebiliyoruz: boşluk karakteri ve tab karakteri. boşluk karakteri (32 numaralı ascii karakteri) biz boşluk tuşuna (space bar) basınca ekrana çıkan karakter. tab karakteri ise (9 numaralı ascii karakter) ekranda görünen bir karakter değil. değeri 32'den düşük tüm karakterler gibi o da bir kontrol karakteri. yani normalde yer kaplamayıp metin işleyicisine özel iş yaptıranlardan. aynen yeni satıra geçme işini (ve haliyle satırları bölme işini) ascii tablosunda 13 ve 10 numaralı kontrol karakterlerinin yaptırması gibi.

    tab karakteri napıyor? geleneksel olarak imleci bir sonraki sütunun başına getiriyor. genişliği değişebilir, antika standardı 8 karakter. ama editörden 4 diye ayarladın o da olumlu. tab'ın boşluktan farkı her zaman genişliğin katları olan bir noktaya götürmesi. o yüzden mesela tab karakterine "t" boşluk karaterine "b" diyelim ve tab genişliğimiz 8 olsun:

    bbbbt
    bbbt
    bbt
    t

    kullanımlarının tamamı satırı 8. sütuna hizalayacaktır. oysa ki boşluk her zaman kaç boşluk varsa o kadar görünür. haliyle mesela tab genişliği ayarını 4 yapan birinde ilk örnek (bbbbt) 8 yerine 16. kolona hizalayacağından satırlar birbirine girecek saçmalayacak.

    geliştiricilerin tüm kavgası da bu tutarsız kullanıma engel olmak için "birini seçelim ve hep onu kullanalım" deyip hangisi olacağı konusunda uzlaşamıyor olmalarından kaynaklı. kimi "hepsi tab olsun mis gibi" diyor kimi "hepsi boşluk olsun mis gibi" diyor.

    boşlukçuların en temel argümanı: "zaten boşluk için boşluk kullanıyoruz, baştaki boşluğa niye farklı karakter kullanıyoruz?"

    tabcıların en temel argümanı: "ben belki girintileri takımdakilerin kullandığından farklı genişlikte görmek istiyorum?"

    evet işte tüm tab mı boşluk mu tartışmaları özünde sadece bu iki meseleye indirgeniyor. geri kalan tüm argümanlar ya artık çok antika (misal "tab daha az yer kaplıyor"), ya günümüz modern geliştirme ortamlarında anlamlı değil (misal "tablı kodda imleçle daha hızlı geziniyorum"), ya da tamamen palavra (misal "tab semantik değer katıyor").

    ben boşlukçuyum. bunun için de çok basit gerekçelerim var:

    1) tab bir kontrol karakteri olarak yorumlama gerektirdiğinden yorum tutarsızlığına açık. başta bahsettiğim standarda uymayan editörler mevcut, emacs bi garip diyorlar mesela. sadece kodun içeri girinti görünmesi için bir yorumlama karmaşasına dalmak büyük bir bedel. oysa ki boşluk karakterinin yorum tutarsızlığı yok. hafızadaki haliyle görünen hali aynı. boşluğu doğru desteklemek ve doğru destekleyen ortam elde etmek çok daha kolay. yani tamamen tab kullansan bile tutarsız vaziyetlere düşebilecekken boşlukta düşme imkanı yok.

    2) tab karakteri geliştiricinin kodun nasıl görünmesini istediği konusundaki tercihini korumuyor. bu açıdan boşluğa kıyasla kayıplı sıkıştırma algoritması gibi. bu yüzden mesela github gibi yerlerde tarayıcının ya da sitenin kendi kafasına göre seçtiği değerle görüyoruz. tab'ın temel argümanı olan "ben böyle seviyorum" başka yoldan yine eziliyor. hayır tarayıcınızda "bana tabları şöyle göster" ayarı yok. eklentilere ya da 8 karakterlik sütunlara mahkumsunuz. bu sadece tarayıcıyla sınırlı da değil. tab karakterini kullanan her yerde tercihleriniz varsayılanlarla eziliyor. cat'le less'le dosyaya bakacaksanız patlıyor, kalkıp orada yeniden tab ayarı yapmanız gerekiyor. görsel bir gereçle diff'ine bakacağınız zaman patlıyor. farklı projelerde ya da dosya tiplerinde farklı tab genişliği tercihlerniz varsa bunları ayrı ayrı anlatma lüksünüz editör dışındaki hiçbir ortamda olmuyor.

    3) takımca belirlenen kodlama standartlarının hepsinde "tab mı boşluk mu"dakine benzer uzlaşmazlıklar yaşamak mümkün. mesela "public member'lar capitalcase yazılır" diye bir kuralı sevmeyen biri için editörün public member'ları camel case gösterirmişçesine ilüzyon yapan özelliği var mı? yok. bunu soran, isteyen var mı? yok. bir kodlama standardında onlarca, yüzlerce madde olabiliyor. tab meselesi bunlardan sadece biri. yani neymiş "ben böyle seviyorum" aslında sadece tab'lara gelince, o da sırf bize imkan sağlandığından kullanılan bir bahaneymiş. eğer tab karakterinden 20 yıl önce kurtulmuş olsaydık bu konuyu bugün tartışıyor bile olmayacaktık. oysa ki boşluk karakterini atma diye bir şey sözkonusu değil. unutmayalım: "zerafet, ekleyecek değil, çıkarılacak bir şey kalmadığında elde edilir" --yılmaz morgül

    o yüzden hep birlikte, aydınlık bir geleceğe doğru:

    [x] insert tabs as spaces
  • (bkz: yerine göre)
  • bu soruyu bir microsoft word kullanıcısı sorsaydı, verilecek yanıt "tab" olurdu. eğer bir yerde geniş bir boşluk bırakmak gerekiyorsa, boşluğun bitmesi gereken noktaya bir adet sekme durağı koymalı; sonra da tab tuşuna basmalı ki sekme durağına kadar boşluk oluşsun, boşluk belirli olsun, dosya başka bilgisayarda düzensiz görünmesin, satırlar arasında uyum olsun, sağlıklı bir metin oluşturulmuş olsun.

    (bkz: sekme yerine boşluk tuşuna abanmak)
  • kullanacağım alana göre değişir. mesela hazır bir şablonu düzenlerken, şablonu oluşturan kişinin kullandığı boşluğa/tab'e göre bende aynı şekilde devam ederim. kendi yazdığım kodlarda genellikle tab kullanırım fakat bazen boşluk kullandığımda oluyor. yani cevap: yerine göre
  • (bkz: hortum mu kıble mi) *
  • tabs versus spaces—what is the proper indentation character for everything, in every situation, ever?
  • okudum lan. baya çok eğlenceli.
  • (bkz: 12 subat 2016 ssg can sikilmasi rezaleti)
  • (bkz: indentation)
  • ne tab ne space. ide { } gördüğü anda bloğu görsel olarak kendi kaydırmalı. bu işi niye programcıya bırakıyorlar anlamıyorum.
hesabın var mı? giriş yap