Kode Bersih: Fungsi dengan beberapa parameter [ditutup]

Saya membaca bab-bab pertama dari Clean Code oleh Robert C. Martin, dan menurut saya itu cukup bagus, tetapi saya ragu, di satu bagian disebutkan bahwa itu baik (secara kognitif) bahwa fungsi-fungsinya harus memiliki beberapa parameter. mungkin, bahkan menunjukkan bahwa 3 atau lebih parameter terlalu banyak untuk suatu fungsi (yang saya temukan sangat berlebihan dan idealis), jadi saya mulai bertanya-tanya ...

Kedua praktik menggunakan variabel global dan melewati banyak argumen pada fungsi akan menjadi praktik pemrograman yang buruk, tetapi penggunaan variabel global dapat sangat mengurangi jumlah parameter dalam fungsi ...

Jadi saya ingin mendengar pendapat Anda tentang itu, apakah ada baiknya menggunakan variabel global untuk mengurangi jumlah parameter fungsi atau tidak? Dalam kasus apa jadinya?

Apa yang saya pikirkan adalah bahwa itu tergantung pada beberapa faktor:

• Ukuran kode sumber.
• Jumlah parameter dalam rata-rata fungsi.
• Jumlah fungsi.
• Frekuensi di mana variabel yang sama digunakan.

Menurut pendapat saya jika ukuran kode sumber relatif kecil (seperti kurang dari 600 baris kode), ada banyak fungsi, variabel yang sama dilewatkan sebagai parameter dan fungsi memiliki banyak parameter, maka menggunakan variabel global akan bernilai, tetapi saya ingin tahu...

• Apakah Anda membagikan pendapat saya?
• Bagaimana menurut Anda tentang kasus-kasus lain di mana kode sumber lebih besar, dll?

PS . Saya melihat posting ini , judulnya sangat mirip, tetapi dia tidak bertanya apa yang ingin saya ketahui.

Saya tidak membagikan pendapat Anda. Menurut pendapat saya menggunakan variabel global adalah praktik yang lebih buruk daripada lebih banyak parameter terlepas dari kualitas yang Anda jelaskan. Alasan saya adalah bahwa lebih banyak parameter dapat membuat metode lebih sulit untuk dipahami, tetapi variabel global dapat menyebabkan banyak masalah untuk kode termasuk testability yang buruk, bug konkurensi, dan kopling ketat. Tidak peduli berapa banyak parameter yang dimiliki fungsi, ia tidak akan memiliki masalah yang sama seperti variabel global.

... variabel yang sama dilewatkan sebagai parameter

Ini mungkin menjadi bau desain. Jika Anda memiliki parameter yang sama yang diteruskan ke sebagian besar fungsi di sistem Anda, mungkin ada masalah lintas sektoral yang harus ditangani dengan memperkenalkan komponen baru. Saya tidak berpikir meneruskan variabel yang sama ke banyak fungsi menjadi alasan yang masuk akal untuk memperkenalkan variabel global.

Dalam satu pengeditan pertanyaan Anda, Anda mengindikasikan bahwa memperkenalkan variabel global dapat meningkatkan keterbacaan kode. Saya tidak setuju. Penggunaan variabel global disembunyikan dalam kode implementasi sedangkan parameter fungsi dinyatakan dalam tanda tangan. Fungsi idealnya harus murni. Mereka seharusnya hanya beroperasi pada parameter mereka dan tidak boleh memiliki efek samping. Jika Anda memiliki fungsi murni, Anda dapat mempertimbangkan fungsi hanya dengan melihat satu fungsi. Jika fungsi Anda tidak murni, Anda harus mempertimbangkan keadaan komponen lain, dan itu menjadi jauh lebih sulit untuk dipikirkan.

Anda harus menghindari variabel global seperti wabah .

Saya tidak akan meletakkan batas keras untuk jumlah argumen (seperti 3 atau 4), tetapi Anda jangan ingin menjaga mereka untuk minimum, jika memungkinkan.

Gunakan structs (atau objek dalam C ++) untuk mengelompokkan variabel-variabel menjadi satu kesatuan dan meneruskannya (dengan referensi) ke fungsi. Biasanya suatu fungsi mendapat struktur atau objek (dengan beberapa hal berbeda di dalamnya) diteruskan ke sana bersama dengan beberapa parameter lain yang memberi tahu fungsi untuk melakukan sesuatu pada struct.

Untuk kode modular yang beraroma harum, bersih, cobalah untuk tetap berpegang pada prinsip tanggung jawab tunggal . Lakukan itu dengan struct Anda (atau objek), fungsi, dan file sumber. Jika Anda melakukan itu, jumlah parameter alami yang diteruskan ke suatu fungsi akan menjadi jelas.

Kita berbicara tentang beban kognitif, bukan sintaksis. Jadi pertanyaannya adalah ... Apa adalah parameter dalam konteks ini?

Parameter adalah nilai yang mempengaruhi perilaku fungsi. Semakin banyak parameter, semakin banyak kemungkinan kombinasi nilai yang Anda dapatkan, semakin sulit penalaran tentang fungsi tersebut.

Dalam pengertian itu, variabel global yang digunakan fungsi adalah parameter. Mereka adalah parameter yang tidak muncul dalam tanda tangannya, yang memiliki masalah susunan konstruksi, kontrol akses, dan remanensi.

Kecuali jika parameter tersebut adalah apa yang disebut kekhawatiran lintas sektoral , yaitu beberapa kondisi seluruh program yang semuanya gunakan tetapi tidak ada yang berubah (misalnya objek logging), Anda tidak boleh mengganti parameter fungsi dengan variabel global. Mereka masih menjadi parameter, tetapi lebih buruk.

IMHO pertanyaan Anda didasarkan pada kesalahpahaman. Dalam "Kode Bersih", Bob Martin tidak menyarankan untuk mengganti parameter fungsi berulang oleh global, itu akan menjadi saran yang sangat mengerikan. Dia menyarankan untuk menggantinya dengan variabel anggota pribadi dari kelas fungsi. Dan dia juga mengusulkan kelas yang kecil dan kohesif (biasanya lebih kecil dari 600 baris kode yang Anda sebutkan), jadi variabel anggota ini jelas bukan global.

Jadi, ketika Anda memiliki pendapat dalam konteks dengan kurang dari 600 baris "menggunakan variabel global akan sia-sia" , maka Anda dengan sempurna membagikan pendapat Paman Bob. Tentu saja, masih bisa diperdebatkan jika "3 parameter pada maksimum" adalah angka ideal, dan jika aturan ini kadang-kadang menyebabkan terlalu banyak variabel anggota bahkan dalam kelas kecil. IMHO ini adalah trade-off, tidak ada aturan keras dan cepat di mana harus menarik garis.

Memiliki banyak parameter dianggap tidak diinginkan, tetapi mengubahnya menjadi bidang atau variabel global jauh lebih buruk karena tidak menyelesaikan masalah aktual tetapi menimbulkan masalah baru.

Memiliki banyak parameter tidak dengan sendirinya masalah, tetapi merupakan gejala bahwa Anda mungkin memiliki masalah. Pertimbangkan metode ini:

Graphics.PaintRectangle(left, top, length, height, red, green, blue, transparency);

Memiliki 7 parameter adalah tanda peringatan yang pasti. Masalah yang mendasarinya adalah parameter-parameter ini tidak independen tetapi termasuk dalam kelompok. leftdan topmilik bersama sebagai Position-struktur, lengthdan heightsebagai Sizestruktur, dan red, bluedan greensebagai Colorstruktur. Dan mungkin Colordan transparansi termasuk dalam Brushstruktur? Mungkin Positiondan Sizedimiliki bersama dalam suatu Rectanglestruktur, dalam hal mana kita bahkan dapat mempertimbangkan untuk mengubahnya menjadi Paintmetode pada Rectangleobjek? Jadi kita mungkin berakhir dengan:

Rectangle.Paint(brush);

Misi selesai! Tetapi yang penting adalah kita sebenarnya telah memperbaiki desain secara keseluruhan, dan pengurangan jumlah parameter adalah konsekuensi dari ini. Jika kami hanya mengurangi jumlah parameter tanpa menangani masalah mendasar, kami mungkin melakukan sesuatu seperti ini:

Graphics.left = something;
Graphics.top = something;
Graphics.length = something;
...etc
Graphics.PaintRectangle();

Di sini kami telah mencapai pengurangan yang sama dalam jumlah parameter, tetapi kami sebenarnya telah memperburuk desain .

Intinya: Untuk saran dan aturan pemrograman apa pun, sangat penting untuk memahami alasan yang mendasarinya.

apakah layak menggunakan variabel global untuk mengurangi jumlah parameter fungsi atau tidak?

Tidak

Saya membaca bab-bab pertama buku ini

Apakah Anda membaca sisa buku ini?

Global hanyalah parameter tersembunyi. Mereka menyebabkan rasa sakit yang berbeda. Tapi masih sakit. Berhentilah memikirkan cara untuk menyiasati aturan ini. Pikirkan bagaimana cara mengikutinya.

Apa itu parameter?

Itu barang. Dalam kotak berlabel baik. Mengapa penting berapa banyak kotak yang Anda miliki ketika Anda bisa memasukkan barang apa pun di dalamnya?

Ini adalah biaya pengiriman dan penanganan.

Move(1, 2, 3, 4)

Katakan padaku kamu bisa membacanya. Ayo, coba.

Move(PointA, PointB)

Itu sebabnya.

Trik itu disebut memperkenalkan parameter objek .

Dan ya itu hanya tipuan jika yang Anda lakukan hanyalah menghitung parameter. Yang harus Anda hitung adalah IDEAS! Abstraksi! Berapa banyak yang membuat saya berpikir sekaligus? Tetap sederhana.

Sekarang ini jumlah yang sama:

Move(xyx, y)

OW! Mengerikan! Apa yang salah di sini?

Tidak cukup membatasi jumlah ide. Itu harus ide yang jelas. Apa itu xyx?

Sekarang ini masih lemah. Apa cara yang lebih kuat untuk memikirkan hal ini?

Fungsinya harus kecil. Tidak lebih kecil dari itu.

Paman Bob

Move(PointB)

Mengapa membuat fungsi melakukan lebih dari yang sebenarnya perlu dilakukan? Prinsip tanggung jawab tunggal tidak hanya untuk kelas. Serius, ada baiknya mengubah seluruh arsitektur hanya untuk menghentikan satu fungsi dari berubah menjadi mimpi buruk yang berlebihan dengan 10 parameter terkait terkadang beberapa di antaranya tidak dapat digunakan dengan yang lain.

Saya telah melihat kode di mana jumlah baris paling umum dalam suatu fungsi adalah 1. Serius. Saya tidak mengatakan Anda harus menulis seperti itu tetapi sheesh, jangan bilang global adalah HANYA cara Anda dapat mematuhi aturan ini. Berhentilah mencoba keluar dari refactoring fungsi itu dengan benar. Kamu tahu kamu bisa. Mungkin terpecah menjadi beberapa fungsi. Ini mungkin benar-benar berubah menjadi beberapa objek. Sial, Anda bahkan dapat memecah sebagiannya menjadi aplikasi yang sama sekali berbeda.

Buku ini tidak memberitahu Anda untuk menghitung parameter Anda. Ia memberi tahu Anda untuk memperhatikan rasa sakit yang Anda sebabkan. Apa pun yang memperbaiki rasa sakit akan memperbaiki masalahnya. Berhati-hatilah saat Anda hanya memperdagangkan satu rasa sakit untuk yang lain.

Saya tidak akan pernah menggunakan variabel global untuk mengurangi parameter. Alasannya adalah bahwa variabel global dapat diubah oleh fungsi / perintah apa pun, oleh karena itu membuat input fungsi tidak dapat diandalkan dan rentan terhadap nilai yang berada di luar ruang lingkup yang dapat ditangani oleh fungsi tersebut. Bagaimana jika variabel diubah selama eksekusi fungsi dan separuh fungsi memiliki nilai yang berbeda dari setengah lainnya?

Melewati parameter di sisi lain, membatasi ruang lingkup variabel hanya untuk fungsinya sendiri sehingga hanya fungsi yang dapat mengubah parameter setelah dipanggil.

Jika Anda perlu meneruskan variabel global alih-alih parameter, lebih baik untuk mendesain ulang kode.

Hanya dua sen saya.

Saya dengan Paman Bob dalam hal ini dan setuju bahwa lebih dari 3 params adalah sesuatu yang harus dihindari (saya sangat jarang menggunakan lebih dari 3 params dalam suatu fungsi). Memiliki banyak params pada satu fungsi menciptakan masalah pemeliharaan yang lebih besar dan mungkin bau bahwa fungsi Anda melakukan terlalu banyak / memiliki tanggung jawab terlalu banyak.

Jika Anda menggunakan lebih dari 3 dalam suatu metode dalam bahasa OO maka Anda harus mempertimbangkan apakah params tidak terkait satu sama lain dalam beberapa cara dan karena itu Anda harus benar-benar melewati sebuah objek saja?

Juga, jika Anda membuat lebih banyak fungsi (lebih kecil) Anda juga akan melihat bahwa fungsi cenderung lebih sering memiliki 3 params atau kurang. Ekstrak fungsi / metode adalah teman Anda :-).

Jangan gunakan variabel global sebagai cara untuk mendapatkan lebih banyak params! Itu adalah menukar satu praktik buruk dengan yang lebih buruk!

Alternatif yang valid untuk banyak parameter fungsi adalah dengan memperkenalkan objek parameter . Ini berguna jika Anda memiliki metode yang terdiri yang melewati (hampir) semua parameternya ke sekelompok metode lain.

Dalam kasus sederhana ini adalah DTO sederhana yang tidak memiliki apa pun kecuali parameter lama sebagai properti.

Menggunakan variabel global sepertinya selalu merupakan cara yang mudah untuk kode (terutama dalam program kecil), tetapi itu akan membuat kode Anda sulit diperluas.

Ya, Anda bisa mengurangi jumlah parameter dalam suatu fungsi dengan menggunakan array untuk mengikat parameter dalam satu entitas.

function <functionname>(var1,var2,var3,var4.....var(n)){}

Fungsi di atas akan diedit dan diubah menjadi [menggunakan array asosiatif] -

data=array(var1->var1,
           var2->var2
           var3->var3..
           .....
           ); // data is an associative array

function <functionname>(data)

Saya setuju dengan jawaban robert bristow-johnson : Anda bahkan dapat menggunakan struct untuk mengikat data dalam satu entitas.

Mengambil contoh dari PHP 4, lihat tanda tangan fungsi untuk mktime():

• int mktime ([ int $hour = date("H") [, int $minute = date("i") [, int $second = date("s") [, int $month = date("n") [, int $day = date("j") [, int $year = date("Y") [, int $is_dst = -1 ]]]]]]] )

Tidakkah Anda merasa itu membingungkan? Fungsi ini disebut "buat waktu" tetapi membutuhkan parameter hari, bulan dan tahun serta tiga parameter waktu. Seberapa mudah untuk mengingat urutan mereka masuk? Bagaimana jika kamu melihat mktime(1, 2, 3, 4, 5, 2246);? Bisakah Anda memahami itu tanpa harus merujuk ke hal lain? Apakah 2246ditafsirkan sebagai waktu 24 jam "22:46"? Apa arti dari parameter lainnya? Akan lebih baik sebagai objek.

Pindah ke PHP 5, sekarang ada objek DateTime. Di antara metodenya ada dua yang disebut setDate()dan setTime(). Tanda tangan mereka adalah sebagai berikut:

• public DateTime setDate ( int $year , int $month , int $day )
• public DateTime setTime ( int $hour , int $minute [, int $second = 0 ] )

Anda masih harus ingat bahwa urutan parameternya berubah dari yang terbesar ke yang terkecil, tetapi ini merupakan peningkatan besar. Perhatikan bahwa tidak ada metode tunggal yang memungkinkan Anda untuk mengatur keenam parameter sekaligus. Anda harus membuat dua panggilan terpisah untuk melakukan ini.

Apa yang Paman Bob bicarakan adalah menghindari memiliki struktur yang datar. Parameter terkait harus dikelompokkan bersama menjadi objek, dan jika Anda memiliki lebih dari tiga parameter, sangat mungkin Anda punya objek pseudo di sana, yang memberi Anda peluang untuk membuat objek yang sesuai untuk pemisahan yang lebih besar. Meskipun PHP tidak memiliki kelas Datedan terpisah Time, Anda dapat mempertimbangkan yang DateTimebenar - benar berisi Dateobjek dan Timeobjek.

Anda mungkin memiliki struktur berikut:

<?php
$my_date = new Date;
$my_date->setDay(5);
$my_date->setMonth(4);
$my_date->setYear(2246);

$my_time = new Time;
$my_time->setHour(1);
$my_time->setMinute(2);
$my_time->setSecond(3);

$my_date_time = new DateTime;
$my_date_time->setTime($my_time);
$my_date_time->setDate($my_date);
?>

Apakah wajib untuk menetapkan dua atau tiga parameter setiap kali? Jika Anda ingin mengubah jam atau hari, sekarang mudah untuk melakukannya. Ya, objek perlu divalidasi untuk memastikan setiap parameter berfungsi dengan yang lain, tapi itu yang terjadi sebelumnya.

Yang paling penting adalah, apakah lebih mudah dipahami, dan karenanya dipertahankan? Blok kode di bagian bawah lebih besar dari satu mktime()fungsi, tapi saya berpendapat itu jauh lebih mudah dipahami; bahkan non-programmer tidak akan mengalami banyak kesulitan dalam mengerjakan apa yang dikerjakannya. Tujuannya tidak selalu kode lebih pendek atau kode pintar, tetapi kode lebih dapat dipertahankan.

Oh, dan jangan gunakan global!

Banyak jawaban bagus di sini namun sebagian besar tidak membahas maksudnya. Mengapa ini aturan praktis? Ini tentang ruang lingkup, ini tentang dependensi dan ini tentang pemodelan yang tepat.

Global untuk argumen lebih buruk karena sepertinya Anda membuatnya lebih sederhana tetapi sebenarnya Anda hanya menyembunyikan kerumitannya. Anda tidak melihatnya lagi dalam prototipe tetapi Anda masih harus menyadarinya (yang sulit karena tidak ada untuk Anda lihat lagi) dan mendapatkan kepala Anda di sekitar logika fungsi tidak akan membantu Anda karena mungkin ada menjadi logika tersembunyi lainnya yang mengganggu di belakang Anda. Cakupan Anda meliputi semua tempat dan Anda memperkenalkan ketergantungan pada apa pun karena apa pun sekarang dapat mengacaukan variabel Anda. Tidak baik.

Hal utama yang harus dipertahankan untuk suatu fungsi adalah Anda dapat memahami apa fungsinya dengan melihat prototipe dan panggilan. Jadi namanya harus jelas dan tidak ambigu. Tetapi juga, semakin banyak argumen semakin sulit untuk memahami apa yang dilakukannya. Ini memperluas cakupan di kepala Anda, terlalu banyak hal yang terjadi, inilah mengapa Anda ingin membatasi jumlahnya. Itu penting argumen apa yang Anda hadapi, beberapa lebih buruk dari yang lain. Boolean opsional tambahan yang memungkinkan pemrosesan tidak sensitif pada kasus tidak membuat fungsi lebih sulit untuk dipahami sehingga Anda tidak ingin membuat masalah besar tentang hal itu. Sebagai catatan, enum membuat argumen yang lebih baik daripada boolean karena makna enum jelas dalam panggilan.

Masalah yang biasa terjadi bukanlah Anda menulis fungsi baru dengan sejumlah besar argumen, Anda akan mulai dengan hanya beberapa ketika Anda belum menyadari betapa rumitnya masalah yang Anda selesaikan sebenarnya. Saat program Anda berkembang, daftar argumen secara bertahap cenderung semakin panjang. Setelah model menetapkan dalam pikiran Anda, Anda ingin menyimpannya karena itu adalah referensi aman yang Anda tahu. Tapi kalau dipikir-pikir modelnya mungkin tidak terlalu bagus. Anda melewatkan satu langkah atau terlalu dalam logika dan Anda gagal mengenali satu atau dua entitas. "Oke ... saya bisa memulai lagi dan menghabiskan satu atau dua hari refactoring kode saya atau ... saya bisa menambahkan argumen ini sehingga saya bisa membuatnya melakukan hal yang benar dan selesai dengan itu. Untuk sekarang. Untuk skenario ini Untuk menghilangkan bug ini dari piringan saya sehingga saya bisa memindahkan catatan tempel ke selesai. "

Semakin sering Anda pergi dengan solusi kedua semakin mahal perawatan lanjutan akan terjadi dan semakin sulit dan tidak menarik akan menjadi refactor.

Tidak ada solusi pelat ketel untuk mengurangi jumlah argumen dalam fungsi yang ada. Mengelompokkan mereka menjadi senyawa tidak benar-benar membuat segalanya lebih mudah, itu hanyalah cara lain untuk menyeka kompleksitas di bawah karpet. Melakukannya dengan benar melibatkan melihat seluruh tumpukan panggilan lagi dan mengenali apa yang hilang atau telah dilakukan salah.

Beberapa kali saya telah menemukan bahwa pengelompokan banyak parameter yang dikirim bersama memperbaiki keadaan.

• Ini memaksa Anda untuk memberikan nama yang bagus pada konsep konsep yang digunakan bersama. Jika Anda menggunakan parameter-parameter itu bersama-sama, bisa jadi mereka memiliki hubungan (atau Anda tidak boleh menggunakannya bersama-sama).

• Setelah dengan objek saya biasanya menemukan bahwa beberapa funtionality dapat dipindahkan bahwa objek ini tampaknya stuypid. Biasanya mudah untuk menguji dan dengan kohesi yang hebat dan kopling yang rendah membuat hal itu menjadi lebih baik.

• Lain kali saya perlu menambahkan parameter baru saya punya tempat yang bagus untuk memasukkannya tanpa mengubah tanda tangan banyak metode.

Jadi itu mungkin tidak bekerja 100% dari waktu tetapi tanyakan pada diri sendiri apakah daftar parameter ini harus dikelompokkan dalam suatu objek. Dan tolong. Jangan gunakan kelas yang tidak diketik seperti Tuple untuk menghindari membuat objek. Anda menggunakan pemrograman berorientasi objek, tidak keberatan membuat lebih banyak objek jika Anda membutuhkannya.

Dengan segala hormat, saya cukup yakin Anda benar-benar melewatkan titik memiliki sejumlah kecil parameter dalam suatu fungsi.

Idenya adalah bahwa otak hanya dapat menyimpan begitu banyak "informasi aktif" pada satu waktu, dan jika Anda memiliki n parameter dalam suatu fungsi, Anda memiliki n lebih banyak "informasi aktif" yang perlu ada di otak Anda dengan mudah dan akurat. pahami apa yang dilakukan oleh potongan kode (Steve McConnell, dalam Code Complete (buku yang jauh lebih baik, IMO), mengatakan sesuatu yang serupa tentang 7 variabel dalam tubuh metode: jarang kita mencapai itu, tetapi lebih lagi dan Anda kehilangan kemampuan menjaga semuanya tetap lurus di kepala Anda).

Inti dari sejumlah variabel yang rendah adalah untuk dapat menjaga persyaratan kognitif untuk bekerja dengan kode ini kecil, sehingga Anda dapat bekerja dengannya (atau membacanya) lebih efektif. Penyebab utama dari hal ini adalah kode yang difaktorkan dengan baik akan cenderung memiliki parameter yang semakin sedikit (mis., Kode dengan faktor buruk cenderung untuk mengelompokkan banyak barang menjadi berantakan).

Dengan melewatkan objek alih-alih nilai, mungkin Anda mendapatkan tingkat abstraksi untuk otak Anda karena sekarang perlu disadari ya, saya punya SearchContext untuk bekerja di sini alih-alih memikirkan 15 properti yang mungkin berada dalam konteks pencarian itu.

Dengan mencoba menggunakan variabel Global, Anda telah sepenuhnya pergi ke seluruh arah yang salah. Sekarang Anda tidak hanya tidak menyelesaikan masalah karena memiliki terlalu banyak parameter untuk suatu fungsi, Anda telah mengambil masalah itu dan melemparkannya ke dalam masalah yang jauh lebih baik yang sekarang harus Anda bawa ke dalam pikiran Anda!

Sekarang alih-alih bekerja hanya pada tingkat fungsi, Anda juga harus mempertimbangkan lingkup global proyek Anda (ya ampun, betapa mengerikan! Saya ngeri ...). Anda bahkan tidak memiliki semua informasi di depan Anda dalam fungsi (omong kosong, apa itu nama variabel global?) (Saya harap ini belum diubah oleh sesuatu yang lain sejak saya memanggil fungsi ini).

Variabel yang dicakup secara global adalah salah satu hal yang paling buruk untuk dilihat dalam suatu proyek (besar atau kecil). Mereka menunjukkan ketidakmampuan untuk manajemen ruang lingkup yang tepat, yang merupakan keterampilan yang sangat mendasar untuk pemrograman. Mereka. Adalah. Jahat.

Dengan memindahkan parameter dari fungsi Anda dan menempatkannya ke dalam global, Anda telah menembak diri sendiri di foor (atau kaki, atau wajah). Dan Tuhan melarang Anda memutuskan bahwa hei, saya dapat menggunakan kembali global ini untuk sesuatu yang lain ... pikiran saya gemetar pada pikiran itu.

Keseluruhan yang ideal adalah menjaga hal-hal mudah dikelola, dan variabel global TIDAK akan melakukan itu. Saya akan mengatakan bahwa itu adalah salah satu hal terburuk yang dapat Anda lakukan untuk pergi ke arah yang berlawanan.

Saya telah menemukan pendekatan yang sangat efektif (dalam JavaScript) untuk meminimalkan gesekan antar antarmuka: Gunakan antarmuka yang seragam untuk semua modul , khususnya: fungsi param tunggal.

Saat Anda membutuhkan banyak parameter: Gunakan satu Objek / Hash atau Array.

Bersabarlah, aku berjanji aku tidak trolling ...

Sebelum Anda mengatakan "apa gunanya fungsi param tunggal?" Atau "Apakah ada perbedaan antara fungsi 1 Array dan multi arg?"

Baiklah. Ini mungkin secara visual halus, tetapi perbedaannya berlipat ganda - Saya mengeksplorasi banyak manfaat di sini

Rupanya beberapa orang menganggap 3 adalah # argumen yang tepat. Beberapa orang berpikir itu 2. Nah, itu masih menimbulkan pertanyaan, "param mana yang ada di arg [0]?" Alih-alih memilih opsi yang membatasi antarmuka dengan deklarasi yang lebih kaku.

Saya kira saya berpendapat untuk posisi yang lebih radikal: jangan mengandalkan argumen posisi. Saya hanya merasa itu rapuh dan mengarah ke argumen tentang posisi argumen sialan itu. Lewati dan teruskan ke pertarungan yang tak terelakkan tentang nama fungsi dan variabel. 😉

Serius meskipun, setelah penamaan menetap, mudah-mudahan Anda berakhir dengan kode seperti berikut, yang agak mendokumentasikan diri, tidak sensitif terhadap posisi, dan memungkinkan perubahan param di masa depan untuk ditangani di dalam ke fungsi:

function sendMessage({toUser, fromUser, subject, body}) { }

// And call the method like so:
sendMessage({toUser: this.parentUser, fromUser: this.currentUser, subject: ‘Example Alert’})