Rekomendasi untuk bergabung dengan garis implisit versus eksplisit


9

Saya ingin mengetahui rekomendasi tentang Penggabungan Garis Implisit versus Penggabungan Garis Eksplisit dengan Python.

Secara khusus, apakah Anda lebih menyukai satu formulir daripada yang lainnya? Apa yang Anda rekomendasikan sebagai standar umum? Kriteria apa yang Anda miliki untuk memilih satu dari yang lain, dan jika Anda memang memiliki preferensi satu, kapan Anda membuat pengecualian untuk yang lain?

Saya memiliki jawaban untuk pertanyaan ini yang mencerminkan bias saya sendiri, tetapi sebelum saya memposting jawaban saya sendiri, saya ingin tahu apa yang dipikirkan orang lain ... dan jika Anda dapat memiliki kriteria yang lebih baik daripada yang ada dalam pikiran saya, maka saya pasti akan menerima jawaban Anda sendiri.

Beberapa rekomendasi mungkin digeneralisasi untuk pilihan ini dalam bahasa pemrograman lain, tetapi bias saya sendiri agak kuat di Python karena beberapa fitur spesifik bahasa, jadi saya ingin tahu alasan umum dan Python-centric yang mungkin Anda gunakan miliki tentang topik ini.

Untuk beberapa latar belakang, diskusi terjadi sekitar pertanyaan tertentu tentang stackoverflow , tapi saya pikir lebih tepat untuk memindahkan diskusi ke sini sebagai pertanyaan untuk menghindari mengacaukan jawaban pada SO dengan tangen ini karena telah mengalihkan topik dari pertanyaan aslinya. Anda dapat melihat pertanyaan itu dan jawabannya untuk cuplikan kode contoh yang memulai diskusi.

Berikut ini contoh sederhana:

join_type = "explicit"
a = "%s line joining" \
    % (join_type)
# versus
join_type = "implicit"
b = ("%s line joining"
     % (join_type))

Pertanyaan praktik terbaik di luar topik untuk tinjauan kode. Saya telah memindahkan pertanyaan Anda ke tempat yang lebih baik.
Winston Ewert

1
@ WinstonEwert sebelum memposting, saya melihat dengan baik pada FAQ CodeReview dan Programmer FAQ , dan saya memilih CodeReview karena secara eksplisit mengatakan bahwa jenis pertanyaan yang diajukan di sana termasuk "Praktik terbaik dan penggunaan pola desain dalam kode Anda". Saya menyertakan versi kode yang disederhanakan dalam pertanyaan, jadi bagaimana ini di luar topik?
aculich

@ WinstonEwert Saya telah mengirim pertanyaan di Meta tentang klarifikasi FAQ CodeReview jika Anda ingin mengomentari ini di sana.
aculich

Jawaban:


8

Ada dokumen gaya pengkodean yang disebut PEP8. Ini merekomendasikan terhadap penggunaan di \<NL>mana pun kurung dapat digunakan.

Cara pembungkus garis panjang yang disukai adalah dengan menggunakan kelanjutan garis tersirat Python di dalam tanda kurung, kurung dan kawat gigi. Garis panjang dapat dipecah menjadi beberapa baris dengan membungkus ekspresi dalam tanda kurung. Ini harus digunakan dalam preferensi untuk menggunakan garis miring terbalik untuk kelanjutan garis. Pastikan untuk membuat indentasi baris lanjutan dengan tepat. Tempat yang disukai untuk istirahat di sekitar operator biner adalah setelah operator, bukan sebelumnya.

Teks lengkap: http://www.python.org/dev/peps/pep-0008/ (Tata Letak Kode bagian)

Ini tidak wajib tetapi mendefinisikan praktik baik yang dapat diterima yang sangat berguna jika Anda memiliki beberapa committer Python di tim Anda.


1

Saya cenderung menggunakan garis implisit bergabung karena saya merasa lebih mudah dibaca dan dukungan dari editor biasanya lebih baik berkaitan dengan lekukan dan menyoroti seluruh ekspresi berkat pencocokan tanda kurung.


0

Saat ini, saya lebih suka

join_type = "kiding"
a = "%s line joining" % (join_type)

B-))

.

Saya cenderung lebih suka Explicit Lines Joining karena saya tidak suka kekacauan orangtua di akhir ekspresi.
Tapi saya suka Garis Implisit Bergabung untuk mengurangi lebar ditempati oleh penulisan string.
Kemudian dalam beberapa kasus, saya malu untuk tidak mencampuradukkan dua cara


1
Semua bercanda samping, saya tidak suka bergabung secara eksplisit karena memerlukan lebih banyak mengetik dan sulit untuk menjaga semua garis miring terbalik rapi ketika kode diedit.
martineau

rupanya @eyquem belum pernah menulis LISP ...
cowbert
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.