1. Ringkasan
Saya tidak mengerti, mengapa saya perlu aturan bashate E010 .
2. Detail
Saya menggunakan bashate untuk .sh
file linting . Aturan E010:
jangan di baris yang sama seperti untuk
for
bashate:
Benar:
#!/bin/bash for f in bash/*.sh; do sashacommand "$f" done
Kesalahan:
#!/bin/bash for f in bash/*.sh do sashacommand "$f" done
Apakah ada argumen yang valid, mengapa saya perlu for
dan do
di baris yang sama?
3. Tidak berguna
Saya tidak dapat menemukan jawaban untuk pertanyaan saya di:
- Artikel tentang praktik pengkodean terbaik ( contoh )
dokumentasi bashate . Saya hanya menemukan:
Seperangkat aturan yang membantu menjaga hal-hal konsisten di blok kontrol. Ini diabaikan pada garis panjang yang memiliki kelanjutan, karena membuka gulungan yang agak "menarik"
bash
shell-script
Саша Черных
sumber
sumber
do
jelas agak tidak biasa, tetapifor ... \ndo\n<indent>body...
sangat umum dan saya bahkan memperkirakan lebih dari itufor ... ; do
. Apakah itu juga mengeluh tentang itu?bashate
adalah pemeriksa gaya . Gaya secara inheren bersifat subyektif. Jangan menggunakannya jika Anda tidak menyukai gaya artibrary yang diterapkannya. Anda sebaiknya mempertimbangkan pemeriksa sintaks / bug seperti shellcheck .E010
- hanya gaya aturan atau dalam beberapa kasus saya perlu untuk dan lakukan di baris yang sama tidak hanya oleh alasan gaya.do
. Ini seperti indentasi penjepit pembukaanif
dan menambahkan kode pada baris yang sama dalam bahasa seperti C. Contoh lain, jika python mengijinkannya, akan menempatkan:
sebuahif
menjorok pada baris berikutnya dan menambahkan kode pada baris yang sama. Ini akan membuatnya berbeda dengan garis tambahan di dalam tubuh.Jawaban:
Secara sintaksis, dua cuplikan kode berikut ini benar dan setara:
Yang terakhir mungkin bisa dikatakan lebih sulit untuk dibaca karena
do
sedikit mengaburkan perintah dalam tubuh loop. Jika loop berisi banyak perintah dan perintah berikutnya ada di baris baru, kebingungan akan lebih disorot:... tetapi untuk menandainya sebagai "kesalahan" adalah pendapat pribadi seseorang IMHO daripada kebenaran obyektif.
Secara umum, hampir semua
;
dapat digantikan oleh baris baru. Keduanya;
dan baris baru adalah terminator perintah.do
adalah kata kunci yang berarti "di sini mengikuti apa yang perlu dilakukan (dalamfor
loop ini )".sama dengan
dan sebagai
Alasan untuk menggunakan satu sama lain adalah keterbacaan dan konvensi gaya lokal / pribadi.
Opini pribadi:
Dalam header loop yang sangat panjang , saya pikir mungkin masuk akal untuk meletakkan
do
baris baru, seperti padaatau
Hal yang sama berlaku untuk
then
dalamif
pernyataan.Tetapi sekali lagi, ini tergantung pada preferensi gaya pribadi seseorang, atau untuk gaya pengkodean apa pun yang digunakan tim / proyek seseorang.
sumber
do
, saya tidak melihat alasan mengapa meletakkannya di baris berikutnya akan membantu keterbacaan.do
(atauthen
) pada baris sendiri (seperti pada contoh kedua ke terakhir). Ini semua harus dengan preferensi pribadi. Saya tidak suka garis yang terlalu panjang, sebagian karena terminal saya "hanya" 80 karakter lebar, dan sebagian karena saya pikir itu terlihat berantakan. Saya juga merasa sulit untuk menguraikan garis yang sangat panjang untuk kesalahan.do
pada baris terpisah merupakan "kesalahan". Mereka agak frase yang ketat, sehingga tidak tampak layak untuk menunjukkan bahwa, cukup sebaliknya, yang disebut "aturan" sebenarnya hanya opini subjektif.Perhatikan apa yang tertulis di bagian atas halaman:
PEP8 adalah Panduan Gaya untuk Kode Python. Sementara Python orang sering tampaknya mengambil isu-isu gaya mereka sangat serius [rujukan?] , Hanya saja, pemandu. Kita bisa membuat sisi negatif untuk menempatkan keduanya
do
di baris yang sama denganfor
, dan untuk menempatkannya pada barisnya sendiri.Ini adalah diskusi yang sama dengan tempat memasukkan
{
kode C saat memulaiif
atauwhile
memblokir (atau semacamnya).Beberapa baris di bawah ini dalam dokumentasi, ada aturan lain yang menarik:
Saya berasumsi intinya di sini adalah bahwa penulis panduan gaya berpikir bahwa menggunakan
function
kata kunci diperlukan bagi pembaca untuk mengenali deklarasi fungsi. Namun,function foo
cara non-standar untuk mendefinisikan suatu fungsi: cara standar adalahfoo()
. Satu-satunya perbedaan antara keduanya (dalam Bash) adalah bahwa yang lain lebih sulit untuk port ke shell standar, seperti/bin/sh
di Debian atau Ubuntu.Jadi, saya akan menyarankan mengambil setiap dan semua panduan gaya tersebut dengan sebutir garam atau tiga, dan memutuskan untuk diri sendiri apa gaya terbaik. Pemeriksa gaya yang baik memungkinkan penonaktifan beberapa cek (bashate harus
bashate -i E010,E011
mengabaikan kedua pemeriksaan itu.) Pemeriksa gaya yang hebat akan memungkinkan Anda untuk memodifikasi tes, misalnya untuk memeriksa kebalikan dari E020, di sini.sumber
TL; DR: Anda tidak perlu. Itu hanya pendapat beberapa pria.
Seperti banyak orang lain, saya telah menulis
for
loop seperti ini selama beberapa dekade:Layout ini menyoroti fakta yang
do ... done
mengelilingi tubuh loop, seperti kurung kurawal dalam bahasa mirip-C, dan memungkinkan baris baru untuk memisahkan komponen konstruksi loop.Tentu saja ada perang agama tentang di mana menempatkan kurung kurawal juga, jadi Anda bisa mengatakan juri masih keluar tentang yang satu ini. IMHO, ini jelas bagaimana ini dirancang untuk bekerja; Bourne menyukai pembatas yang cocok, lih.
if ... fi
,,case ... esac
dan perlunya titik koma di versi yang lebih pendek mengungkapkan bahwa Anda membuatnya lebih pendek dari yang dirancang semula. Tidak ada yang salah dengan itu; kemajuan teknologi dan banyak hal yang dulu tampak seperti ide bagus sekarang disukai, sepertigoto
. Tetapi sampai seluruh komunitas skrip shell mengadopsi preferensibashate
penulis, Anda tidak perlu melakukan apa pun.sumber
fi
sesuai denganif
, danesac
lain - lain berasal dari Algol 68. Satu-satunya alasanfor
loopdo
tidak diakhiriod
adalah karenaod
itulah nama utilitas standar yang ada. Lihat en.wikipedia.org/wiki/ALGOL_68C#Algol_68C_and_Unixbegin ... end
dll.).od
, itu lucu ... (Meskipun, mengapa tidak hanya berakhir denganrof
, ya?)BEGIN
danEND
didefinisikan di sana juga.FOR
danDO
juga akan berada di jalur yang terpisah, dengan konvensi, kecuali ketika seluruh loop dengan mudah akan muat pada satu baris.Saya terkejut belum ada yang menyebutkan sintaks yang valid dan portabel ini:
Perhatikan baik-baik itu
for
dando
berada di jalur yang sama, tanpa titik koma. Hasil:sumber
for q
dando
berada pada baris yang terpisah (formulir dalam contoh ini tidak didukung beberapa dekade yang lalu pada shell Almquish asli (ash
): in-ulm.de/ ~mascheck / various/ bourne_args / # endnote )Beberapa jawaban bagus di sini. Selalu ambil panduan gaya dengan sebutir garam, dan IMHO dan pengalaman, menjadi sangat-sedikit-untuk-sedang khawatir tentang setiap komunitas yang penuh dengan dogma berlebihan ketika datang ke gaya. Ini hampir seperti mereka percaya bahwa ketika mereka AKHIRNYA mendapatkan yang terakhir saya putus-putus, dan yang terakhir terlewati, maka perangkat lunak akan bekerja. Terkadang dibutuhkan lebih dari gaya yang sempurna untuk menghapus bug ...
Ketika saya mulai belajar shell, sebagian besar skrip dan tute di luar sana menggunakan format titik koma in-line
tetapi karena saya tidak berpengalaman, saya agak kesulitan menemukan; dan do - keduanya penting untuk mengkonfirmasi kebenaran sintaksis. Jadi saya lebih suka lakukan pada baris berikutnya dengan sendirinya. Saya tidak lagi melakukan itu (pun intended)
Selanjutnya, perintah 'while' adalah kandidat yang sangat baik untuk trik kecil yang menyenangkan:
tetapi ketika perintah prep agak besar, dan / atau kondisinya kompleks, lebih baik diformat sebagai
dan kemudian menambahkan do sebagai "; do" positif.
Anda bahkan bisa lebih intens dari itu:
karena setiap pernyataan adalah ekspresi. Perhatikan bagaimana kedua gaya digunakan secara oportunistik. Tetap bersih dan cukup mudah dibaca. Memadatkan atau membelokkannya atas nama gaya atau "menghemat ruang" dan itu menjadi berantakan.
Begitu! Mengingat stylings skrip shell yang agak barok pada umumnya, segala sesuatu yang bertujuan meningkatkan kejelasan dan akses visual yang mudah ke simbol-simbol penting selalu merupakan hal yang baik.
Bentuk di mana 'do' ditulis sesuai dengan perintah itu manis ketika Anda memiliki sedikit perintah - Saya tidak menemukan 'do' disembunyikan secara visual, juga tidak ada perintah batin yang benar-benar dikaburkan:
Saya menemukan itu cukup menyenangkan untuk dilihat, dan memiliki analog dengan while, if dan case:
Kejelasan dan kerapian umum adalah semua yang diminta Codd dari Anda.
* Edgar F. Codd, bapak teori database relasional.
sumber
while
denganif
kondisi sebelumnya. Keren!