it-swarm-id.com

Apakah menulis komentar di dalam metode bukan praktik yang baik?

Seorang teman mengatakan kepada saya bahwa menulis komentar di dalam metode tidak baik. Dia mengatakan bahwa kita harus memiliki komentar hanya untuk definisi metode (javadocs) tetapi tidak di dalam tubuh metode. Sepertinya dia membaca dalam sebuah buku yang memiliki komentar di dalam kode berarti ada masalah dalam kode. Saya tidak mengerti alasannya. Saya pikir menulis komentar di dalam tubuh metode itu bagus dan membantu pengembang lain untuk memahaminya dengan lebih baik dan lebih cepat. Harap berikan komentar Anda.

63
Srini Kandula

Teman Anda salah, dan sangat sedikit programmer yang setuju dengannya. Anda harus menulis komentar kapan pun dan di mana pun Anda merasa mereka yang terbaik membantu pemahaman.

151
mqp

Abaikan temanmu. Berikan komentar sesuai kebutuhan. Tetapi berusaha membuat kode Anda cukup jelas, sehingga komentar tidak diperlukan. Ingatlah bahwa komputer Anda tidak menjalankan komentar, sehingga mudah bagi komentar untuk keluar dari sinkronisasi dengan apa yang sebenarnya terjadi.

Saya cenderung menggunakan sekumpulan komentar untuk menjelaskan sedikit logika yang rumit, yang kalau tidak demikian akan membutuhkan sedikit sentuhan otak untuk membaca. Dan kemudian saya akan mencoba untuk membuat logika lebih jelas, dan menghilangkan kebutuhan akan penjelasan.

90
Michael Petrotta

Kode yang baik mendokumentasikan diri sendiri. Suatu metode harus melakukan tepat satu hal, dan satu hal itu harus jelas dengan nama metode dan spesifikasi komentar. Oleh karena itu, memerlukan komentar dalam metode yang menjelaskan logika menunjukkan bahwa metode tersebut harus dipecah menjadi metode tanggung jawab tunggal.

Sekarang, untuk kenyataan. Anda dihadapkan pada basis kode kode-spaghetti yang kompleks dan Anda berusaha bersikap Baik kepada para pengelola. Anda tidak punya waktu atau mandat untuk memperbaiki 8 juta baris kode, dan bahkan jika Anda melakukannya, akan ada nuansa karena semuanya rumit. Apa yang kamu kerjakan?

44
Mark Peters

Saya terkejut berapa banyak orang yang tidak setuju dengan pandangan ini.

  1. Kode yang baik harus mendokumentasikan diri sendiri, jadi Anda harus hati-hati memilih nama metode, nama variabel, dll
  2. Metode Anda tidak boleh terlalu lama sehingga Anda tidak dapat melihat seluruh metode dan komentar dalam satu layar

Yang mengatakan, ada pengecualian. Tapi itu pengecualian. Dan intinya adalah pengecualian, yaitu jumlahnya sedikit. Anda benar-benar hanya perlu menjelaskan kode sebaris jika Anda melakukan sesuatu yang berlawanan dengan intuisi.

Situasi umum di mana Anda mungkin perlu komentar dalam metode Anda adalah ketika Anda menerapkan peretasan lokal untuk mengoptimalkan kecepatan, tetapi yang pada bacaan pertama mungkin memberi programmer lain saat yang tepat. Itu poin yang bagus untuk menambahkan komentar.

Tetapi secara umum: tidak, jangan tambahkan komentar di metode Anda.

24
markijbema

Saya pikir dia berbicara tentang kasus seperti ini:

public void upload() {
    // destination Host
    String Host = ....
}

Di mana Anda dapat membuat kode lebih baik dengan memiliki nama variabel yang lebih eksplisit, daripada komentar:

public void upload() {
    String destinationHost = ....
}
18
Douglas

Saya yakin teman Anda mengacu pada "Kode Bersih" oleh Robert C. Martin. Namun, saya pikir dia terlalu menyederhanakan situasi. Buku ini berbicara tentang memberikan metode nama yang jelas dan deskriptif, yang kita semua harus tahu, tetapi yang tidak pernah bisa cukup diulang. Buku ini juga merekomendasikan membuat metode yang sangat kecil dengan membungkus blok kode apa pun yang dapat diberi nama yang jelas dan deskriptif menjadi metode tersendiri. Jadi, jika Anda merasa bahwa satu blok kode memerlukan komentar yang menjelaskan apa yang dilakukannya, maka Anda harus menjadikannya metode terpisah dengan nama yang sesuai. Secara teori, jika semua metode Anda di bawah 5 baris, dan jika mereka semua memiliki nama deskriptif yang baik, harus jelas apa yang mereka lakukan tanpa harus menjelaskannya dalam komentar.

Namun, itu tidak berarti bahwa Anda tidak boleh memiliki komentar di dalam metode Anda. Intinya adalah bahwa komentar tidak boleh berlebihan. Mereka harus menambahkan informasi. Jika Anda memiliki metode yang melakukan tepat satu hal, dan hal itu jelas dari namanya, maka Anda tidak perlu komentar yang menjelaskan apa yang dilakukannya. Namun, sangat masuk akal untuk memiliki komentar yang menjelaskan mengapa ia melakukan hal tersebut dengan cara tertentu. Anda mungkin ingin komentar yang menjelaskan mengapa Anda memilih satu algoritma di atas yang lain, atau mengapa Anda memilih satu struktur data di atas yang lain. Dengan kata lain, Anda ingin kode itu sendiri untuk menjelaskan cara kerjanya, dan Anda ingin komentar untuk menjelaskan alasan keputusan desain Anda, i. e. mengapa semuanya dilakukan dengan cara khusus ini.

Buku ini merekomendasikan refactoring kode buruk daripada berkomentar. Ini tentu saja merupakan ide bagus dalam teori, tetapi dalam kenyataannya Anda mungkin tidak memiliki waktu atau infrastruktur, seperti kerangka uji unit kerja dengan serangkaian tes unit yang sesuai untuk melakukan itu. Ada saat-saat ketika Anda dihadapkan dengan basis kode yang berantakan, yang harus Anda kerjakan kemarin, dan satu-satunya cara untuk maju adalah mencoba memahami bagian-bagian yang berantakan, dan berkomentar sebagai cara untuk membuat catatan untuk diri Anda sendiri.

16
Dima

Ya, Anda pasti menulis komentar di dalam metode di Jawa.

As Konvensi kode Sun mengatakan:

Program Java dapat memiliki dua jenis komentar: komentar implementasi dan komentar dokumentasi. Komentar implementasi adalah yang ditemukan di C++, yang dibatasi oleh /*...*/, dan //. Komentar dokumentasi (dikenal sebagai "komentar doc") hanya Java, dan dibatasi oleh /**...*/. Komentar dokumen dapat diekstraksi ke file HTML menggunakan alat javadoc.

Jadi, komentar dalam metode adalah komentar implementasi.

8
zengr

Saya sangat tidak setuju dengan teman Anda dan berpendapat bahwa komentar fungsi sebaris adalah bagian yang sangat penting dari penulisan kode yang baik. Komentar fungsi dirancang untuk memberi klien kode pemahaman yang lebih baik tentang apa yang seharusnya dilakukan kode - apa arti parameter dan nilai pengembaliannya, jenis invarian yang diharapkan ada pada saat masuk dan keluar, dll. Komentar inline, bagaimanapun, diarahkan terutama pada pengelola kode dan idealnya sebagai serangkaian catatan mental untuk pembuat kode asli. Mereka memungkinkan untuk melihat metode yang kompleks yang orang lain telah baca dan untuk intuisi apa yang dipikirkan oleh penulis asli. Mereka juga memudahkan untuk mendiagnosis bug, karena jika komentar menggambarkan apa maksud kode tersebut dan asumsi apa yang dibuatnya, akan jauh lebih mudah untuk mengetahui bagaimana sepotong kode keliru ketika kerusakan terdeteksi.

Saya pribadi menemukan komentar sebaris berguna karena memaksa saya untuk membuktikan kepada diri sendiri bahwa kode yang akan saya tulis akan berfungsi dengan benar. Seringkali, saya akan membiasakan diri untuk tidak menulis kode apa pun tanpa terlebih dahulu mengomentari maksudnya dan bagaimana cara kerjanya. Lebih sering daripada tidak, ini mencegah saya membuat kesalahan konyol dalam kode karena saya akan menemukan bahwa penjelasan saya tidak benar atau tidak mempertimbangkan beberapa kasus Edge.

Tentu saja, setiap orang memiliki disiplin pengkodean sendiri, dan mungkin beberapa orang merasa lebih mudah untuk menulis kode tanpa komentar sebaris dan bukannya membagi kode menjadi beberapa metode yang lebih kecil. Namun, dari pengalaman saya telah menemukan bahwa komentar sebaris sangat berharga selama pengembangan dan debugging, dan sangat berguna bagi orang lain yang harus melihat dan menjaga kode saya lama setelah saya pindah ke proyek lain.

6
templatetypedef

Teman Anda mungkin mengekspresikan gagasan bahwa komentar adalah, jika bukan diri mereka sendiri "bau kode", a " deodoran ". Ini tidak spesifik untuk komentar dalam metode, tetapi mungkin cenderung lebih benar dari komentar dalam metode daripada komentar pembukaan.

Ketika Anda menulis komentar, biasanya itu untuk menjelaskan sesuatu. Ketika sesuatu perlu dijelaskan - yah, itu tidak jelas. Kode hebat adalah cukup jelas. Jadi ketika Anda menambahkan komentar, Anda menutupi kegagalannya untuk menjelaskan sendiri, tanpa membuatnya jelas. Jadi setiap kali Anda menulis komentar seperti itu, alih-alih mengubah kode - dengan mengganti nama, dengan metode ekstraksi, dll. Ke buat cukup jelas, Anda kurang ideal.

Tapi kita semua gagal sempurna sekarang dan lagi. Dan seringkali lebih baik menambahkan komentar yang jelas daripada membiarkan kode yang sulit dipahami tidak terdokumentasi.

6
Carl Manaster

Komentar yang baik menjelaskan mengapa tidak bagaimana caranya. Itulah perbedaan utama di sini. Kebanyakan orang akan dapat mengikuti apa yang Anda lakukan tetapi mengapa Anda melakukannya memerlukan komentar tambahan. Komentar itu harus sedekat mungkin dengan operasi.

3
Bill Leeper

Saat mengomentari kode Anda (atau kode orang lain yang benar-benar tidak terdokumentasi), Anda mungkin sering dihadapkan dengan perasaan belaka jijik , benci atau murka . Kode mungkin berperilaku frustasi dan tidak terduga dan Anda mungkin harus menambahkan beberapa peretasan yang sangat jahat untuk membuatnya bekerja untuk tenggat waktu tertentu.

Dalam semua kasus itu, ungkapkan perasaan Anda dengan memberi anotasi pada masing-masing bagian kode dengan beberapa swearwords (lihat linux kernel fuckcount ) adalah praktik umum. Komentar-komentar itu harus hidup di dalam metode sehingga tidak muncul dalam API yang didokumentasikan secara otomatis, sehingga bos Anda atau klien Anda atau orang agnostik kode sumber lainnya tidak akan pernah melihatnya.

Namun sesama programmer Anda akan merasa senang lega dan kebahagiaan ketika mempelajari sumbernya . (Dan tentu saja Anda dapat menambahkan catatan pada diri Anda sendiri, atau menggunakan kode sumber sebagai media komunikasi sampai batas tertentu, #TODO: add more examples here)

Tentu saja Anda mungkin berpendapat, bahwa komentar semacam ini tidak seharusnya ada di tempat pertama, atau bahwa mereka harus dihapus sebelum rilis final, tetapi hari ini proyek perangkat lunak memiliki siklus rilis yang sangat singkat, dan beberapa komentar masih relevan banyak pembangunan malam nanti, jadi mungkin teman Anda harus mulai belajar untuk membaca (dan menulis) di antara baris .

2
codecraft

Sangat menyenangkan memiliki kode yang tidak perlu dikomentari. Saat Anda mendapatkan, menyimpan, dan menghapus sesuatu, kami punya ide bagus apa yang sedang terjadi dan tidak perlu komentar.

Terkadang kode menjadi berantakan dan merupakan kandidat untuk refactoring, jadi Anda mungkin harus berkomentar untuk sementara waktu.

Hari ini saya punya sederet kode tidak melakukan apa yang diharapkan. Rupanya .net datatable tidak berpikir bahwa baris yang diimpor adalah catatan baru. Saat Anda memasukkan catatan dari tabel tidak ada yang terjadi. Baris yang diimpor harus terlebih dahulu diubah statusnya. Hanya komentar yang diperlukan, jadi ketika saya kembali ke sana 6 bulan dari sekarang dan berpikir, "Untuk apa saya butuh itu?" Aku akan tahu.

1
JeffO

Ini adalah praktik umum bagi programmer untuk memberikan komentar di dalam metode kapan pun mereka pikir tidak jelas bagi programmer lain apa yang dilakukan kode. Pemrogram juga terkadang memasukkan komentar TODO ke dalam metode. Namun, memang benar bahwa jika Anda memiliki terlalu banyak komentar di dalam metode, Anda mungkin perlu mundur dan berpikir jika Anda melakukan hal-hal yang terlalu rumit dari yang seharusnya. Dengan kata lain, Anda mungkin ingin menghindari mengomentari sesuatu yang jelas bagi programmer lain karena lebih sulit untuk membaca kode dengan mereka.

Untuk menerima saran teman Anda secara positif, Anda harus ingat bahwa kami dapat menghindari berkomentar terlalu banyak dengan menyebutkan variabel dan metode dengan benar dan menjaga setiap metode tetap kecil dan memastikan mereka tidak melakukan terlalu banyak staf.

1
knoguchi

Saya pikir alasan dia mengatakan itu adalah karena dia percaya fungsi harus cukup singkat sehingga masing-masing merangkum hanya operasi konseptual tunggal.

Saya tidak perlu menganut kepercayaan itu secara ekstrem (karena berbagai alasan, termasuk membaca kode seperti itu bisa menjadi mimpi buruk), tetapi jika ada, mungkin mereka hanya memiliki satu komentar per fungsi, karena hanya ada satu konsep per fungsi dan satu komentar per konsep.

Apa pun cara saya menggunakan komentar kapan pun dan di mana pun ada kode yang pilihan atau perilakunya tidak segera jelas - sering berkaitan dengan pertimbangan kinerja atau matematika esoterik. Hal-hal semacam itu sering tidak langsung menjadi perhatian konsumen fungsi, jadi saya berpendapat bahwa sebenarnya ide yang bagus untuk menyembunyikannya dari dokumentasi.

1
Rei Miyasaka

Saya yakin teman Anda berbicara tentang javadoc, yang akan menghasilkan dokumentasi dari komentar Anda jika itu di atas deklarasi metode Anda (dan dihiasi dengan tanda bintang tambahan) seperti ini:

/**
   get a webpage for a given url 
   @param url: the url to get
   @returns String: the http-source 
*/
public String getWebpage (String url) {
... 

Jika Anda memasukkan komentar ini ke dalam metode, itu tidak berguna.

Oleh karena itu - sebagai aturan praktis: beri komentar di Java sumber di atas metode.

Pengecualian dapat dan akan terjadi. Saya setuju untuk: menggunakan metode pendek, menulis kode self-documenting. Namun javadoc sebagai alat mendorong duplikasi komentar, karena selain itu terlihat begitu telanjang dalam dokumentasi. :)

1
user unknown

Saya mengakui bahwa dalam sebuah metode yang ditulis dari awal, seseorang dapat mendokumentasikan fungsinya hanya dalam header. Namun.

Saya menemukan bahwa komentar sering disisipkan di mana bug ditemukan dan nuansa halus diabaikan bahkan jika metode ini hanya memiliki satu tanggung jawab - yang jujur ​​saja, jarang terjadi dalam kode warisan. Lebih lanjut, saya tidak melihat alasan untuk memiliki nama variabel yang panjangnya empat puluh karakter (bahkan jika itu hanya digunakan di dua tempat) ketika nama variabel pendek dengan komentar ringkas dapat lebih mudah dicerna dan digunakan kembali nanti. Bersih dan ringkas adalah yang terbaik, tetapi di atas semua itu, ini merupakan sarana komunikasi dengan programmer lain sebanyak email, surat, dan puisi juga. Dan untuk itu saya menambahkan kutipan:

"Aku hanya membuat surat ini lebih lama karena aku tidak punya waktu untuk membuatnya lebih pendek."

Blaise Pascal, (1623-1662) Lettres Provinciales

1
M. Tibbits

Komentar hanya membuat kode lebih ramah bagi programmer, ingat komentar tidak akan dieksekusi.

Jika Anda membaca kode setelah beberapa bulan, komentar akan memudahkan membaca kode.

Ini akan membuat kode dapat dipelihara dan programmer lain yang melihat kode akan merasa mudah untuk memahami logika yang telah Anda terapkan.

Itu tidak berarti bahwa Anda harus selalu menambahkan komentar bahkan untuk metode dengan beberapa baris kode.

Seperti misalnya kode berikut cukup jelas dan tidak memerlukan komentar apa pun untuk menjelaskan fungsinya

public String getName(){
    return name;
}

Sementara ketika sebuah metode besar jangan menambahkan komentar sehingga lebih mudah dibaca setiap kali ada programmer melihatnya.

Ingat saat menulis kode, Anda mungkin berpikir bahwa kode itu cukup jelas, tetapi ketika Anda dapat melihatnya setelah enam bulan, komentar yang Anda tambahkan enam bulan lalu pasti akan membantu Anda atau programmer lain memahami kode dengan cepat.

0
Alpine

Masalah dengan komentar inline adalah bahwa mereka harus dipertahankan bersama dengan kode (juga berlaku untuk fungsi/metode/modul/komentar tingkat kelas, tetapi tidak untuk gelar yang lebih besar); Tuhan tahu berapa banyak kode sumber masih di luar sana di mana komentar sama sekali tidak ada hubungannya dengan kode yang mereka dokumentasikan, IMO mana yang sama buruk atau lebih buruk daripada tidak memiliki komentar sama sekali.

Idealnya, dokumentasi sebaris harus dibatasi pada situasi berikut:

  • Menjelaskan kode yang sangat dioptimalkan atau "rumit", bersama dengan pembenaran untuk mengapa kode sangat dioptimalkan atau "rumit" ("kami kehilangan persyaratan kinerja X dan profil menunjukkan hambatan yang ada di ini bagian; optimasi di bawah ini memperoleh kinerja Y% ");

  • Mengacu pada standar atau persyaratan ("jarak posting DTED 0 adalah 30 detik busur");

  • Identifikasi kode yang memerlukan analisis/pengembangan lebih lanjut ("TODO");

Hukum pertama dokumentasi kode - jangan mendokumentasikan yang sudah jelas. Sesuai dengan hukum pertama dokumentasi kode - tulis kode yang jelas sejauh mungkin.

0
John Bode

Pertama, pertanyaan Anda berorientasi pada Java - yang secara signifikan memengaruhi jawabannya.

Jumlah komentar yang wajib sangat terkait dengan bahasa tempat Anda bekerja.

  • Beberapa bahasa seperti Java dan C # meminjamkan diri mereka dengan sangat baik untuk konsep kode self-documenting. Dalam bahasa-bahasa ini usaha Anda dihabiskan untuk membuat kode itu sendiri sebagai dapat dibaca dan deskriptif mungkin, dan kemudian menambahkan komentar sebaris hanya untuk hal-hal yang tidak dapat Anda uraikan secara asli dalam bahasa tersebut.

  • Beberapa bahasa seperti SQL lebih sulit untuk dibaca. Sintaksis, urutan evaluasi, bersarang, dan sebagainya dapat membuatnya lebih sulit untuk dirancang dengan cara mendokumentasikan diri. Pendekatan dasar yang sama masih berlaku: fokuslah menggunakan bahasa sebanyak mungkin, kemudian tambahkan komentar untuk mengimbangi area yang tidak jelas atau membingungkan.

Secara keseluruhan Anda tidak dapat 100% menghapus komentar, tetapi tujuan Anda seharusnya menghapus perl untuk komentar sebanyak mungkin dengan membuat kode lebih menggambarkan diri. Hasil dari upaya ini biasanya kode kurang keseluruhan dan kode lebih terorganisir. Terlepas dari apakah masih ada komentar yang hadir atau tidak, ini berarti bahwa kode Anda akan jauh lebih mudah dikelola dan didekati - yang sebenarnya merupakan komentar yang dimaksudkan untuk dibantu dalam hal apa pun.

0
STW

Gagasan bahwa Javadoc (atau bahkan petunjuk autocomplete Delphi) harus mengubah cara kode orang (selain menambahkan fungsionalitas untuk javadoc) sangat tidak masuk akal.

Tanyakan temanmu yang mana yang lebih dulu, javac atau javadoc?

Itu seperti bertanya mana yang lebih dulu, sapi atau Nyonya O'Leary


Juga, javadoc harus untuk orang yang mengimplementasikan kelas dan fungsi Anda, komentar dalam kode adalah untuk orang yang menjaga kode Anda. Terutama dengan metode pribadi Anda, tidak seorang pun harus melihat kode Anda untuk melihat apa yang dilakukannya. Untuk itulah dokter itu. Tetapi jika seseorang perlu men-tweak sesuatu karena berbulu oleh satu kesalahan, maka Anda ingin mengomentari hal itu dalam metode Anda.

Dia jelas mengasumsikan 90% dari kode yang sebenarnya perbaikan bug semuanya buruk. Saya tidak pernah membaca "Programmer pragmatis" tetapi saya bisa berasumsi dia tidak merujuk buku itu.

0
Peter Turner

Saya akan melemparkan dua sen saya sekarang karena pestanya sudah cukup baik. Saya menggunakan komentar ketika saya menjelaskan sedikit logika bisnis tertentu atau ketika saya harus menambahkan sesuatu untuk menutupi kasus Edge yang tidak terduga.

Kode berevolusi dari waktu ke waktu untuk memperhitungkan hal-hal yang tidak diketahui sebelumnya, dan jadi ketika Anda menerapkan bantuan-band, alih-alih mengasumsikan bahwa itu dikenal mengapa Anda menggunakan bantuan-band itu, terkadang membantu untuk menambahkan blok kecil di dalam kode yang mengatakan "oh, omong-omong, saya harus memperbaiki ini dan inilah referensi bugtracker sehingga Anda dapat mengikuti percakapan di sekitarnya" dan dalam kasus saya (karena saya menggunakan FogBugz) akan terlihat seperti ini :

//Case: 1234 ~ Throttling based on unusual activity per ABC request.
Throttler myThrottler = new Throttler( oldActivity );

atau terserah. Jadi poin saya adalah bahwa sesuatu yang tampaknya tidak pada tempatnya dan tidak dapat dibaca mungkin adalah tempat yang baik untuk inline dokumen. Pengetahuan yang terkumpul adalah hal yang indah.

Tetapi poin pertama saya adalah logika bisnis saya. Saya benar-benar memiliki blok dalam prosedur tersimpan yang akan saya tulis ulang AM ini yang memiliki beberapa aturan bisnis di depan.

/****************************************************************
author  yourstruly
date    2010-11-18
descrip intended use is to blah blah blah
        ended up over actual measured blah blah blah according to blah blah blah
        rules from the customer are:
        If the sum of the blah blah blah is higher than the blah blah blah
        and the blah blah blah contain blah blah blah,
        and the blah blah blah is non-zero,
        recalculate the blah blah blah to fit within the blah blah blah

        Additional rules for us internally: 
        if the blah blah blah originally read blah blah blah don't blah blah blah (set to zero)

        rewritten here with (1) traceable statements for the where clauses.
        If 
            the blah blah blah(1) is higher than the blah blah blah (2)
        and the blah blah blah (3)
        and the blah blah blah is non-zero (9)
        and the blah blah blah is lower than the blah blah blah (4)
        and the edited blah blah blah is higher than the blah blah blah (5)
        then recalculate the blah blah blah (6)
        // See note lower in this document on the math

        If 
            the blah blah blah(1) is higher than the blah blah blah (2)
        and the blah blah blah (3)
        and the blah blah blah is higher than the blah blah blah (7)
        then set the blah blah blah to zero (8)

        (7) dictates the same as (4) but it's easier to do (7)
****************************************************************/

Sorry for the blah blah blah's but proprietary rules and all that ;)

Dan tiba-tiba Anda melihat bahwa saya memiliki persyaratan (!) Tertanam dalam kode saya sebagai komentar dan saya dapat merujuk ke komentar sebagai /*(1)*/ (yang saya lakukan) sehingga ini mudah dilacak untuk karyawan berikutnya (yang itu, dan dia dapat menemukan bagian-bagian yang perlu tweaker segera) dan kemudian jika ada yang ingin tahu spesifikasi apa yang mereka dapat membaca komentar dari atas, dan jika ada yang ingin tahu apa kode pseudo itu di sana dan jika ada yang ingin mengkonversi pseudo-code ke kode maka di sana Anda pergi. Bagi saya ini jauh lebih mudah dibaca (untuk kasus saya) karena menjaga permintaan asli (terpotong dari email) dan memungkinkan kereta pemikiran cepat dikumpulkan tanpa terlalu banyak berpikir, dan memungkinkan untuk menggunakan transformasi mudah dari semu menjadi kode nyata.

Dan ya, ada beberapa komentar sebaris yang mengatakan ini dan itu tidak berfungsi seperti yang diharapkan dalam pseudo-code karena persyaratannya tidak cukup cocok dengan data sehingga kami perlu men-tweak data. Tapi itu maksud saya. Kami mendokumentasikan in-line kasus Edge, dan kami meninggalkan pseudo-code dalam kode yang tepat untuk mengikuti logika, jadi kami semua tahu apa yang diharapkan dari persyaratan asli

0
jcolebrand