Mengapa menulis seluruh skrip bash dalam fungsi?

Di tempat kerja, saya sering menulis skrip bash. Atasan saya menyarankan agar seluruh skrip dipecah menjadi fungsi, mirip dengan contoh berikut:

#!/bin/bash

# Configure variables
declare_variables() {
    noun=geese
    count=three
}

# Announce something
i_am_foo() {
    echo "I am foo"
    sleep 0.5
    echo "hear me roar!"
}

# Tell a joke
walk_into_bar() {
    echo "So these ${count} ${noun} walk into a bar..."
}

# Emulate a pendulum clock for a bit
do_baz() {
    for i in {1..6}; do
        expr $i % 2 >/dev/null && echo "tick" || echo "tock"
        sleep 1
    done
}

# Establish run order
main() {
    declare_variables
    i_am_foo
    walk_into_bar
    do_baz
}

main

Apakah ada alasan untuk melakukan hal ini selain "keterbacaan", yang saya pikir dapat juga dilakukan dengan beberapa komentar dan spasi baris?

Apakah ini membuat script berjalan lebih efisien (saya benar-benar mengharapkan yang sebaliknya, jika ada), atau apakah itu membuatnya lebih mudah untuk memodifikasi kode di luar potensi keterbacaan yang disebutkan sebelumnya? Atau itu benar-benar hanya preferensi gaya?

Harap perhatikan bahwa meskipun skrip tidak menunjukkannya dengan baik, "menjalankan urutan" fungsi dalam skrip aktual kami cenderung sangat linier - walk_into_bartergantung pada hal-hal yang i_am_footelah dilakukan, dan do_baztindakan pada hal-hal yang diatur oleh walk_into_bar- jadi dapat secara sewenang-wenang menukar run order bukanlah sesuatu yang biasanya kita lakukan. Misalnya, Anda tidak akan tiba-tiba ingin declare_variablesmengejarnya walk_into_bar, itu akan menghancurkan banyak hal.

Contoh bagaimana saya akan menulis skrip di atas adalah:

#!/bin/bash

# Configure variables
noun=geese
count=three

# Announce something
echo "I am foo"
sleep 0.5
echo "hear me roar!"

# Tell a joke
echo "So these ${count} ${noun} walk into a bar..."

# Emulate a pendulum clock for a bit
for i in {1..6}; do
    expr $i % 2 >/dev/null && echo "tick" || echo "tock"
    sleep 1
done

Saya sudah mulai menggunakan gaya pemrograman bash yang sama ini setelah membaca posting blog Kfir Lavi "Defensive Bash Programming" . Dia memberikan beberapa alasan bagus, tetapi secara pribadi saya menemukan ini yang paling penting:

• prosedur menjadi deskriptif: jauh lebih mudah untuk mengetahui bagian kode apa yang seharusnya dilakukan. Alih-alih dinding kode, Anda melihat "Oh, find_log_errorsfungsi membaca file log untuk kesalahan". Bandingkan dengan menemukan banyak baris awk / grep / sed yang menggunakan tuhan tahu apa jenis regex di tengah naskah panjang - Anda tidak tahu apa yang dilakukannya di sana kecuali ada komentar.

• Anda dapat men-debug fungsi dengan menyertakan ke set -xdan set +x. Setelah Anda mengetahui bahwa sisa kode berfungsi dengan baik, Anda dapat menggunakan trik ini untuk fokus pada debugging hanya fungsi spesifik itu. Tentu, Anda dapat melampirkan bagian skrip, tetapi bagaimana jika itu bagian yang panjang? Lebih mudah melakukan hal seperti ini:

   set -x
   parse_process_list
   set +x

• penggunaan pencetakan dengan cat <<- EOF . . . EOF. Saya telah menggunakannya beberapa kali untuk membuat kode saya jauh lebih profesional. Selain itu, parse_args()dengan getoptsfungsinya yang cukup nyaman. Sekali lagi, ini membantu keterbacaan, alih-alih memasukkan semuanya ke dalam skrip sebagai dinding teks raksasa. Juga nyaman untuk menggunakan kembali ini.

Dan jelas, ini jauh lebih mudah dibaca untuk seseorang yang tahu C atau Java, atau Vala, tetapi memiliki pengalaman bash yang terbatas. Sejauh efisiensi berjalan, tidak ada banyak yang dapat Anda lakukan - bash itu sendiri bukan bahasa yang paling efisien dan orang lebih suka perl dan python ketika datang ke kecepatan dan efisiensi. Namun, Anda dapat nicesuatu fungsi:

nice -10 resource_hungry_function

Dibandingkan dengan memanggil baik pada setiap baris kode, ini mengurangi banyak mengetik DAN dapat dengan mudah digunakan ketika Anda ingin hanya bagian dari skrip Anda berjalan dengan prioritas lebih rendah.

Menjalankan fungsi di latar belakang, menurut saya, juga membantu ketika Anda ingin memiliki banyak pernyataan untuk dijalankan di latar belakang.

Beberapa contoh di mana saya menggunakan gaya ini:

• https://askubuntu.com/a/758339/295286
• https://askubuntu.com/a/788654/295286
• https://github.com/SergKolo/sergrep/blob/master/chgreeterbg.sh

Keterbacaan adalah satu hal. Tetapi ada lebih banyak modularisasi daripada hanya ini. ( Semi-modularisasi mungkin lebih tepat untuk fungsi.)

Dalam fungsi Anda dapat menyimpan beberapa variabel lokal, yang meningkatkan keandalan , mengurangi kemungkinan hal-hal kacau.

Pro fungsi lainnya adalah kegunaan ulang . Setelah suatu fungsi dikodekan, itu dapat diterapkan beberapa kali dalam skrip. Anda juga dapat memindahkannya ke skrip lain.

Kode Anda sekarang mungkin linier, tetapi di masa depan Anda dapat memasukkan ranah multi-threading , atau multi-pemrosesan di dunia Bash. Setelah Anda belajar melakukan hal-hal dalam fungsi, Anda akan diperlengkapi dengan baik untuk melangkah ke paralel.

Satu hal lagi untuk ditambahkan. Sebagaimana Etsitpab Nioliv perhatikan dalam komentar di bawah, mudah untuk mengalihkan dari fungsi sebagai entitas yang koheren. Tetapi ada satu aspek lagi dari pengalihan dengan fungsi. Yaitu, pengalihan dapat diatur di sepanjang definisi fungsi. Misalnya.:

f () { echo something; } > log

Sekarang tidak diperlukan pengalihan secara eksplisit oleh pemanggilan fungsi.

$ f

Ini dapat menghemat banyak pengulangan, yang lagi-lagi meningkatkan keandalan dan membantu menjaga barang-barang tetap teratur.

Lihat juga

• https://unix.stackexchange.com/a/483304/181255

Dalam komentar saya, saya menyebutkan tiga keunggulan fungsi:

1. Mereka lebih mudah untuk menguji dan memverifikasi kebenaran.

2. Fungsi dapat dengan mudah digunakan kembali (bersumber) dalam skrip yang akan datang

3. Bos Anda menyukai mereka.

Dan, jangan pernah meremehkan pentingnya angka 3.

Saya ingin membahas satu masalah lagi:

... jadi bisa secara sewenang-wenang menukar run order bukanlah sesuatu yang biasanya kita lakukan. Misalnya, Anda tidak akan tiba-tiba ingin declare_variablesmengejarnya walk_into_bar, itu akan menghancurkan banyak hal.

Untuk mendapatkan manfaat dari memecah kode menjadi fungsi, seseorang harus mencoba untuk membuat fungsi sebebas mungkin. Jika walk_into_barmemerlukan variabel yang tidak digunakan di tempat lain, maka variabel tersebut harus didefinisikan dan dibuat lokal untuk walk_into_bar. Proses memisahkan kode menjadi fungsi dan meminimalkan saling ketergantungan mereka harus membuat kode lebih jelas dan sederhana.

Idealnya, fungsi harus mudah diuji secara individual. Jika, karena interaksi, mereka tidak mudah diuji, maka itu adalah tanda bahwa mereka mungkin mendapat manfaat dari refactoring.

Anda memecah kode menjadi fungsi untuk alasan yang sama Anda akan melakukannya untuk C / C ++, python, perl, ruby ​​atau kode bahasa pemrograman apa pun. Alasan yang lebih dalam adalah abstraksi - Anda merangkum tugas-tugas tingkat bawah menjadi primitif tingkat tinggi (fungsi) sehingga Anda tidak perlu repot tentang bagaimana hal-hal dilakukan. Pada saat yang sama, kode menjadi lebih mudah dibaca (dan dipelihara), dan logika program menjadi lebih jelas.

Namun, melihat kode Anda, saya merasa sangat aneh memiliki fungsi untuk mendeklarasikan variabel; ini benar-benar membuat saya menaikkan alis mata.

Sementara saya sepenuhnya setuju dengan usabilitas , keterbacaan , dan mencium bos dengan lembut tetapi ada satu keuntungan lain dari fungsi di bash : ruang lingkup variabel . Seperti yang ditunjukkan LDP :

#!/bin/bash
# ex62.sh: Global and local variables inside a function.

func ()
{
  local loc_var=23       # Declared as local variable.
  echo                   # Uses the 'local' builtin.
  echo "\"loc_var\" in function = $loc_var"
  global_var=999         # Not declared as local.
                         # Therefore, defaults to global. 
  echo "\"global_var\" in function = $global_var"
}  

func

# Now, to see if local variable "loc_var" exists outside the function.

echo
echo "\"loc_var\" outside function = $loc_var"
                                      # $loc_var outside function = 
                                      # No, $loc_var not visible globally.
echo "\"global_var\" outside function = $global_var"
                                      # $global_var outside function = 999
                                      # $global_var is visible globally.
echo                      

exit 0
#  In contrast to C, a Bash variable declared inside a function
#+ is local ONLY if declared as such.

Saya tidak sering melihat ini di skrip shell dunia nyata, tetapi sepertinya ide yang bagus untuk skrip yang lebih kompleks. Mengurangi kohesi membantu menghindari bug di mana Anda menghancurkan variabel yang diharapkan di bagian lain kode.

Dapat digunakan kembali sering kali berarti membuat perpustakaan umum fungsi dan sourcememasukkan perpustakaan itu ke semua skrip Anda. Ini tidak akan membantu mereka berlari lebih cepat, tetapi itu akan membantu Anda menulisnya lebih cepat.

Alasan yang sangat berbeda dari yang sudah diberikan dalam jawaban lain: satu alasan teknik ini kadang-kadang digunakan, di mana satu-satunya pernyataan non-fungsi-definisi di tingkat atas adalah panggilan untuk main, adalah untuk memastikan skrip tidak secara tidak sengaja melakukan sesuatu yang jahat jika skrip terpotong. Script dapat dipotong jika disalurkan dari proses A ke proses B (shell), dan proses A berakhir karena alasan apa pun sebelum selesai menulis keseluruhan skrip. Ini sangat mungkin terjadi jika proses A mengambil skrip dari sumber daya jarak jauh. Sementara untuk alasan keamanan itu bukan ide yang baik, itu adalah sesuatu yang dilakukan, dan beberapa skrip telah dimodifikasi untuk mengantisipasi masalah.

Suatu proses membutuhkan urutan. Sebagian besar tugas berurutan. Tidak masuk akal untuk mengacaukan pesanan.

Tetapi hal super besar tentang pemrograman - yang termasuk scripting - adalah pengujian. Pengujian, pengujian, pengujian. Skrip tes apa yang saat ini Anda miliki untuk memvalidasi kebenaran skrip Anda?

Bos Anda mencoba memandu Anda dari menjadi script kiddy menjadi programmer. Ini adalah arah yang baik untuk masuk. Orang-orang yang datang setelah Anda akan menyukai Anda.

TAPI. Ingatlah selalu akar proses Anda. Jika masuk akal untuk memiliki fungsi yang dipesan dalam urutan di mana mereka biasanya dieksekusi, maka lakukan itu, setidaknya sebagai pass pertama.

Kemudian, Anda akan melihat bahwa beberapa fungsi Anda menangani input, yang lain output, yang lain memproses, yang lain memodelkan data, dan yang lain memanipulasi data, sehingga mungkin pintar untuk mengelompokkan metode yang serupa, mungkin bahkan memindahkannya ke file yang terpisah. .

Kemudian, Anda mungkin menyadari bahwa sekarang Anda telah menulis perpustakaan fungsi pembantu kecil yang Anda gunakan di banyak skrip Anda.

Komentar dan spasi tidak dapat mendekati keterbacaan yang berfungsi, seperti yang akan saya tunjukkan. Tanpa fungsi, Anda tidak dapat melihat hutan untuk pepohonan - masalah besar bersembunyi di antara banyak garis detail. Dengan kata lain, orang tidak bisa secara bersamaan fokus pada detail halus dan gambaran besar. Itu mungkin tidak jelas dalam naskah pendek; selama masih pendek mungkin cukup mudah dibaca. Namun, perangkat lunak menjadi lebih besar, tidak lebih kecil, dan tentu saja itu bagian dari keseluruhan sistem perangkat lunak perusahaan Anda, yang tentunya jauh lebih besar, mungkin jutaan baris.

Pertimbangkan jika saya memberi Anda petunjuk seperti ini:

Place your hands on your desk.
Tense your arm muscles.
Extend your knee and hip joints.
Relax your arms.
Move your arms backwards.
Move your left leg backwards.
Move your right leg backwards.
(continue for 10,000 more lines)

Pada saat Anda setengah jalan, atau bahkan 5% melalui, Anda akan lupa apa beberapa langkah pertama itu. Anda tidak mungkin menemukan sebagian besar masalah, karena Anda tidak dapat melihat hutan untuk pepohonan. Bandingkan dengan fungsi:

stand_up();
walk_to(break_room);
pour(coffee);
walk_to(office);

Itu tentu jauh lebih dimengerti, tidak peduli berapa banyak komentar yang Anda masukkan ke dalam versi berurutan baris demi baris. Ini juga membuatnya jauh lebih mungkin Anda akan melihat bahwa Anda lupa membuat kopi, dan mungkin lupa sit_down () di akhir. Ketika pikiran Anda memikirkan perincian grep dan awk regexes, Anda tidak dapat memikirkan gambaran besar - "bagaimana jika tidak ada kopi yang dibuat"?

Fungsi utamanya memungkinkan Anda melihat gambaran besar, dan memerhatikan bahwa Anda lupa membuat kopi (atau seseorang mungkin lebih suka teh). Di lain waktu, dalam kerangka berpikir yang berbeda, Anda khawatir tentang implementasi terperinci.

Ada juga manfaat lain yang dibahas dalam jawaban lain, tentu saja. Manfaat lain yang tidak secara jelas dinyatakan dalam jawaban lain adalah bahwa fungsi memberikan jaminan yang penting dalam mencegah dan memperbaiki bug. Jika Anda menemukan bahwa beberapa variabel $ foo dalam fungsi walk_to () yang salah salah, Anda tahu bahwa Anda hanya perlu melihat 6 baris lainnya dari fungsi itu untuk menemukan segala sesuatu yang dapat dipengaruhi oleh masalah itu, dan segala sesuatu yang bisa telah menyebabkannya salah. Tanpa fungsi (tepat), apa pun dan segala sesuatu di seluruh sistem mungkin menjadi penyebab $ foo salah, dan apa pun dan segala sesuatu mungkin dipengaruhi oleh $ foo. Karenanya Anda tidak dapat memperbaiki $ foo dengan aman tanpa memeriksa ulang setiap baris program. Jika $ foo bersifat lokal untuk suatu fungsi,

Beberapa kebenaran yang relevan tentang pemrograman:

• Program Anda akan berubah, bahkan jika bos Anda bersikeras ini bukan masalahnya.
• Hanya kode dan input yang memengaruhi perilaku program.
• Penamaan itu sulit.

Komentar dimulai sebagai penghenti karena tidak dapat mengekspresikan ide Anda dengan jelas dalam kode *, dan menjadi lebih buruk (atau hanya salah) dengan perubahan. Karena itu, jika memungkinkan, ungkapkan konsep, struktur, alasan, semantik, aliran, penanganan kesalahan, dan hal lain yang berkaitan dengan pemahaman kode sebagai kode.

Yang mengatakan, fungsi Bash memiliki beberapa masalah yang tidak ditemukan di sebagian besar bahasa:

• Namespacing mengerikan di Bash. Misalnya, lupa menggunakan localhasil kata kunci dalam mencemari namespace global.
• Menggunakan local foo="$(bar)"hasil dalam kehilangan kode keluar daribar .
• Tidak ada parameter bernama, jadi Anda harus ingat apa "$@"artinya dalam konteks yang berbeda.

* Maaf jika ini menyinggung, tetapi setelah menggunakan komentar selama beberapa tahun dan berkembang tanpa mereka ** selama bertahun-tahun cukup jelas mana yang lebih unggul.

** Menggunakan komentar untuk lisensi, dokumentasi API dan sejenisnya masih diperlukan.

Waktu adalah uang

Ada jawaban bagus lainnya yang menyebarkan alasan teknis untuk menulis skrip modular , berpotensi panjang, dikembangkan di lingkungan kerja, dikembangkan untuk digunakan oleh sekelompok orang dan tidak hanya untuk penggunaan Anda sendiri.

Saya ingin fokus pada satu harapan: dalam lingkungan kerja "waktu adalah uang" . Jadi tidak adanya bug dan kinerja kode Anda dievaluasi bersama dengan readibility , testability, rawatan, refactorability, reusability ...

Menulis dalam "modul" kode akan mengurangi waktu membaca yang dibutuhkan tidak hanya oleh koder itu sendiri, tetapi bahkan waktu yang digunakan oleh penguji atau oleh bos. Selain itu perhatikan bahwa waktu seorang bos biasanya dibayar lebih dari waktu seorang pembuat kode dan bahwa bos Anda akan mengevaluasi kualitas pekerjaan Anda.

Selanjutnya menulis dalam "modul" kode independen (bahkan skrip bash) akan memungkinkan Anda untuk bekerja secara "paralel" dengan komponen lain dari tim Anda yang memperpendek waktu produksi keseluruhan dan menggunakan keahlian terbaik single, untuk meninjau atau menulis ulang bagian dengan tidak ada efek samping pada yang lain, untuk mendaur ulang kode yang baru saja Anda tulis "apa adanya"untuk program / skrip lain, untuk membuat pustaka (atau pustaka snippet), untuk mengurangi ukuran keseluruhan dan kemungkinan kesalahan yang terkait, untuk men-debug dan menguji secara menyeluruh setiap bagian tunggal ... dan tentu saja akan diatur dalam bagian logis program Anda / skrip dan tingkatkan keterbacaannya. Semua hal yang akan menghemat waktu dan uang. Kekurangannya adalah Anda harus tetap berpegang pada standar dan mengomentari fungsi Anda (yang harus Anda lakukan di lingkungan kerja).

Mematuhi standar akan memperlambat pekerjaan Anda di awal tetapi akan mempercepat pekerjaan semua yang lain (dan Anda juga) sesudahnya. Memang ketika kolaborasi tumbuh dalam jumlah orang yang terlibat ini menjadi kebutuhan yang tidak dapat dihindari. Jadi, misalnya, bahkan jika saya percaya bahwa variabel global harus didefinisikan secara global dan tidak dalam suatu fungsi, saya dapat memahami suatu standar yang mem-inisialisasi mereka dalam suatu fungsi yang dinamakan declare_variables()selalu di baris pertama main()...

Last but not least, jangan meremehkan kemungkinan dalam editor kode sumber modern untuk menunjukkan atau menyembunyikan rutinitas terpisah secara selektif ( Lipat kode ). Ini akan menjaga kode kompak dan memfokuskan pengguna menghemat waktu lagi.

^{Di sini di atas Anda dapat melihat bagaimana itu hanya membukawalk_into_bar() fungsi. Bahkan yang lainnya masing-masing terdiri dari 1000 baris, Anda masih dapat mengontrol semua kode dalam satu halaman. Catatan itu dilipat bahkan bagian mana Anda pergi untuk mendeklarasikan / menginisialisasi variabel.}

Selain alasan yang diberikan dalam jawaban lain:

9. Psikologi: Seorang programmer yang produktivitasnya sedang diukur dalam baris kode akan memiliki insentif untuk menulis kode verbose yang tidak perlu. Semakin banyak manajemen berfokus pada garis kode, semakin banyak insentif yang harus diprogram programmer untuk memperluas kodenya dengan kompleksitas yang tidak dibutuhkan. Ini tidak diinginkan karena peningkatan kompleksitas dapat menyebabkan peningkatan biaya pemeliharaan dan peningkatan upaya yang diperlukan untuk memperbaiki bug.
   • WP, Sumber Baris Kode; Kekurangan, # 9

Alasan lain yang sering diabaikan adalah sintaks bash:

set -eu

echo "this shouldn't run"
{
echo "this shouldn't run either"

Script ini jelas mengandung kesalahan sintaks dan bash seharusnya tidak menjalankannya sama sekali, kan? Salah.

~ $ bash t1.sh
this shouldn't run
t1.sh: line 7: syntax error: unexpected end of file

Jika kami membungkus kode dalam suatu fungsi, ini tidak akan terjadi:

set -eu

main() {
  echo "this shouldn't run"
  {
  echo "this shouldn't run either"
}

main

~ $ bash t1.sh
t1.sh: line 10: syntax error: unexpected end of file