Mengapa menulis sesuatu dalam bahasa X seolah-olah Anda sedang menulis sebuah program dalam bahasa Y dalam hal menggunakan paradigma pengkodean bersama [ditutup]

Beberapa waktu yang lalu, saya mengajukan pertanyaan pada SO tentang sesuatu yang ditulis dalam C ++, tetapi alih-alih mendapatkan jawaban atas masalah yang ada, komentarnya menjadi gila pada gaya pengkodean saya, bahkan ketika saya menunjukkan bahwa itu adalah sepotong kode WIP dan aku bermaksud membersihkannya nanti ketika base case-ku berjalan. (Saya mendapat begitu banyak suara sehingga saya memutuskan untuk menarik pertanyaan, karena perwakilan saya pada SO sudah hampir-hampir buruk)

Itu membuat saya bertanya-tanya mengapa orang mengadopsi sikap keras seperti "Anda seorang noob, pergi bercinta sendiri". Saya dituduh menulis C ++ seolah-olah itu Java. Sesuatu yang tidak bisa saya mengerti, dan itu masih membingungkan saya.

Saya telah memprogram dalam beberapa bahasa OOP selama beberapa tahun sekarang, meskipun secara berkala. Saya memilih bahasa yang akan digunakan dalam hal perpustakaan yang tersedia dan lingkungan eksekusi yang optimal untuk pekerjaan yang dihadapi. Saya mengadopsi pola desain dalam kode OOP dan saya cukup yakin bahwa penggunaan pola saya adalah suara dan bahwa OO bijaksana, saya dapat menahan saya sendiri. Saya mengerti kotak alat OOP, tetapi memilih untuk menggunakan alat hanya ketika saya pikir itu benar-benar diperlukan, bukan hanya menggunakan trik yang rapi untuk menunjukkan kecerdasan kode saya. (Yang saya tahu bukan kedudukan tertinggi, tapi saya pikir juga tidak di level n00b).

Saya mendesain kode saya sebelum menulis satu baris. Untuk menentukan tes, saya mencantumkan tujuan dari kelas tertentu, dan kriteria tes yang harus dipatuhi. Karena lebih mudah bagi saya untuk membuat diagram urutan dan kemudian menulis kode, saya memilih untuk menulis tes saya setelah antarmuka menjadi jelas.

Saya harus mengakui bahwa dalam bagian kode yang saya posting dalam pertanyaan, saya masih menggunakan pointer, daripada menggunakan pointer pintar. Saya menggunakan RAII kapan pun saya bisa. Saya tahu RAII yang tepat berarti melindungi terhadap nullpointers, tetapi saya bekerja secara bertahap. Itu adalah pekerjaan yang sedang berjalan dan saya bermaksud untuk membersihkannya nanti. Cara kerja ini sangat dikecam.

Dalam pandangan saya, saya harus memiliki contoh kerja terlebih dahulu sehingga saya dapat melihat apakah kasus dasar adalah cara berpikir yang layak. Saya juga kebetulan berpikir bahwa membersihkan kode adalah sesuatu yang khas dari fase refactoring lincah, setelah kasus dasar telah terbukti. Saya harus mengakui bahwa walaupun saya perlahan mendapatkan standar Cxx, saya lebih suka menggunakan apa yang saya pahami, daripada mengambil risiko menggunakan konsep yang belum saya kuasai dalam kode produksi. Saya mencoba hal-hal baru sesekali, tetapi biasanya dalam proyek bermain yang saya miliki di samping, hanya untuk tujuan itu.

[Sunting] Saya ingin mengklarifikasi bahwa saran nyamuk [1] tidak muncul dalam pencarian yang saya lakukan sebelum saya mulai mengajukan pertanyaan saya. Namun, meskipun sarannya mencakup satu aspek pertanyaan, pertanyaan yang ia kaitkan tidak menjawab inti pertanyaan saya, hanya sebagian saja. Pertanyaan saya adalah lebih lanjut tentang respons yang saya dapatkan pada gaya pengkodean saya dan aspek profesional dalam menangani berbagai gaya pengkodean dan (jelas) tingkat keterampilan. Dengan pertanyaan saya sebelumnya pada SO dan itu respons sebagai kasus yang tepat. [/ edit]

Pertanyaannya kemudian adalah: mengapa mencemooh seseorang yang tidak menggunakan gaya pengkodean Anda?

Hal-hal / subdivisi yang tersedia bagi saya adalah:

• Mengapa praktik pemrograman yang buruk menggunakan lebih banyak kode rawan kesalahan dalam situasi prototipe, jika refactoring membuatnya lebih kuat sesudahnya?
• Bagaimana program yang ditulis dalam C ++ dapat seperti itu ditulis dalam Java? Apa yang menjadikannya program yang buruk, (mengingat saya menunjukkan maksud gaya saat ini dan pekerjaan yang direncanakan untuk ditingkatkan?)
• Bagaimana saya akan menjadi profesional yang buruk jika saya memilih untuk menggunakan konstruk yang digunakan dalam paradigma pemrograman tertentu (misalnya OOP / DP)?

[1] Kembangkan cepat dan bermasalah, lalu koreksi kesalahan atau lambat, hati-hati untuk setiap baris kode?

Tanpa melihat kode yang dimaksud, ada beberapa cara untuk menulis kode Java di C ++, beberapa lebih buruk daripada yang lain.

1. Pada satu ekstrem, ada meletakkan sumber Anda seperti Java: semuanya dalam satu file, semua dalam definisi kelas, dll .:

   class HelloWorldApp {
   public:
       void main() {
           cout << "Hello World!" << endl;
       }
   };
   

   Ini adalah bagaimana sumber Java akan ditata. Secara teknis legal di C ++, tetapi meletakkan segala sesuatu di file header dan semuanya inline (dengan mendefinisikannya dalam deklarasi kelas) adalah gaya yang mengerikan dan akan membunuh kinerja kompilasi Anda. Jangan lakukan itu.
2. Terlalu banyak OO - Untuk menyederhanakan, di Jawa, itu adalah Kerajaan Nouns , di mana semuanya adalah objek. Kode C ++ yang baik (idiomatis) lebih cenderung menggunakan fungsi, templat, dll yang gratis, alih-alih mencoba menjejalkan semuanya menjadi objek.
3. No RAII - Anda sudah menyebutkan ini - menggunakan pointer dan pembersihan manual, bukan smart pointer. C ++ memberi Anda alat seperti RAII dan smart pointer, kode C ++ yang sangat bagus (yaitu idiomatik) menggunakan alat tersebut.
4. Tidak ada C ++ lanjutan - Dasar-dasar Java dan C ++ cukup mirip, tetapi begitu Anda masuk ke fitur yang lebih canggih (template, pustaka algoritma C ++, dll.), Mereka mulai menyimpang.

Kecuali untuk # 1, tidak satu pun dari ini membuat program C ++ program yang buruk, tetapi juga bukan jenis kode yang saya sukai untuk bekerja sebagai programmer C ++. (Saya juga tidak akan senang bekerja dengan Perl non-idiomatik atau C-style, Python non-idiomatik, dll.) Bahasa memiliki alat dan idiom dan filosofi sendiri, dan kode yang baik menggunakan alat dan idiom itu alih-alih mencoba menggunakan penyebut umum terendah atau mencoba mereproduksi pendekatan bahasa lain. Menulis kode non-idiomatis dalam bahasa tertentu / domain masalah / apa pun yang tidak menjadikan seseorang programmer yang buruk, itu hanya berarti bahwa mereka harus lebih banyak belajar tentang bahasa / domain masalah / apa pun itu. Dan tidak ada yang salah dengan itu; ada daftar yang sangat panjang yang harus saya pelajari lebih banyak, dan C ++ khususnya memiliki banyak hal untuk dipelajari.

Mengenai pertanyaan khusus menulis kode rawan kesalahan dengan maksud untuk membersihkannya nanti, itu bukan hitam dan putih:

• Jika beberapa kode prototipe gagal untuk menangani setiap kemungkinan pengecualian dan setiap kasus sudut yang mungkin, maka itu yang diharapkan. Buat itu bekerja, lalu buat itu bekerja dengan kuat. Tidak masalah.
• Jika beberapa kode prototipe ditulis dengan gaya yang buruk atau desain yang buruk (buruk untuk bahasa yang diberikan dan idiom-idiomnya, desain yang secara fundamental buruk untuk masalah, dll.), Maka kecuali jika Anda menulisnya sebagai membuang-buang pembuktian konsep, Anda tidak mendapatkan apa-apa.

Untuk menggunakan pointer mentah versus pointer pintar sebagai contoh, jika Anda akan bekerja di C ++, menggunakan RAII dan pointer pintar cukup mendasar sehingga harus lebih cepat untuk menulis kode seperti itu daripada kembali dan membersihkannya nanti. Sekali lagi, gagal melakukan ini tidak berarti seseorang adalah programmer yang buruk, tidak profesional, dll., Tetapi itu berarti ada lebih banyak yang harus dipelajari.

Setiap bahasa pemrograman memiliki serangkaian idiom dan praktik terbaik, yang biasanya akan mengarah pada kode yang elegan, benar, dan berkinerja. Berikut adalah beberapa praktik terburuk yang baik-baik saja dalam beberapa bahasa lain:

• Saya akan berteriak jika Anda menulis for ($i = 0; $i < 42; $i++) { … }dalam Perl, tetapi tidak dalam PHP
  (dalam Perl, variabel harus dideklarasikan, dan loop tersebut harus diulang pada rentang)
• Saya akan menangis jika Anda menulis new Foo()dalam C ++ tanpa alasan yang baik, tetapi tidak di Jawa
  (C ++ tidak memiliki pengumpulan sampah, jadi RAII harus digunakan. Noobs akan membocorkan memori jika tidak)
• Saya akan merasa ngeri jika Anda mendeklarasikan semua variabel Anda di bagian atas fungsi Anda, kecuali dalam C89, Pascal, atau JavaScript.
• Saya akan facepalm jika Anda menempatkan semua fungsi Anda ke dalam kelas dengan Python, tetapi tidak di Jawa
  (Python adalah bahasa multi-paradigma, bukan memaksa "OOP" dan mendukung fungsi di tingkat atas)
• Saya akan menangis jika Anda return nullmenggunakan Scala, tetapi tidak dalam bahasa C-like
  (karena Scala memiliki Optiontipe)
• Saya akan mengeluh jika Anda menulis algoritma rekursif di Jawa, tetapi tidak di OCaml
  (karena tumpukan Java meluap dengan cepat, sedangkan OCaml memiliki optimasi panggilan ekor)
• ...

Sangat mudah untuk menggunakan bahasa baru seolah-olah itu adalah sesuatu yang Anda tahu, dan dengan keberuntungan itu akan berhasil. "Anda dapat menulis Fortran dalam bahasa apa pun". Tetapi Anda benar-benar tidak ingin mengabaikan fitur khusus yang ditawarkan bahasa X, karena kemungkinan besar X menawarkan beberapa keunggulan dibandingkan U.

“ Saya memilih bahasa yang akan digunakan dalam hal perpustakaan yang tersedia dan lingkungan eksekusi yang optimal untuk pekerjaan yang sedang dilakukan ” - tetapi apakah bahasa X ini sebenarnya lebih baik daripada bahasa U untuk pekerjaan yang ditangani juga tergantung pada seberapa akrab dengan bahasa itu, atau berapa lama untuk menjadi cukup akrab untuk menggunakannya dengan baik. Anda tidak akan menghasilkan gergaji mesin yang berat hanya karena memotong kayu paling cepat, ketika Anda benar-benar menginginkan pisau pena lama Anda karena pas ke tangan Anda dengan sempurna. Kecuali Anda benar-benar ingin menebang pohon.

Tetapi pertanyaan Anda lebih tentang masalah budaya : mempelajari semua praktik terbaik membutuhkan banyak waktu, dan pemula mengajukan sebagian besar pertanyaan, sedangkan guru menjawabnya. Tetapi apa yang jelas bagi seorang guru tidak jelas bagi seorang pemula, dan guru terkadang melupakan hal itu. Sebagai seorang pemula, solusinya adalah tidak berhenti bertanya. Namun, seseorang dapat menunjukkan keterbukaan untuk belajar dan menerapkan praktik terbaik, misalnya dengan mencoba membersihkan kode Anda sebanyak mungkin sebelum menunjukkannya kepada orang lain. Sebagian besar bahasa memiliki beberapa praktik terbaik inti yang mudah dipelajari, bahkan ketika seluruh kurva belajar sebenarnya sangat panjang.

Masalah umum adalah bahwa orang yang baru mengenal pemrograman mengabaikan lekukan atau format lainnya, dan kemudian menjadi bingung karena program mereka tidak berfungsi. Saya akan bingung juga, dan langkah pertama untuk memahami suatu program adalah memastikan itu ditata dengan sempurna. Kemudian, kesalahan sederhana seperti kutipan penutupan yang terlupakan atau koma yang hilang tiba-tiba menjadi jelas. Saya percaya bahwa Anda sudah mempraktikkan pemformatan yang baik, dan ini adalah metafora untuk praktik terbaik lainnya: praktik terbaik mencegah kesalahan, praktik terbaik membuat menemukan kesalahan lebih mudah, menerapkan praktik terbaik dilakukan sebelum menemukan masalah .

Terlalu murah untuk mengatakan "Aku akan memperbaikinya nanti", ketika memperbaikinya sekarang akan memecahkan masalah Anda (juga, "fase pembersihan" dongeng mungkin tidak pernah datang, jadi satu-satunya pilihan yang bertanggung jawab adalah melakukannya dengan benar. pertama kali). Paling tidak, mencoba membuat kode Anda sebaik mungkin sebelum meminta bantuan orang lain membuat mereka lebih mudah untuk berpikir tentang kode Anda, jadi adalah hal yang sopan untuk dilakukan.

Saya bukan pengembang C ++ hardcore, tapi ...

Mengapa praktik pemrograman yang buruk menggunakan lebih banyak kode rawan kesalahan dalam situasi prototipe, jika refactoring membuatnya lebih kuat sesudahnya?

Satu hal yang perlu diingat adalah bahwa kesalahan dalam C ++ biasanya berarti "perilaku tidak terdefinisi". Dalam bahasa yang aman, hal terburuk yang bisa terjadi adalah pengecualian menghentikan program Anda dengan segera. Di C ++, Anda beruntung jika mendapat segfault. Sangat mungkin program Anda terus melakukan sesuatu yang salah. Itu juga bisa berperilaku dengan benar untuk jangka waktu tertentu dan memanifestasikan bug lebih lama, atau bisa berperilaku dengan benar sepanjang waktu tetapi pada akhirnya memakan semua memori Anda.

Bagaimanapun, hanya perlu satu kesalahan untuk mengambil eksekusi program sepenuhnya dari rel dan ke wilayah yang belum dipetakan. Kemungkinan untuk pengembang C ++ penuh waktu, "kasus dasar" berarti "tidak ada kemungkinan perilaku yang tidak jelas atau kebocoran memori."

Bagaimana program yang ditulis dalam C ++ dapat seperti itu ditulis dalam Java? Apa yang menjadikannya program yang buruk?

Saya tidak berpikir ada jawaban untuk ini yang tidak akan spekulatif dan banyak pendapat. Jika Anda ingin pendapat saya tentang itu, Java cenderung memiliki beberapa antipatterns yang terkait seperti kenyataan bahwa semuanya harus menjadi objek. Dimana dalam bahasa lain Anda akan melewati sebuah pointer, functor, atau fungsi, di Jawa biasanya Anda menemukan ton hampa dan sempit-berguna ThingDoers, FooFactoriesdan IFrobnicatorsyang hanya fungsi yang menyamar.

Demikian juga, di mana dalam bahasa lain Anda mungkin melewatkan tuple sederhana atau struct tanpa nama, di Jawa untuk menggabungkan bahkan hanya 2 objek ke dalam wadah data sederhana mengharuskan Anda untuk menentukan sebelumnya 30+ baris kelas NamedThing dengan setter, getter, dan Javadocs. Kurangnya fitur Java memaksa programmer untuk melakukan backflip ganda berorientasi objek untuk menyelesaikan sesuatu kadang-kadang. Kode yang dihasilkan jarang idiomatik di luar Jawa.

Lalu ada fakta bahwa di C ++ Anda memerlukan grafik objek yang sangat sederhana untuk mengelola memori secara manual; biasanya suatu objek dimiliki oleh tepat satu objek lain. Di Jawa Anda tidak perlu mengikuti batasan ketat seperti itu, karena pengumpul sampah memastikan semuanya akan bersih ketika tidak ada lagi referensi tentang mereka. Jadi pasti ada risiko manajemen memori yang salah jika Anda hanya menerjemahkan kode dari Java ke C ++.

Akhirnya, bisa jadi hanya elitisme. Saya tidak akan berpura-pura mereka menjadi mayoritas, tapi saya pasti melihat sentimen "Saya tidak butuh bahasa yang akan memegang tangan saya dan membuat saya tidak melakukan hal-hal bodoh" di antara beberapa pengembang C ++. Dalam benak mereka, C ++ adalah bahasa "nyata" dan jika Anda tidak dapat menangani keanehannya, Anda bukan seorang "programmer sejati".

Jawaban topik sedikit tidak aktif ...

Jangan khawatir - ini adalah "perilaku" umum dalam komunitas pakar mana pun. Dan jujur, jika Anda baik dalam bahasa apa pun, dan Anda akan menemukan kode yang "aneh", mungkin Anda akan mengkritiknya juga. (karena, mau MENGAJAR).

Saya di dunia perl - ketika akan melihat sesuatu seperti:

$imax=$#array;
$str=""
for($i=0; $i<$imax; $i++) {
    $str = "$str" . $array[$i];
}

dari pada:

my $str = join '', @array;

yakin akan berkomentar - (baca: ajar penulis) tentang joinfungsi tersebut.

Bagaimanapun, terlalu banyak kritik sama sekali tidak produktif, dan salah satu contoh terbaik adalah yang berikut: (diambil dari: http://perl-begin.org/humour/#How_can_I_switch_off_the_T.V..3F )

(Bit ini diposting secara anonim ke sebuah pastebot pada 23 Maret 2011. Itu ditempatkan di sini untuk anak cucu setelah beberapa pengeditan.) - sedikit diedit juga

Pertanyaan: bagaimana saya bisa menghidupkan TV saya?

Apa yang ingin didengar OP?

Misalnya: Cari tombol on / off remote TV Anda, tekan. Tombolnya biasanya merah dan terletak di garis paling atas pada remote.

Jawaban pakar #perl: Pertama, apa yang Anda maksud dengan "aktifkan"? Tentukan terlebih dahulu. Nopaste TV Anda, remote TV dan ruang tamu juga.

... setelah nopaste:

Kamarmu jelek. Dan TV terlihat mengerikan. Gunakan Mr. Clean di layar, dan bersihkan ruang tamu Anda terlebih dahulu. Gunakan tiga pel pembersih bukan dua. Gunakan HDMI dan jangan pernah gunakan konektor scart (?), Kecuali jika Anda benar-benar menginginkannya. Remote TV Anda memiliki tombol yang tidak dapat dibaca, bersihkan terlebih dahulu. Anda seorang pemula, jadi baca:

http://experts.blog/how_to_design_a_future_3D_TV.html http://experts.blog/the_basics_of_tv_repairing.html http://experts.blog/viruses_in_living_room_short_essay.html http://experts.blog/global_chip_html

Tamu IRC: Tapi, saya tidak ingin menjadi pakar TV.

Jawab: Mengapa Anda ingin menghidupkan TV ?!

Mengapa praktik pemrograman yang buruk menggunakan lebih banyak kode rawan kesalahan dalam situasi prototipe, jika refactoring membuatnya lebih kuat sesudahnya?

Saat menulis cepat dan kotor dengan pikiran memperbaikinya nanti ada bahaya melupakan sesuatu yang perlu Anda perbaiki.

Bagaimana program yang ditulis dalam C ++ dapat seperti itu ditulis dalam Java? Apa yang menjadikannya program yang buruk, (mengingat saya menunjukkan maksud gaya saat ini dan pekerjaan yang direncanakan untuk ditingkatkan?)

Di java Anda tidak perlu memikirkan siapa yang memiliki objek tertentu, Anda cukup meneruskan referensi dan lupakan itu seolah tidak ada artinya. Namun dalam C ++ perlu ada definisi yang jelas tentang siapa yang memiliki objek dan siapa yang bertanggung jawab untuk membersihkannya.

Bagaimana saya akan menjadi profesional yang buruk jika saya memilih untuk menggunakan konstruk yang digunakan dalam paradigma pemrograman tertentu (misalnya OOP / DP)

Kamu tidak akan; C ++ adalah bahasa multi-paradigma, itu terjadi untuk mendukung OOP dengan baik tetapi dapat melakukan banyak hal lain juga. Namun sebagian besar bermuara pada menggunakan alat yang benar untuk pekerjaan daripada menarik palu setiap kali Anda perlu mendorong lonjakan runcing ke kayu.

Alasan Anda mendapat respons yang buruk adalah bahwa kebanyakan orang di SO cenderung menilai keterampilan berdasarkan seberapa idiomatik Anda dapat mengode dalam bahasa yang Anda tanyakan. Orang-orang yang akrab dengan C ++ cenderung tidak mengerti ketika mereka melihat kode buruk yang terlihat seperti sesuatu yang telah menggigit mereka di masa lalu.