Mengingat bahwa programmer adalah penulis dan menulis kode untuk mengekspresikan pemikiran dan konsep abstrak, dan kode yang baik harus dibaca oleh programmer lain tanpa kesulitan dan kesalahpahaman, haruskah programmer mengambil pelajaran menulis untuk menulis kode yang lebih baik?

Konsep abstrak dan masalah dunia nyata / entitas adalah bagian penting dari penulisan kode yang baik, dan penguasaan yang baik dari bahasa yang digunakan untuk pengkodean harus memungkinkan programmer untuk mengekspresikan pikirannya lebih mudah, atau dengan cara yang lebih baik. Selain itu, ketika mencoba menulis atau menulis ulang beberapa kode untuk membuatnya lebih baik, banyak waktu dapat dihabiskan dalam menentukan nama untuk fungsi, variabel atau struktur data.

Saya pikir ini juga dapat membantu untuk menghindari penulisan kode dengan lebih dari satu makna, seringkali menyebabkan kesalahpahaman di antara programmer yang berbeda. Kode harus selalu menyatakan dengan jelas fungsinya secara jelas.

1. Pelajaran menulis? Tidak juga.

Menulis kode sumber cukup berbeda dari menulis buku.

Walaupun keduanya mengejar tujuan yang sama: menjadi tidak ambigu mungkin dan mudah dipahami, mereka melakukannya dengan cara yang sangat berbeda, dan hal-hal yang harus dipelajari penulis tidak sama dengan hal-hal yang harus dipelajari oleh pengembang perangkat lunak.

Contoh 1: kiasan

Tokoh-tokoh pidato berharga ketika menulis novel, puisi, dll., Karena mereka meningkatkan ekspresif penulisan.

Apa yang terakhir kali Anda melihat sebuah oxymoron atau litotes dalam kode sumber ? Apakah akan membantu memilikinya, atau lebih baik sangat berbahaya bagi pengembang mana pun yang harus mempertahankan kode sumber tersebut nanti?

Contoh 2: kosakata

Kosakata yang kaya sangat dihargai dalam literatur. Kosakata William Shakespeare, misalnya, adalah dua puluh ribu hingga dua puluh lima ribu kata. Kosa kata yang lebih kaya membuatnya lebih menarik untuk membaca novel atau puisi.

Ketika Anda menulis kode sumber, Anda mengharapkannya dibaca oleh orang-orang yang tidak bisa berbahasa Inggris dengan baik . Menunjukkan seberapa baik Anda tahu bahasa Inggris akan sangat berbahaya bagi kode Anda. Jika Anda tahu kata mewah yang berarti persis apa yang Anda butuhkan tetapi Anda tahu bahwa banyak orang tidak tahu arti kata ini, Anda sebaiknya mencari sinonim yang kurang ekspresif atau serangkaian kata yang menjelaskan artinya. Kosakata beberapa ribu kata seringkali cukup untuk proyek tertentu.

Perhatikan aspek penting: sementara Google Terjemahan bisa sangat membantu bagi penutur asing, ada dua masalah dengan penerjemah apa pun:

• Sepasang bahasa tidak harus memiliki kecocokan 1: 1 di antara kata-kata. Beberapa kata tidak memiliki terjemahan dalam bahasa lain, atau beberapa kata dapat diterjemahkan menjadi satu kata dalam bahasa asing. Misalnya, dalam bahasa Rusia, ada sejumlah besar kata-kata yang menargetkan keadaan khusus salju dan cuaca dingin, dan menerjemahkannya dalam bahasa Prancis atau Spanyol biasanya tidak mungkin tanpa kehilangan kekhususannya.

• Suatu kata terkadang memiliki banyak makna, dan artinya disimpulkan dari konteksnya. Google Translate, meskipun memiliki kualitas tinggi, biasanya tidak dapat menunjukkan makna untuk situasi apa pun kecuali yang paling mendasar.

Contoh 3: ekspresi

Ekspresi membuat prosa lebih kaya juga. Seorang penulis berharap seorang pembaca memiliki sejumlah budaya umum, dan menggunakan kesempatan ini untuk membuat teks lebih ekspresif.

Demikian pula dengan contoh sebelumnya, ungkapan seperti itu bisa sangat bermasalah ketika dibaca oleh orang yang bukan penutur asli. Tetapi jika kosa kata umum biasanya dapat diterjemahkan, ekspresi jauh lebih bermasalah.

Misalnya, bahasa Inggris bukan bahasa pertama saya, dan setiap hari, saya menemukan ekspresi, termasuk di sini di StackExchange, yang saya tidak tahu. Saya mencoba menebak artinya, dan kadang-kadang saya benar. Tapi kadang-kadang saya salah, dan mencari ekspresi itu di Google tidak membantu.

Seorang pengguna dalam komentarnya mengingatkan saya pada contoh yang membuat saya menderita untuk waktu yang lama ketika saya baru saja memulai pemrograman: jarum PHP dan tumpukan jerami . Saya tidak mengetahui kiasan yang sesuai, jadi setiap kali saya membaca dokumentasi, saya bertanya-tanya tentang apa semua ini. Tidak perlu dikatakan bahwa C # sequence.Contains(element)atau Python element in sequenceyang sangat baik adalah alternatif yang jauh lebih baik. Setidaknya, pengembang yang tidak tahu bahasa Ibrani juga harus menderita PHP , tetapi ini adalah cerita yang berbeda.

Contoh 4: referensi budaya

Referensi budaya. Dalam sastra, tergoda untuk memasukkan unsur-unsur dari budaya tertentu, dan ini juga membuat buku lebih kaya dan kadang-kadang lebih menarik untuk dibaca.

Namun, kode ini ditujukan untuk pengembang dari seluruh dunia. Oleh karena itu, apa yang merupakan referensi yang jelas untuk pengembang Italia mungkin tidak terlalu jelas untuk pengembang Rusia, dan apa yang diketahui oleh setiap anak lelaki atau perempuan India mungkin tidak diketahui oleh programmer Amerika.

Pengguna yang sama yang berbicara tentang jarum dan tumpukan jerami memberikan contoh yang sangat baik dari referensi budaya seperti itu: Cawan. Siapa yang tidak tahu apa itu Grail? Maksudku, itu "Graal" dalam bahasa Prancis, "Grial" dalam bahasa Spanyol dan ... "Kutsal Kâse" dalam bahasa Turki, tapi tetap saja. Namun, seberapa banyak pengembang Amerika atau Eropa mengetahui sejarah abad pertengahan Cina atau India? Mengapa ada yang berasumsi bahwa setiap programmer Cina dan India harus mengetahui referensi Holy Grail?

2. Pelajaran untuk menulis kode sumber ekspresif? Tentu.

• Setiap pengembang harus belajar cara menulis kode sumber ekspresif.

• Setiap pengembang harus menjelaskan mengapa komentar di:

  int j = i + 1; // Creating i and adding 1 to it.
  

  itu buruk, walaupun fakta itu benar-benar salah.

• Setiap pengembang harus dapat memahami refactoring dasar dan bagaimana hal itu membantu membuat kode sumber lebih ekspresif.

• Setiap pengembang harus ingat bahwa 20% dari waktu dihabiskan untuk mengembangkan kode, dan 80% dari waktu mempertahankannya. Untuk beberapa proyek, ini lebih seperti 5% - 95%.

• dll.

Intinya, pemrograman dekat dengan dokumentasi teknis. Apakah seseorang yang menulis spek untuk baut harus mengambil pelajaran menulis? Tidak juga. Hal yang sama berlaku untuk pengembang. Siapa pun harus menulis tanpa membuat kesalahan ejaan dalam setiap kata, dan siapa pun harus dapat mengomunikasikan idenya dengan cukup jelas. Selain itu, saya tidak yakin bagaimana pelajaran menulis akan lebih berguna daripada, katakanlah, kursus dalam ilmu komputer atau keamanan TI atau apa pun.

Ekspresi kode sumber dapat dipelajari dengan cara lain. SuperM menyebutkan salah satu dari mereka dalam jawabannya : membaca kode yang baik. Saya dapat menyebutkan beberapa yang lain:

• Membaca buku seperti Kode Indah atau Kode Lengkap,

• Meminta pengembang yang lebih berpengalaman untuk meninjau kode Anda,

• Memahami pola dan bagaimana dan kapan menggunakannya.

haruskah seorang programmer mengambil pelajaran menulis untuk menulis kode yang lebih baik?

Tidak. Seorang programmer harus mengambil pelajaran menulis untuk belajar menulis prosa yang lebih baik. Seorang programmer harus mengambil pelajaran pemrograman untuk belajar menulis kode yang lebih baik. Terlepas dari beberapa kesamaan, penulisan prosa dan penulisan kode sangat berbeda.

Itu tidak berarti bahwa programmer tidak boleh mengambil kelas menulis. Mereka harus! Beberapa alasan:

• Menulis adalah keterampilan penting bagi setiap orang yang berpendidikan. Anda akan tampak lebih pintar jika Anda bisa menulis dengan baik.

• Terlepas dari upaya terbaik mereka, programmer sering perlu berkomunikasi dengan manusia lain, sering menggunakan kata-kata tertulis

• Anda belajar keterampilan di luar menulis dalam kelas menulis, dan itu sering berguna bagi programmer. Misalnya, Anda akan belajar membahas pekerjaan orang lain tanpa melukai perasaan mereka, dan Anda akan belajar menerima kritik dari orang lain tanpa menganggapnya pribadi.

Kode saya semakin tergantung pada penciptaan kosakata bersama antara bisnis dan tim teknis. Saya akan mengatakan bahwa meningkatkan keterampilan menulis Anda dapat membantu Anda mengurangi ambiguitas dan kesalahpahaman dalam upaya-upaya ini, tetapi sepertinya tidak akan membantu ekspresi kode Anda.

Gagasan sastra tentang ekspresif tidak sama dengan gagasan pemrograman ekspresif. Dalam banyak kasus, ambiguitas dalam bahasa dapat digunakan sebagai perangkat sastra, bahkan dalam non-fiksi, dalam bentuk yang meningkatkan ekspresif, karena akan memicu berbagai asosiasi budaya, bahasa dan simbolik dalam pembaca, baik yang dimaksudkan maupun tidak. Jenis ekspresif seperti ini tidak diinginkan dalam pemrograman; abstraksi lebih berharga daripada ambiguitas. Dalam pemrograman, abstraksi meningkatkan fleksibilitas dengan mungkin beberapa biaya beban kognitif. Abstraksi dalam bentuk sastra dapat memiliki kebalikan dari efek yang dimilikinya dalam pemrograman: semakin abstrak tulisan Anda, semakin besar kemungkinan pembaca akan memiliki persepsi bahwa Anda tidak mengatakan apa-apa. Semua simbol dan asosiasi yang dihasilkan dari ucapan konkret memiliki nilai,

Namun, seorang programmer bukan mesin. Manusia mendapat manfaat dalam cara yang sering tak terduga dari pertumbuhan intelektual dan emosional. Meningkatkan tulisan Anda dapat menghasilkan empati pelanggan yang lebih besar karena Anda memaksa diri Anda untuk berjuang dengan tantangan komunikasi; mungkin Anda akan merasakan pelanggan yang mengatakan apa yang mereka inginkan, kemudian Anda memberikannya dan mereka menyadari itu bukan yang mereka butuhkan. Mungkin Anda hanya akan belajar untuk fokus pada apa yang tidak terucapkan.

Mungkin belajar melempar tanah liat pada roda tembikar akan membantu Anda mulai melihat paralel antara keahlian dan pengembangan perangkat lunak. Mempelajari cara membangun arsitek berkomunikasi mungkin mengarahkan Anda untuk memiliki apresiasi yang lebih kuat untuk membangun kosakata pola desain dalam pemrograman. Mempelajari biologi mungkin menuntun Anda pada wawasan yang menarik tentang bagaimana semut dan lebah menemukan dan berkomunikasi tentang sumber makanan dan bagaimana mekanisme sederhana itu dapat diterjemahkan ke dalam algoritma penelusuran jalur.

Mempelajari hal-hal di luar domain inti Anda bermanfaat karena orang yang penasaran membuat pengembang lebih baik daripada orang yang tidak.

Untuk apa nilainya, saya hampir menjadi jurusan sastra; Saya akhirnya beralih ke Studi Asia Timur karena saya lebih tertarik pada kelas yang saya ambil di departemen itu. Ada kemungkinan saya mungkin tidak berada di industri ini jika saya tidak belajar Studi Asia Timur, karena efek samping dari belajar bahasa Jepang membuat saya lebih berharga pada saat itu, ketika sebuah perusahaan perangkat lunak mempekerjakan saya sebagian karena kemampuan bahasa. Saya masih harus membangun portofolio keterampilan teknis yang lebih dalam, tetapi efek samping yang tidak diinginkan dari mempelajari apa pun dapat membuat Anda menjadi profesional perangkat lunak yang lebih baik dan lebih relevan.

Ketika proyek pemrograman gagal biasanya karena komunikasi gagal, umumnya sekitar persyaratan. Meskipun pemahaman bahasa Inggris yang biasa-biasa saja mungkin cukup untuk benar-benar menulis kode, menjadi komunikator yang baik sangat penting untuk menulis kode yang benar. Di era komunikasi berbasis teks yang bekerja jarak jauh ini, menulis bahasa Inggris adalah keterampilan komunikasi yang sangat penting.

Yang mengatakan, pertanyaan Anda ditulis dengan cara yang sangat jelas dan ringkas - lebih baik daripada kebanyakan programmer yang pernah bekerja dengan saya. Karena tidak melihat kode Anda, saya sarankan Anda berkonsentrasi untuk mengekspresikan diri dalam bahasa pengkodean pilihan Anda. Untuk Jawa, saya merekomendasikan buku Joshua Bloch, "Java Efektif."

Seperti penulis yang diajarkan dengan membaca klasik dunia, sehingga programmer dididik dengan membaca kode yang baik . Tapi ada satu masalah kecil. Meskipun ada raksasa yang diakui dalam literatur, ada beberapa dari mereka dalam pemrograman. Dan jika ada, mereka mungkin "berbicara" dengan bahasa yang berbeda. (Saya bahkan tidak yakin itu masuk akal untuk menyarankan membaca kode sumber Minix oleh Tanenbaum)

Ada banyak cara populer untuk membuat kode lebih mudah dibaca (=> dapat dipelihara), seperti menulis komentar, memberikan nama yang bermakna, dll. Selain itu, banyak perusahaan menetapkan aturan penulisan kode mereka, dan itu membuat semuanya lebih mudah.

Bagaimanapun, seperti banyak penulis hebat, programmer tidak pernah senang dengan kode mereka sendiri. Jadi mengetahui kapan berhenti sama pentingnya dengan menulis kode kualitas.

Saya selalu menemukan hanya berhenti setelah setiap bit kode yang Anda tulis dan membacanya lagi, membayangkan bahwa Anda belum pernah melihatnya, membuat saya jauh dengan ini.

Bahkan yang lebih baik adalah bertanya kepada seorang teman yang akrab dengan pemrograman untuk membaca kode Anda tanpa memberi tahu mereka apa fungsinya.

Saya tidak berpikir itu akan membantu; penulisan kreatif adalah tentang plot dan pengembangan karakter dan dialog, bukan tentang mengekspresikan konsep teknis dengan jelas. Menulis teknis mungkin membantu, tetapi saya ragu - mereka hanya menulis yang sangat berbeda!

dan perhatikan bahwa kode "dapat dibaca" adalah subyektif, dan terutama masalah gaya sintaksis dan idiom umum (yang bervariasi di antara bahasa dan bahkan di antara tim)

memilih nama baik untuk variabel dan kelas dan metode, bagaimanapun, adalah penting. Setiap pengembang, sampai taraf tertentu, menjadi ahli subjek dalam aspek-aspek tertentu dari domain yang sedang dikembangkan, sehingga penggunaan terminologi domain yang benar sangat penting.

ulasan sejawat dapat membantu Anda membangun kosa kata dan kepercayaan diri

Tentu ada perbedaan besar antara menulis kode dan menulis prosa.

Dalam prosa, kalimat-kalimat dihubungkan (atau dipisahkan) dengan waktu (cara mereka mengikuti satu sama lain untuk mencapai tujuan atau makna) tetapi dalam kode (efisien) Anda dapat (kembali) memuat bagian-bagian dari 'cerita' dari tabel dengan berulang tindakan / tanggapan. Jadi, interaksi dengan pembaca (dalam prosa) atau pengguna (kode) sama sekali berbeda.

Dengan cara lain, menulis prosa 'bagus' dan menulis kode 'bagus' serupa: belajar menulis (kode atau prosa) adalah proses yang melibatkan banyak kesalahan (atau berpikir / menguji tentang perbaikan, atau merumuskan kembali) untuk mendapatkannya ' anggun'.

Saya pikir sistem unsur kimia periodik elegan, karena cara yang sangat ringkas itu menggambarkan beberapa sifat dasar dari bahan dasar yang kita gunakan, sedikit seperti kode efisien tetapi tentu saja tidak prosa. Lelucon memiliki banyak kualitas prosa (membuat Anda berada dalam suasana hati tertentu, mempertahankan suasana hati itu dan kemudian mengubahnya, ketika tidak terduga) tetapi itu adalah praktik pengkodean yang mengerikan.

Namun kedua jenis tulisan ini meminta keahlian.

Bahasa Inggris dasar dan tata bahasa sudah cukup untuk seorang programmer dari sudut pandang saya. Tetapi kemudian segala sesuatu untuk menghentikan rutinitas pemrograman yang monoton akan selalu meremajakan dan dengan demikian pelajaran menulis akan menenangkan bagi para programmer.