Neden “do” yu “ile” aynı çizgiye yerleştirmem gerekiyor?

1. Özet

Anlamıyorum, neden E010 bazhate kuralına ihtiyacım var ?

2. Ayrıntılar

Dosyaları sıralamak için bashate kullanıyorum .sh. E010 kuralı:

yapmak aynı satırda değil için

for bashate:

• Doğru:

  #!/bin/bash
  for f in bash/*.sh; do
      sashacommand "$f"
  done

• Hata:

  #!/bin/bash
  for f in bash/*.sh
      do sashacommand "$f"
  done

Herhangi bir geçerli tartışma var mı, neden ihtiyacım var forve doaynı satırda?

3. yararlı değil

Soruma cevap bulamıyorum:

1. Google
2. En iyi kodlama uygulamaları hakkında makaleler ( örnek )

3. temel belgeler . Ben sadece buluyorum:

   Kontrol bloklarında olayların tutarlı kalmasına yardımcı olan bir dizi kural. Bunları devam ettiren uzun çizgilerde görmezden gelinir, çünkü bunun çözülmesi bir tür “ilginç”

Sözdizimsel olarak, aşağıdaki iki kod parçacığı doğru ve eşdeğerdir:

for f in bash/*.sh; do
    sashacommand "$f"
done

for f in bash/*.sh
    do sashacommand "$f"
done

İkinci bir olabilir , muhtemelen olarak okumak daha olduğu söylenebilir dohafif döngü gövdesinde komutu üstünü örter. Döngü birden fazla komut içeriyorsa ve bir sonraki komut yeni bir satırdaysa, şaşırtmaca daha fazla vurgulanır:

for f in *
    do cmd1
    cmd2
done

... ancak bunu bir "hata" olarak işaretlemek, IMHO'nun nesnel bir gerçeklikten ziyade kişisel görüşünü ifade eder.

Genel olarak, neredeyse her ;şey bir newline ile değiştirilebilir. Her ikisi de ;ve newline komut sonlandırıcılar. do"burada yapılması gerekenleri izler (bu fordöngüde)" anlamına gelen bir anahtar kelimedir .

for f in *; do ...; done

aynıdır

for f in *
do
   ...
done

ve benzeri

for f in *; do
   ...
done

Üst üste kullanılmasının nedeni okunabilirlik ve yerel / kişisel tarz sözleşmeleridir.

Kişisel görüş:

Çok uzun olan döngü başlıklarında do, olduğu gibi yeni bir satır koymak mantıklı gelebilir .

for i in animals people houses thoughts basketballs bees
do
    ...
done

veya

for i in        \
    animals     \
    people      \
    houses      \
    thoughts    \
    basketballs \
    bees
do
    ...
done

Aynı thenbir ifaçıklama için de geçerli.

Ancak yine, bu kişinin kişisel stil tercihlerine veya bir takımın / projesinin kullandığı kodlama stiline bağlıdır.

Sayfanın üst kısmında ne yazdığını not edin:

bashate: bash scriptleri için pep8 eşdeğeri

PEP8 Python Kodu için Stil Kılavuzu. Python millet çoğu zaman stil sorunlarını çok ciddiye alıyor gibi görünmekle birlikte ^{[kaynak belirtilmeli]} , bu sadece bir rehber. Hem doçizgiyi aynı çizgiye koymak, hem forde kendi çizgisine koymak için başa çıkabildik .

{Bir ifveya whileblok (veya benzeri) başlatırken C kodunu nereye koyacağınızla aynı tartışma .

Belgelerde aşağıdaki birkaç satır, başka ilginç bir kural var:

E020: İşlev bildirimi biçiminde değil ^function name {$

Buradaki noktanın, bu stil rehberinin yazarının function, okuyucunun işlev bildirimini tanıması için anahtar kelimenin kullanılmasının gerekli olduğunu düşündüğü olduğunu farz ediyorum . Ancak, bir işlevi tanımlamanın standart olmayanfunction foo bir yoludur: standart yoldur . İkisi arasındaki tek fark (Bash cinsinden), diğerinin Debian veya Ubuntu'daki gibi standart bir kabuğa taşımayı zorlaştırmasıdır .foo()/bin/sh

Bu yüzden, bu tarz tarla kılavuzlarını bir ya da üç tane tuzla alıp kendinize en iyi tarzın ne olduğuna karar vermenizi öneririm. İyi bir stil denetleyicisi bazı çeklerin devre dışı bırakılmasına izin verir (bazhate bashate -i E010,E011bu iki çekimi göz ardı etmelidir .) Mükemmel bir stil denetleyici testleri burada, örneğin E020'nin tersini kontrol etmek için değiştirmenize izin verir.

TL; DR: Buna gerek yok. Bu sadece bir erkeğin görüşü.

Diğerleri forgibi onlarca yıldır böyle döngüler yazıyorum :

for F in arg1 arg2 arg*
do
    somecommand "$F"
done

Bu düzen do ... done, C benzeri dillerde kıvrık parantezler gibi döngü gövdesini çevreleyen gerçeğini vurgular ve yeni satırların döngü yapısının bileşenlerini ayırmasına izin verir.

Elbette, kıvrık kaşlı ayraçları da nereye yerleştireceğinizle ilgili dini savaşlar var, bu yüzden jürinin hala bunun dışında olduğunu söyleyebilirsin. IMHO, bu açıkça çalışmak için tasarlanmıştı; Bourne eşleşmiş sınırlayıcılara düşkündü, bkz. if ... fi, case ... esacve daha kısa sürümde bir noktalı virgül gereksinimi, onu orijinal tasarımdan daha kısa yaptığınızı ortaya koyuyor. Bunda yanlış bir şey yok; teknoloji gelişmeleri ve bir zamanlar iyi bir fikir gibi görünen pek çok şey şimdi kaşlarını çattı goto. Ancak tüm kabuk komut dosyası oluşturma topluluğu bashateyazarların tercihlerini kabul edene kadar bir şey yapmanıza gerek yoktur.

Henüz kimsenin bu geçerli ve taşınabilir sözdiziminden bahsetmediğine şaşırdım:

set alfa bravo charlie
for q do
  echo "$q"
done

Dikkatli bir şekilde dikkat edin forve donoktalı virgül olmadan aynı satırda. Sonuç:

alfa
bravo
charlie

Burada birkaç iyi cevap. Her zaman bir tuz taneleri ile stil rehberleri alın ve IMHO ile deneyim, stil konusunda aşırı dogmaya maruz kalan herhangi bir topluluk hakkında her zamankinden biraz orta derecede endişeli olun. Neredeyse son nokta attığım ve son T'yi geçtiğinde yazılımın işe yarayacağına inanıyor gibiydiler. Bazen böcekleri gidermek için mükemmel bir tarzdan daha fazlasını gerektirir ...

Kabuk öğrenmeye başladığımda, çoğu komut dosyası ve tutuş orada satır içi noktalı virgül biçimini kullandı

for i in "$@"; do
    stuff
done

ama deneyimsiz olduğum için, farkına varmakta zorlandım; ve - her ikisi de sözdizimsel doğruluğu onaylamak için gereklidir. Bu yüzden bir sonraki satırda tek başıma yapmayı tercih ettim. Bunu artık yapmıyorum (amaçlanan)

Ayrıca 'while' komutu küçük bir numara için mükemmel bir aday:

while prep1; prep2; condition; do
    stuff
done

ancak hazırlık komutları biraz hantal olduğunda ve / veya durum karmaşık olduğunda,

while
    prep1
    prep2
    condition
do
    stuff
done

ve ardından do 'yu'; 'do' 'olarak eklemek olumlu bir şekilde fugly.

Bundan daha da yoğunlaşabilirsiniz:

while
    if con1; then
      cond2
    elif cond3; then
      cond4
    elif cond5; then
      cond6
    else
      cond7
    fi
do
    stuff
done

çünkü her ifade bir ifadedir. Her iki stilin fırsatçı olarak nasıl kullanıldığına dikkat edin. Temiz tutun ve oldukça okunabilir. Stil veya "yerden tasarruf" adına sıkıştırın ya da çarpıtın ve korkunç bir karışıklık olur.

Yani! Genel olarak kabuk betiklerinin barok stilleri göz önüne alındığında, netliği ve anlamlı sembollere kolay görsel erişimi arttırmayı amaçlayan herhangi bir şey her zaman iyi bir şeydir.

'Do' komutunun satırına yazıldığı biçim, küçük bir komutunuz olduğunda tatlıdır - 'do' komutunu görsel olarak gizli bulmuyorum ya da iç komut gerçekten gizlenmiş değil:

for i in whatever
  do stuff
done

Bunu bakmak oldukça keyifli buluyorum ve süre, eğer ve durumla benzerleri var:

while condition
  do stuff
end

if condition
  then stuff1
  else stuff2
fi

case $blah in
  a) stuff1;;
  b) stuff2;;
  c) stuff3;;
  *) stuffInfinity;;
esac

Netlik ve genel düzen, Codd * 'in sizden istediği şeydir.

* Edgar F. Codd, ilişkisel veritabanı teorisinin babası.