Apakah ide yang buruk untuk mendaftar setiap argumen fungsi / metode pada baris baru dan mengapa?

Saya bekerja dengan seseorang yang, setiap kali mereka memanggil fungsi mereka menempatkan argumen pada baris baru misalnya

aFunction(
    byte1,
    short1,
    int1, 
    int2,
    int3,
    int4,
    int5
) ;

Saya menemukan ini sangat menjengkelkan karena artinya kode ini tidak terlalu kompak, jadi saya harus memindai ke atas dan ke bawah untuk benar-benar memahami logika. Saya tertarik untuk mengetahui apakah ini benar-benar praktik yang buruk dan jika demikian, bagaimana saya bisa membujuk mereka untuk tidak melakukannya?

Itu hanya pedoman pengkodean yang mungkin Anda suka atau tidak suka. Yang penting Anda dan kolega Anda setuju untuk menggunakannya atau tidak.

Jelas, cara terbaik untuk meningkatkan keterbacaan adalah dengan membatasi jumlah argumen.

Ini masalah preferensi. Untuk panggilan fungsi yang rumit di mana Anda ingin mendokumentasikan setiap parameter, atau di mana variabel agak panjang dan ada banyak dari mereka, ini bisa bagus.

Sebagai contoh:

do_complex_op(
      0, //Starting state, always 0, ask Joe why
      X, //X-coord of thingy
      y, //Y-coord of thingy
      73, //in this case, we don't want to use Z but want constant 
      dlogMessageTitle, //message for dialogue title
      dlogMessageText, //message for dialogue contents, don't care about this.
      SomethingIP, //IP of something-or-other server, can be NULL, won't crash.
      someObject.childObject.getValue(key1).HVAL, //very long path to HVAL
      someObject.childObject.getValue(key1).LVAL, //very long path to LVAL
      this.parentWindow.owner.mainTextBox.text.value.trim, //get the trimmed text, untrimmed text causes weird output
      pvrMainSettingForLongBlahs.getObjectByPath(somePath),
      pvrMainSettingForLongBlahs.K_TCA_UPPER_LIMIT,
      pvrMainSettingForLongBlahs.K_ENDPOINT_COMPLIANCE_LEVEL,
 );

Dengan bahasa yang mengizinkan parameter bernama, ini lebih umum jika Anda menggunakan nama parameter (contohnya dalam PL / SQL):

PKG_SOME_TEST_CODE.FN_DO_SOMETHING( in_text => 'test text',
                                    in_id => v_id,
                                    in_ref_id => v_ref_id,
                                    out_array_for_storage => v_bArray); 

Tapi saya setuju dengan Anda bahwa jika pemanggilan fungsi itu sederhana dan tidak terlalu banyak parameter, ini bisa mengganggu, seperti:

setColour (
    r,
    g,
    b
 );

Saya merasa lebih mudah dibaca

 setColour(r,g,b);

Untuk @ammoQ:

rc=a(b,c(d,e(f)))

rc=a(
     b,
     c(
       d,
       e(
         f
        )
      )
    )

IMO segala sesuatu yang tidak biasa adalah praktik yang buruk kecuali jika keunggulan dari gaya yang biasa dapat dibuktikan secara positif. “Matter of taste” adalah alasan yang buruk untuk menulis kode yang lebih sulit dibaca daripada yang diperlukan bagi sebagian besar programmer, karena suatu hari, jiwa yang miskin, tidak terbiasa dengan gaya itu, harus mempertahankan kode itu.

Membuktikan bahwa itu tidak biasa relatif mudah, tunjukkan sumber contoh di MSDN atau situs sejenis, tunjukkan basis kode sumber terbuka besar, dll. Tampilkan output dari pembuat kode. Pada akhirnya, perlihatkan bagaimana semua orang di tim Anda melakukannya. Jangan terima gaya buruk hanya karena seseorang terlalu keras kepala.

Nah, inilah beberapa umpan balik. Saya tidak pernah dituduh melakukan hal yang populer. Jelas, jika semuanya sesuai pada satu baris, maka baik-baik saja, paskan pada satu baris.

Tetapi perhatian utama saya bukanlah apakah kodenya "jelek" atau "cantik". Perhatian utama saya adalah betapa mudahnya memahami dan membuat perubahan tanpa membuat kesalahan.

Jika argumennya panjang dan ada banyak, mengapa tidak menempatkannya di baris yang berbeda? Dalam benak saya itu membuatnya lebih mudah untuk melihat siapa mereka, dan lebih mudah untuk mengubahnya jika perlu. Itu juga memberi saya ruang untuk melampirkan komentar untuk setiap argumen jika saya mau.

Saya juga ingin meminimalkan kemungkinan membuat kesalahan jika saya menambah atau menghapus argumen ke suatu fungsi, yang lebih mungkin terjadi di akhir daftar argumen daripada di awal. Untuk alasan itu, saya lebih suka meletakkan koma (,) di awal baris, daripada di akhir. Kemudian, jika misalnya, saya ingin menghapus atau menambahkan argumen di akhir daftar, itu adalah edit satu baris. Saya tidak harus mengutak-atik koma yang harus ada di akhir semua baris kecuali yang terakhir, di mana yang terakhir harus diakhiri dengan tanda kurung.

Jadi (nak, aku akan dinyalakan karena ini) aku menulisnya seperti ini:

nameOfFunction(firstArgument
    , secondArgument // optional comment
       ...
    , lastArgument   // optional comment
    );

Ketika ada fungsi dengan dari lima hingga dua puluh argumen, fungsi tersebut tidak mendapatkan semuanya sekaligus. Itu tumbuh seiring waktu, artinya ada banyak pengeditan. Setiap pengeditan yang tidak selesai adalah kesalahan sintaksis atau bug. Jadi saya tidak mengklaim ini cantik. Saya mengklaim ini membantu memperbaiki hasil edit.

(Dan bagi mereka yang mengatakan saya harus lulus struktur sebagai gantinya, semua yang dilakukan adalah mengganti masalah, karena Anda memerlukan banyak baris kode untuk mengisi struktur, belum lagi kode tambahan untuk menyatakan dan mengalokasikannya.)

Saya juga tidak akan menyebutnya. Praktik terbaik tempat saya pernah bekerja biasanya memiliki panggilan fungsi yang semuanya dalam satu baris, kecuali jika Anda harus menggulir secara horizontal jumlah yang signifikan untuk melihat seluruh panggilan. Itu panggilan penilaian, tapi saya pasti akan mengatakan bahwa untuk menempatkan semua fungsi seperti ini di luar batas kecuali itu adalah standar yang ditetapkan oleh organisasi Anda.

Inilah sebabnya mengapa itu adalah praktik yang baik bagi organisasi untuk membuat seperangkat panduan yang harus dipatuhi oleh semua programmer. Semuanya tentang konsistensi dan keterbacaan.

Itu membuatnya lebih mudah untuk:

• Susun ulang argumen.
• Mengomentari atau menonaktifkan argumen.
• Lihat dengan tepat argumen mana yang telah berubah ketika Anda melihat perbedaan dalam sistem kontrol versi Anda
• Hindari pengindeksan ulang dan pembungkusan kata semuanya saat Anda menambah atau menghapus argumen, atau mengubah nama fungsi. (Bahkan jika editor Anda secara otomatis indentasi, Anda masih membuat banyak perubahan spasi putih yang tidak membantu yang membuatnya lebih sulit untuk mengikuti perubahan dalam sistem kontrol versi Anda.)

Saya akan mengatakan bahwa panggilan fungsi harus semua dalam satu baris kecuali mereka secara signifikan melebihi apa pun lebar kode standar Anda (seringkali 80 karakter, sering kali menjadi penyebab argumen :-).

Saya tidak melihat keuntungan dari gaya ini. Terlihat jelek secara subyektif, dan saya merasa sakit ketika mencari kode. Misalnya Anda mungkin ingin mencari dengan cepat dan melihat apakah fungsi tersebut pernah dipanggil dengan parameter tertentu yang dilewatkan sebagai NULL. Ini mudah secara visual ketika semua parameter berada pada satu baris, dan lebih sulit ketika mereka dipisah seperti ini.

Saya sering melihat gaya itu pada deklarasi atau definisi fungsi , tetapi tidak pernah menelepon (sampai sekarang). Kadang-kadang masuk akal karena memungkinkan Anda menambahkan komentar untuk parameter individual dengan lebih jelas. Sepertinya dia menyalin gaya itu ke panggilan tanpa benar-benar mengetahui alasan di baliknya. Anda memiliki argumen yang bagus untuk menentang dan dia sepertinya tidak memiliki argumen yang bagus, jadi Anda memiliki suara saya, tetapi saya bukan orang yang harus Anda yakinkan.

Apakah itu melanggar standar pengkodean perusahaan?

Jika tidak, maka mulailah diskusi tentang standar dan apa yang ingin dilihat orang berubah. Pastikan Anda membawa ini sebagai salah satu hal yang ingin Anda ubah.

Lakukan diskusi lengkap tentang mengapa Anda merasa ini tidak berguna dan mudah-mudahan Anda akan menang. Anda tidak pernah tahu kolega Anda mungkin meyakinkan Anda bahwa jalannya adalah yang terbaik;)

Setelah Anda mendapatkan standar yang diperbarui, kemudian didokumentasikan apa yang harus dikodekan oleh semua orang, jadi jika rekan Anda tetap melakukan ini, Anda dapat meningkatkannya dalam ulasan kode.

Ini mungkin terlihat funky bagi Anda tetapi itu membuat bekerja pada kode lebih mudah. Saat melakukan refactoring, Anda dapat mengomentari argumen individual dengan sangat mudah dan memeriksa refactor Anda sebelum benar-benar menghapus sesuatu. Anda juga dapat berkomentar dan mengganti tipe sementara dengan cukup mudah.

Ini juga lebih mudah dibaca daripada:

int f(int, int, int,
      char, double, int
      X const&, Y)
{}

Saya belum menjadi ekstrem seperti yang Anda tunjukkan (karena tidak ada nama pada parameter yang tidak banyak digunakan), tetapi saya sudah terbiasa membelah setiap parameter pada barisnya sendiri atau tidak melakukan pemisahan sama sekali.

Bagian penting adalah bahwa kode Anda dapat dicetak atau ditampilkan pada layar standar, 80col dan masih dapat dibaca.

Anda jarang mendapatkan jawaban jujur ​​dari programmer untuk hal seperti ini. Semua orang hanya akan menjawab dengan apa yang mereka lakukan atau tidak sukai. Yang benar adalah bahwa, seperti yang sering kita semua berjuang dengannya, satu-satunya "praktik buruk" di sini adalah ketidakfleksibelan Anda sendiri.

Anda harus jujur ​​pada diri sendiri untuk dapat membedakan antara hal-hal yang sebenarnya buruk dan hal-hal yang hanya mengganggu Anda. Yang benar adalah bahwa dalam C / C ++ dan bahasa serupa Anda jarang akan menemukan praktik lekukan yang memiliki dampak nyata pada pemahaman kode. Sebagian besar diskusi tentang hal-hal semacam ini hanya terjadi pada kedua belah pihak ketika orang-orang membuat argumen yang konyol dan tidak jujur ​​untuk mencoba membenarkan pilihan pribadi mereka.

Yang saya baca ... adalah persis apa yang Anda minta dalam pertanyaan ini: argumen konyol dan tidak jujur ​​untuk membenarkan preferensi pribadi Anda.

Sejujurnya itu tergantung pada orangnya .. Saya akan mengatakan untuk fungsi kompleks seperti yang ditunjukkan oleh FrustratedWithForms contoh pertama, lalu ya; jika tidak, NO besar. Kemudian sekali lagi ini sebabnya saya lebih suka menerapkan fungsi IDE dari kode secara sewenang-wenang.

"Aku tertarik untuk mengetahui apakah ini benar-benar praktik buruk ..."

Ya, ini praktik yang buruk, kecuali ketika daftar variabel panjangnya tidak normal. Tetapi dalam kasus itu, masalahnya kemungkinan karena desain fungsi. Mengapa tidak melewatkan objek yang merangkum banyak parameter?

"... dan jika demikian, bagaimana aku bisa membujuk mereka untuk tidak melakukannya?"

Ikat mereka dan terus gelitik mereka sampai mereka setuju untuk menghentikan omong kosong itu.

Mengapa Anda membuang-buang siklus untuk masalah sepele seperti itu? Jalankan IDE tepercaya Anda, buka file, dan format ulang. Voila! Itu akan dalam bentuk apa pun yang Anda inginkan.

Sekarang mari kita beralih ke masalah yang sangat penting - vi atau emacs, LOL.

Saya akan mengatakan, jika argumen sesuai pada satu baris, lakukanlah. Jika tidak, maka satu argumen per baris menghasilkan keterbacaan yang luar biasa.

foo(arg1, arg2, arg3, arg4, arg5)

vs.

foo(
    arg1=arg1,
    arg2=arg2,
    arg3=arg3,
    arg4=arg4,
    arg5=arg5,
    arg6=arg6,
    arg7=arg7
)