Elastik tablaların sakıncaları nelerdir? [kapalı]


83

Buraya bakın: sekmelerde boşluklara karşı tipik bir kutsal savaş .

Şimdi buraya bakın: elastik tablar . Tüm problemler çözüldü ve bir sürü çok yararlı yeni davranış eklendi.

elastik tablar

Elastik tabtaplar bile bu sekmelerde boşluk tartışmalarına girmiş midir? Neden olmasın? Elastik masa üstü fikrin dezavantajları o kadar ciddidir ki, hiç kimse onları popüler bir düzenleyicide uygulamamıştır?

EDIT : "neden bahsedilmedi" konusuna çok fazla önem verdiğim için özür dilerim. Gerçekten istediğim bu değildi; Bu soru muhtemelen konu dışı bile. Gerçekten demek istediğim, bariz bir şekilde yararlı bir fikrin benimsenmesini engelleyen bunun en büyük sakıncaları nelerdir? (her şeyin zaten desteklediği ideal bir dünyada)

(Microsoft Connect'te zaten bir elastik tabtopların Visual Studio uygulaması için bir istek ve Eclipse'de de bir istek olduğu ortaya çıktı . Ayrıca elastik tabtapları uygulayan diğer editörler hakkında da bir soru var )



11
"Boşluklara karşı sekmeler" tartışmasında hiç bahsedilmediler, çünkü çalışan bir programcının bunları kullanması neredeyse imkânsız. Belki bir Eclipse, VS, gvim ve emacs uygulamanız varsa bu değişebilir.
Paul Tomblin

2
Bu fikirden gerçekten hoşlanıyorum, ancak yalnızca bununla bir ay boyunca yaşadığınızda ya da tuzakların ne olduğunu gerçekten bildiğiniz zaman. Her şey gibi, beklemeyeceğiniz şeyleri yapan bazı durumlar da garanti edilir ...
Chris Burt-Brown

3
@ ChrisBurt-Brown Bu her zaman bir risk, evet. IntelliSense'in, istemediğiniz metinleri değiştirmek gibi, tuzakları da vardır. Ancak, genel olarak, C # ın IntelliSense büyük bir yağ kazanır.
Roman Starkov

4
Bu notepad ++ istiyorum ... Şimdi bunu istiyorum
Ben Brocka

Yanıtlar:


32

Kutsal Savaşlar Özneldir

Nick'in elastik sekmeleri, pek çok insanın uygulanabilir bir çözüm üzerinde hemfikir olmasına rağmen, bu Kutsal Savaş'ı tamamen sonlandıracağından kuşku duymama rağmen inanılmaz bir konsepttir : sonuçta, aynı zamanda bir zevk meselesidir ve pek çok programcı hareket etmeyecektir. uzlaşma pahasına olsa bile, bu konudaki konumlarından bir santim. Yani bu ilk sebep olurdu.

Örneğin, "boşluklar" tarafındaki birçok insan, yazılımınızda iyi bir görüntü oluşturma için ek bir mantık parçası gerektirdiğinden (örneğin, sadece SCM'nizin web görünümünde bir değişiklik setini görüntüleme) gerektirmediğinden hala hoşlanmayacaktır .

Uygulama sorunları

Ancak en açık neden , yalnızca giriş yapmadaki teknik engeldir : IDE'lerde ve metin editörlerinde birkaç yıl (on yıllarca olmasa da) uygulanandan temelde farklı bir kavramdır . Bazılarının çizgileri oldukça farklı bir fasionda işlemek için yeniden yazmaları gerekir; bu da, hat işleme kodlarında derin ve sıkı birleşme sıkıntısı çekme olasılığı daha yüksek olan eski ve daha büyük sistemler için zorlaştırır. Size sıfırdan (düşünmek başlamak ancak, çok daha kolay yapmak olduğunu Nick'in demo veya Git 'ın tabwriter paketine).

Kişisel bir fıkra için, yazara görünürde herhangi bir emac desteği olup olmadığını sormak için geri döndüğünü hatırlıyorum ve bu özel durumda önemsiz olmama nedeni olarak bundan bahsetti. Ayrıca, bu özelliğin uygulanmasına ve kitlelere getirilmesine yardımcı olmak için topluluktan yardım istedi.

Yeterince umursuyor muyuz?

Üçüncü bir sebep ise, bazı geliştiricilerin konuya o kadar bağlı olmadıkları ve bu çabaları desteklemek için fazladan mil harcayacakları kadar pek umursamadıklarıdır. Çoğu durumda, spaces-vs-tabs çatışması bir işletme engelleyici değildir, bu nedenle sorunun ardında çok fazla sürücü yoktur.

İstiyorsan, bunun için savaşmalısın. Açık kaynak kodlu yazılımda yapılabilecek olan. Bunları yeterince değiştirirseniz, kapalı kaynak kodlu olanlar, kullanıcı tabanlarının bir kısmının kaybolması riskini göze almak zorunda kalacaklardır.

Yani, istersen, Nick'e yardım et.


(konu dışı) Sık sık diğer "bu kadar güzel ama çok küçük" özelliklerin Visual Studio gibi ürünlere nasıl dahil olduğunu merak ediyorum. Görünüşe göre takımdaki birisi bunu kişisel sebeplerden dolayı uygulamak için zaman buldu. Örneğin, Visual Studio'da aynı anda birkaç satır yazmayı düşünün ; ondan binlerce insanın istediği gibi değil, ama hoşuma gidiyor.
Roman Starkov

3
@romkyns: Pek çok şey için olduğu gibi, ya sessiz bir içeriden ya da kapıdan çığlık atan binlerce ses alır.
haylem

35

Çoğu zaman, belgemin yerleşimini kontrol eden bazı gizli otomatik kurallar olmadan belgeyi istediğim gibi göstermesini sağlamak için bir kelime işlemci ile mücadele etmek zorunda kaldım. Editörün neden bu kelimeleri oraya yerleştirmekte ısrar ettiğini bulmak için bir saniye harcamak istemiyorum.


11
Ben de öyle değilim. Bu düşünceye tamamen sempati duyuyorum, çünkü bu tür kurallar da beni gerçekten sinir ediyor. Ancak bu iki şekilde farklı. Bir: Tıpkı şimdi tabtapları gibi, istemiyorsanız bunları kullanmak zorunda değilsiniz. İş arkadaşlarınızın metnini eğer kullanıyorsa yalnız bırakabilirsiniz. İki: Elastik tabtapların gizli kuralları yoktur, ancak bariz şekilde açık olanları vardır. Davranış tamamen doğaldır - belki de metin içinde bazı keyfi, genellikle alakasız bir pozisyonda meydana gelen geleneksel sekmelerden daha doğaldır. İşte bu yüzden hiç kimse artık girintili dışında başka bir şey için sekme kullanmıyor.
Timwi

10
@Timwi: Soru sakıncaları listelemek oldu. Yaptım.
mhoran_psprep

14
GIF’ten açıkça anlaşılmayabilir, ancak ilgili tek çözüm "SEKME" tuşuna bastığınızda, ne olursa olsun sonra gelenlerin dikey olarak düzgün bir şekilde çıkacağıdır. Kelime işlemcisi gibisi yoktur. Sadece asıl etkileşimli demosunu, yayınladığım bağlantıda deneyin; ne kadar doğal olduğunu göreceksiniz.
Roman Starkov,

3
@mhoran_psprep: Yeterince adil, girişinizi takdir ediyorum. Sanırım sorunun farklı yorumlarına bakıyorduk. Bu özelliği kullanarak kendinizin dezavantajlarını listeliyorsunuz, ben de bu özelliği tanıtmanın dezavantajları olduğunu düşündüm (yani, kullanılabilir kılmak ve zorunlu değil ).
Timwi

27

Bunları ilk defa duyuyorum. İyi bir fikir olup olmadıklarından emin değiliz, ancak zaten kodu otomatik olarak biçimlendiren araçlara (girinti gibi) sahip olduklarımızdan çok az yararlanmış görünüyorlar.

Zeki elastik mastarlarını vim içinde açıp düzenlediğimde ne olur? Sekme otomatik olarak mı temizleniyor yoksa bir karmaşaya mı kaptınız?

Gördüğüm gibi ana dezavantajları muhtemelen farklılıklar, sürüm kontrolü ve onları desteklemeyen editörlerle uyumlu olmamasıdır. Belki onları desteklemek için çok fazla kod değişikliği olabilir ve "kodu biçimlendirmek için başka bir sekme olayı" özelliğinden daha önemli şeyler vardır. Ne indentde olsa, hafıza hizmet ederse, yukarıdakilerin hepsini yapanları kullanabiliriz.


9
Ne geriye dönük bir tutum. Gelişmeyelim çünkü insanların en sevdiği eski, modası geçmiş araçları henüz başa çıkamıyor ! (Tabii ki, ironi, bu araçların (vim gibi) açık kaynak olmasıydı , bu yüzden eğer sizin için gerçekten önemliyse, ona elastik tabla desteği ekleyebilirdiniz (ve muhtemelen gerekir )
Timwi

14
@Timwi: Yaptığım noktayı tamamen kaçırıyorsunuz. Kod dosyanız elastik sekmelerden haberdar olmayan bir şey tarafından ayrıştırıldığında ne olur? Bir karmaşaya mı kaparsın yoksa başa çıkabilir mi? Versiyon kontrolü ve farkları ne olacak? Tüm araçların $ özelliğini desteklemesi dileğiyle, bu araçlar açık kaynak olsa bile gerçekçi değildir.
Sardathrion

14
@Timwi: Sen herkesin düşündüğün kadar harika olduğu elastik masa üstü durduğunu varsayıyorsun. Bu doğru olmayabilir.
Sardathrion

7
@Sardathrion haklı. Pencereleme sistemi olmadan * nix sunucuma uzaktan girmem gerektiğinde ve Vim / Emacs / Pico / Whatever ile bazı kodları incelemem gerektiğinde ne olur? Okunabilecek kadar iyi bir mekanizma varsa ... iyi olurdu ... aksi takdirde kabus olurdu. Elastik bant durdurmaların faydasının zaten bu kadar faydalı olduğunu görmüyorum. Kullandığım IDE'lerde nasıl olması gerektiğine bakmak için kodumu zaten otomatik olarak biçimlendirebilirim.
Rig,

7
Sürüm kontrol noktası iyi bir şey - İnsanların, koddaki yorumların yerleşimini / biçimini değiştirerek değiştirdikleri koddan keyfi bir şekilde uzaklaşarak sessizce değiştirmeye başlayacaklarını düşündüklerini sanmıyorum (OP'in animasyonundaki macenta bölümüne bakın) gIF). Oynamak için referans bir uygulamanın olması yararlı olacaktır, ancak şu ana kadar gördüğüm şey dikkate değer değil - emacs zaten bunun çoğunu yapıyor, sadece birkaç ekstra tuş vuruşu (ki bu muhtemelen iyi bir şey).
mcmcc

13

Dürüst olmak gerekirse, ilk heyecanı aştığınızda onları o kadar yararlı bulmuyorum. Mesela, bir satırın sonundaki yorumları beğenmedim - yorumlarımı her zaman ayrı bir satıra yerleştiririm. Bununla birlikte, elastik çıkıntılar ana kullanımlarını kaybeder.

Bundan sonra, elbette onları işlev argümanlarını (ve parametrelerini) ve uzun atama listelerini hizalamak için kullanabilirsiniz.

Fakat birincisi, tüm argümanları sadece bir ek seviyeyle girintileme eğilimindeyim ve bu da benimle tamamen uyumlu:

void foo(
    int x,
    int y,
    string z
)

Ve ben görmüyorum herhangi bunu değiştirmek için ihtiyaç.

Ve ödevleri hizalamaya gelince, bunu yapmam. Görevlerin etrafına tek boşluk koydum, hepsi bu. Ayrıca pek çok ödevi bir araya getirme eğiliminde değilim, bu nedenle nadiren okunabilirlik sorunu yaşanıyor.

Özetle, elastik sekmeler benim için kesinlikle sıfır işe yarar. Bu elbette değişkenlik gösterebilecek çok kişisel bir tercihtir, ancak bunun işe yaradığını buldum ve elastik sekmeler için destek eksikliğinin diğer insanların da benzer şekilde düşündüğü için olduğunu tahmin ediyorum.

Eğer bir editör bunları uygularsa, yine de kullanmazdım.


Takdir. Öyle görünüyorsa, eğer isterseniz satırın başlangıcından başka bir şeyi aynı hizaya sokmadığınızdan, isterseniz isterseniz genişlikli bir yazı tipi de kullanabilirsiniz. Visual Studio'nun aslında bunun için iyi bir desteği var ve okunabilirlik artışı çok güzel.
Roman Starkov

1
@romkyns Bununla ilgili tartışmalar yaptık ve bir tanesinde programlama için orantılı bir font kullanmayı denedim. Sonuçta, monospaced yazı tiplerinin girintiye aldırış etmese bile daha iyi çalışması oldu. Bunun dışında şu anda sadece Vim ve konsolda çalışıyorum, bunların hiçbiri orantılı fontları desteklemiyor.
Konrad Rudolph

1
@romkyns Demek ki, bu problemler çözülebilir (ya da programlama için tasarlanmış orantılı bir fontla çözülebilir). Ama yine de gerekliliği gerçekten göremiyorum.
Konrad Rudolph

13

Bir dezavantajı, bir satır grubunda hizalama yapmak ve ardından bir sonraki satırında girinti yapmak istediğinizde işe yaramamasıdır, çünkü bitişik satırların sekme duraklarını gruplandırır.

def foo( bar,
         xyzzy ):
         wibble() # Too much indentation

İstediğim şey:

def foo( bar,
         xyzzy ):
    wibble()

Kıvrımlı parantez dilleri için bu sorun daha az olabilir, çünkü genellikle açılış parantezini kendi satırına (animasyonda olduğu gibi) koyarak çözebilirsiniz, ancak boşluklara duyarlı diller için ve sonunda boşlukları kullanmaya geri dönmek zorundasın.


Kabul. Nick'in uygulaması Python gibi diller için hiç de iyi çalışmıyor.
Roman Starkov

3
Bu neden işe yaramadı? Bu temel bir sınırlama değildir, algoritmanın sadece dil farkında olması gerekir. Ancak, bir dereceye kadar bu, bugün bile geçerlidir, örneğin Vim, dile bağlı olarak farklı girinti kurallarını tanımlar. Bu kolayca Python girintisini barındırabilir.
Konrad Rudolph

1
@KonradRudolph Hayır, yapamadılar. Elastik sekmelerin çizilmesi, metin gruplarını otomatik olarak girintili / girintisiz bir şekilde bir araya getirme yeteneğidir. Basit bir örnek, bir "if" ifadesinin sonu: İfadeden çıktığınız için denemeyi denemeniz ve reddetmenizdir, ancak "akıllı" elastik tabtaplar da yukarıdaki veya iki satırın girintisini kaldırmaya karar verdiğinize karar verir. ve diğerleri ... Ve açıkça açıkça metni gruplandırmak zorunda kalırsanız, o zaman - nokta nedir?
Girintileri

1
@Izkata Manuel olarak tanıma, mevcut grubu sonlandırır (gerekir). Neden elastik tırnak uçları ile girintiyi manuel olarak kontrol ettin? Yapmazsınız, bu yüzden algoritma bunu yaptığınızda yukarıdaki bloğun girintisini değil, bir bloğun bitmesi olduğunu bilir.
Konrad Rudolph

1
Oh, iyi nokta. Hmm ... belki argümanları iki katına çıkartabilirsin? Öyleyse wibble()sadece tek bir girintiye sahip olacak ve bu nedenle işlev argümanlarına uymayacak mıydı?
Ajedi32

12

Neden sadece dikey sekme karakterini (VT, ASCII 11) elastik sekmelerin kullanıldığına işaret etmiyoruz? Herhangi bir ana programlama dilinde hiçbir amaca hizmet etmiyor , ancak hepsinde geçerli olan boşluk olarak ayrılıyor, AFAIK.

Bu, elastik sekme panellerinin kullanımının artık dışsallaştırılmış bir kongre olmadığı anlamına gelir (örneğin, "bu dosya elastik sekme panelleri ile biçimlendirildi, lütfen bunları açın"), ancak duruma göre tercih ettiğiniz bir şey.

Mevcut metin editörleri genellikle dikey sekmenin yerine bir glif veya tek boşluk görüntüler. Bu ideal değil, ancak ödenmesi gereken küçük bir bedel, IMO.


10

Söz konusu değil, çünkü çoğu metin editörünün IDE'sinde uygulanmadılar; bir projede küçük gerçek kullanımda bir yenilik.

Zımba kartlarından bu yana programlama yapmak için boşluklar kullanılıyor. Sekmeler ortaya çıktı ve birileri açıkça iyi bir fikir olduğunu düşündü (yanıldılar: p).

Çoğu modern editörün sekmeleri otomatik olarak boşluklara dönüştürebildiği günlerde ... oldukça anlamsızlar.

Tablar ve boşluklar gibi önemsiz bir şeyle başa çıkmak için başka bir araç yüklemek zorunda kalmam kesinlikle bana çekici gelmiyor ve meslektaşlarımın çoğunun bunu yapacağını sanmıyorum.


Hakarete inerken yorumları temizledim.
ChrisF

1
Sadece işaret edeceğimi düşündüm, elastik tabtaplar fikrini sevmemizin ana nedeni, sekmelerde boşluklar problemini çözmesi değil, asıl soruda GIF'de gösterilen davranış nedeniyle; otomatik, ağrısız hizalama. Ayrıca, VCS farkları için, bu örnekte gerekli boşluk boşluğu olmaması gibi ilave bir avantaj var.
Ajedi32

"Başka bir araç kurmalıyım ..." yeterince iyi bir argüman değil ... Zaten kullanılan yeterli araç yokmuş gibi.
Milind R

@MilindR Bunu yeterince iyi bir argüman olarak kabul etseniz de etmeseniz de, bunun nedeni (üç yıl önce) bununla hiç ilgilenmememdi. Yararlı bir şey yapmak için kullanılan birçok araç var, başka bir şey eklemek için bir neden değil, gerçekten, ortamınıza hiçbir şey eklemiyor.
TZHX

Bu gibi tutumlar, MS gibi şirketlerin kullanıcıları yeni UX'lere zorlamaya karar vermelerinin sebebidir ... Aynı tutum disketlere -> CD geçişine uygulanırsa ne olacağını düşünmekten çekinirim.
Milind R

4

Bence IDE'ler destekleselerdi daha fazla yarar bulurlardı (Microsoft!). İnsanlar çiçek kutularını yana tokatlayabileceklerini ve güzel bir şekilde okunabilir hale getirebileceklerini gördüklerinde, yapacaklardır. Birden kaynak koduna aniden daha fazla yorum eklenebilir (bu yalnızca iyi bir şey olabilir).

Sanırım "araç ipuçlarını" da "iyi olur mu ..." listesine ekleyebiliriz, bu nedenle büyük yorum bloklarınız gizlenip gerektiğinde kolayca görüntülenebilir. Belki de belgelerin bir parçasını oluşturan yorum blokları da alabiliriz (sandcastle türü şeyler değil, yalnızca yöntem başlıklarında değil, koda gömülmüş uygun kullanıcı tarafından okunabilen belge parçacıkları)

Dezavantajları: Gerçekten sadece 1 değiştirildiğinde (eğer editör dosyayı boşluklara dönüştürülmüş olarak kaydetmişse) bir satır dizisi değiştirilmiş gibi görünüyorsa kaynak farkınızın kötü görünmesine neden olabilir. Veya elastik sekme tek bir karakterle (veya daha büyük olasılıkla, 2 sekme noktası) uygulanmışsa, kaynağınızı düzenleyicinin dışında görüntülemek kötü görünebilir.

Sanırım fikri sevdim, bir satırın sonundaki 'sekme sekmesi' yorum bloğunu elastik hale getiriyor ve sonraki satırlardaki tüm yorumları (çift sekme aralığı olan) buna göre sıralıyor.


3

İşte nasıl görüyorum: popüler araçların çoğu zaten elastik tablaları destekliyorsa, birçok kişi bunları kullanırdı. Aynı şey vi'nin gezinme / düzenleme modunda, sözdizimi vurgulamasıyla ve daha sonra Intellisense ile oldu. Her durumda, yerleşik bilgelik faydalı olmadığına ya da gerekli olmadığına, ancak hayata geçirilip gitti.

Elastik tabla tablaları elbette nispeten düşük bir etkiye sahiptir. Çoğu insan statükodan yeterince mutlu ve bu yüzden umursamıyor. Benzer bir akıl yürütme, bazı insanların sahip olduklarından sadece mutlu oldukları ve daha ileri bir şeye geçmek için hiçbir sebep görmedikleri durumlara uygulanır. Başka bir deyişle, elastik tablalarla ilgili en büyük sorun, hemen hemen tüm diğer fikirlerle aynıdır: çekiş kazanması gerekir.

Ancak bu, özelliğin aşamalı olarak benimsenemeyeceği anlamına gelmez. Her bir programlama dili, bir ekibin kullanmaya başlamak için yeni bir derleyici ve yeni bir IDE gerektirmesine rağmen, aşamalı olarak kabul edildi. Aynısı, her bir donanım mimarisi ve diğer pek çok örnek için geçerlidir. Aynı zamanda, mevcut araçlarla entegrasyon eksikliğinin bir gösteri durdurucu olduğu durum söz konusu değildir: aynısı doğrudur, örneğin, yine de otomatik araçlar tarafından anlaşılan daha önceki daha az okunabilir bir formatın yerini aldığı “birleştirilmiş-fark formatı” için de geçerlidir. (yama gibi). Bu araçlar zamanla yükseltildi.

Başkalarının bahsettiği birlikte çalışabilirlik meselelerini takdir ediyorum, ancak bunlara rağmen, kesinlikle bunu tamamen tereddüt etmeden benimseyecek takımlar (benimki gibi) olacak. Farklılaşma, birleştirme vb. Gibi harici araçlar başlangıçta desteklemeyecektir, ancak satıcıları bu özelliği dahil etmeye teşvik etmek için elimizden geleni yapacağız. Her zaman böyle bir ilerleme kaydedilmiştir. Geçici bir geçiş dönemi için bazı acılar gerektiriyor ancak sonunda buna değer.


C vs C ++ argümanı biraz yanlış yönlendirilmiş görünüyor. Her ne kadar doğru olsa da (bazılarının söylediği gibi) "bazı insanlar" için geçerli olsa da, duruma bağlı olarak C ya da C ++ a tercih etmek için açık nedenler vardır. Varsayılan ayarda, C ++ çalışma zamanının bunlardan biri olması.
haylem

Haylem ile beraberim. Amacınız C-versus-C ++ karşılaştırması olmadan daha iyi olurdu. Onlar oldukça farklı diller. Aklıma göre, C, çok fazla kontrole ihtiyaç duyduğunuz (örneğin bir VM) sistem programlama ve diğer düşük seviye işler içindir. C ++, soyutlamanın karmaşıklığı (ad alanları, STL kapları ve algoritmaları, şablonlar) yönetmek için yararlı olduğu orta seviye uygulamalar için daha fazladır, ancak performans hala endişe vericidir (oyunlar en görünür örnek olarak).
Jon Purdy,

@haylem: Geri bildiriminiz için teşekkür ederiz. C / C ++ referansını kaldırdım.
Timwi

@JonPurdy: Geri bildiriminiz için teşekkür ederiz. C / C ++ referansını kaldırdım.
Timwi

2

Bununla ilgili en büyük problem, dokümantasyon boyunca tutarsız boşluklar. Bir programcı olarak bir döngü görmekten ya da 'standart' girintideki ifadeyi ve sonra farklı girintilerde fark etmekten rahatsızlık duyduğumu biliyorum. Şahsen, sadece baktığım kod bloğunda değil, tüm kaşlı ayraçlarımın tüm belgelerde birleştirildiğini görmek hoşuma gidiyor.

Genel olarak bunun güzel bir fikir olduğunu düşünüyorum, ancak şahsen bundan hoşlanmam.


1

JEdit’in, aşina olduğum programlama dilleriyle (özellikle HTML / XML ve C-benzeri diller) inanılmaz derecede iyi çalışan, elastik sekmelerin uygulanmasını denedim. Bununla birlikte, Python koduyla, nasıl işlendiği (sekmeler yerine işlerin nasıl hizalandığını göstermek için kullanılan alanlar):

def foo(x):
             '''<1 tab before the docstring.
No tab       <tab
No tab       <tab
             <tab  <another tab
             <tab  <another tab
             <tab'''
             if 1 or 2:    #<Tab before this comment
                           yield True

Boşluğa dayanan Python gibi bir dil için, elastik tablaların sağladığı işlevleri devre dışı bırakmadıkça, bu bir fırsat kırıcıdır. Vim ve Emacs gibi editörler, seçeneğin adını ve nasıl devre dışı bırakılacağını biliyorsanız, çoğu işlev türünü devre dışı bırakmayı basitleştirir, ancak bu işlevin yukarıdaki gibi kodlar için devre dışı bırakılması gerekir.

Söylendiği gibi, x86 ASM, C, C ++, Go, XML, HTML ve beyaz boşluklara çok fazla güvenmeyen diğerleri için harika:

import (
    "fmt"    // We love formatting functions.
    "io"     // Because I/O is useful.
    "os"     // Can't open a file without os.Open!
)

type Foo struct {
    Field1              int          // This is properly aligned
    ReallyLongField2    string       // with this.
    privateField        io.Reader    // Elastic tabstops are great for Go.
}

Scheme gibi Lisp lehçelerinin, aynı zamanda elastik tablaları "çirkin" kod haline getirebilecek kendi kuralları olduğunu söyleyeceğim. Sekme ayarlarımı 2 sütunun kurallarına uyacak şekilde değiştirirsem ve olağandışı yerlere (bir işlev ile bağımsız değişkenler arasına) sekmeler ekleyebilirsem:

(let loop ((n 1))
  (if  (> n 10)
        '()
        (cons  n
               (loop (+ n 1)))))

vs daha okunabilir:

(let loop ((n 1))
  (if (> n 10)
      '()
      (cons n
            (loop (+ n 1)))))

Verilen, bu Python örneği kadar kötü değil, ancak kesinlikle kodun okunabilirliğini azaltır. C # veya C ++ gibi bir şeyde kodlama yaparken işlevsellikten çok zevk alırken, boşlukların işlevsel ve / veya görsel olarak yararlı olduğu Python veya Scheme gibi bir dilde kodlama yaparken işlevsellikten nefret ediyorum. Elastik sekmeler, ayrı bir girinti yardımcı programı gerektirmeden yardımcı olmak için özel olarak oluşturulmuştur, ancak açıkça tüm programlama dilleri için değildir.


0

Emacs, henüz kapatılmamış parantezlerin varlığında girintiyi işler ve wilma'yı fred ile otomatik olarak hizalar . Eclipse'in neden aynı şeyi yapmadığını bilmiyorum. Tamam, bir fikrim var ama bu ücretsiz.

Emacs'ın yorumu çok fazla sorun olmadan da hizaya getirmesini sağlayabilirsiniz, ancak AFAIK hiç kimse ama siz hiç istemediniz.


2
Son cümlenizi yalnızca trolling olarak yorumlayabilirim, çünkü en azından bir kişi daha iyi tartışılan bir sayfa, bir Java uygulaması ve bunun neden iyi olduğunu göstermek için bir GIF oluşturmak için yeterince ciddiye almasını istedi. Cevapları okursanız Nick'in de yalnız olmadığını görürsünüz. Oh bekle, buraya da bak .
Roman Starkov

Bu arada, Emacs wilmaişlev isminin uzunluğunu değiştirmek gibi düzenlemeleri yaparken tekrar belirlenir mi? Eğer öyleyse, bu elastik tabureların yaptıklarına oldukça yakındır.
Roman Starkov

@romkyns: Ben altını üstüne getirirler istemedim, sadece anlamına geliyordu ben EMACS'in içinde girinti yorumun bu stili görmemişti. Genellikle EMACS, siz yazarken birden çok satırı yeniden girmez, ancak bu da değiştirilebilir.
kevin cline
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.