Menafsirkan kode sumber orang lain [ditutup]


9

Catatan: Saya mengetahui pertanyaan ini . Pertanyaan ini sedikit lebih spesifik dan mendalam, namun, berfokus pada membaca kode aktual daripada men-debug atau bertanya kepada penulis.

Sebagai siswa di kelas ilmu komputer tingkat pengantar, teman-teman saya kadang-kadang meminta saya untuk membantu mereka dalam tugas mereka. Pemrograman adalah sesuatu yang sangat saya banggakan, jadi saya selalu senang melakukannya. Namun, saya biasanya mengalami kesulitan menafsirkan kode sumber mereka.

Kadang-kadang ini karena gaya yang aneh atau tidak konsisten, kadang-kadang karena persyaratan desain aneh yang ditentukan dalam tugas, dan kadang-kadang hanya karena kebodohan saya. Bagaimanapun, aku akhirnya terlihat seperti orang idiot yang menatap layar selama beberapa menit dan berkata "Uh ..."

Saya biasanya memeriksa kesalahan umum pertama - hilang titik koma atau tanda kurung, menggunakan koma bukan operator ekstraktor, dll.

Masalahnya datang ketika itu gagal. Saya sering tidak dapat melangkah dengan debugger karena ini adalah kesalahan sintaksis, dan saya sering tidak dapat bertanya kepada penulis karena dia sendiri tidak mengerti keputusan desain.

Bagaimana Anda biasanya membaca kode sumber orang lain? Apakah Anda membaca kode dari atas ke bawah, atau apakah Anda mengikuti setiap fungsi sesuai namanya? Bagaimana Anda tahu kapan harus mengatakan "Sudah waktunya untuk refactor?"


1
Saya akan mengatakan: jangan buang waktu Anda pada programmer buruk, bahkan ketika di perguruan tinggi ... kecuali Anda membebankan biaya untuk itu. Trik untuk sukses adalah: ambil $ mereka sambil membuat mereka terlihat bodoh.
Ayub

2
@ Pekerjaan: Ya, kami semua menulis kode yang buruk ketika kami memulai. Apakah mereka layak menghabiskan waktu tergantung pada apakah mereka peduli untuk bekerja sendiri dan meningkat.

@ Pekerjaan saya di sekolah menengah dan saya ingin memperlakukan teman-teman saya dengan benar. Sementara saya dapat melihat logika di balik memperlakukannya sebagai sebuah kompetisi, saya berusaha untuk menjadi orang yang lebih baik.
Maks.

5
Dan dengan cara ini Anda benar-benar menghilangkan persaingan sambil bersikap baik kepada mereka. Jika Anda menyelesaikan segalanya untuk mereka, Anda akan belajar banyak dan mereka tidak akan berdaya. (Di sisi lain, mereka akan mendapatkan gelar, yang dikombinasikan dengan kurangnya pengetahuan mereka berarti mereka mungkin akan langsung masuk ke manajemen. :))
biziclop

Jawaban:


22

Kiat pertama: gunakan IDE (atau editor yang sangat bagus :)) untuk menemukan kesalahan sintaksis, tanda kurung salah tempat, dan kesalahan sepele lainnya.

Langkah kedua: Atur otomatis semua kode dalam format yang Anda rasa nyaman. Anda akan berpikir ini tidak terlalu penting tetapi luar biasa, itu penting.

Jangan takut untuk mengubah nama variabel lokal jika nama mereka buruk. (Jika Anda memiliki akses ke sistem lengkap, Anda dapat mengganti nama apa saja dan Anda harus.)

Tambahkan komentar ke diri Anda ketika Anda menemukan apa fungsi / metode tertentu lakukan.

Sabar. Memahami kode alien tidak mudah tetapi selalu ada saat terobosan ketika sebagian besar potongan teka-teki tiba-tiba jatuh ke tempatnya. Sampai saat itu, semua itu adalah kerja keras dan pekerjaan yang membosankan. Kabar baiknya adalah bahwa dengan berlatih momen eureka ini akan datang lebih cepat.


Bagaimana saya bisa memformat ulang / mengganti nama sambil tetap menghormati penulis asli? Haruskah saya meninggalkan komentar mengatakan hal-hal seperti // Renamed to ABC for XYZ?
Maks.

3
@ Maxm Jawaban langsung adalah bahwa Anda tidak harus menghormati penulis asli. Kode bukanlah sebuah karya seni, dan jika tidak berfungsi, tentu saja tidak. Tapi Anda bisa memasukkan komentar seperti itu, jadi lebih mudah untuk menjelaskan kepada penulis asli apa yang Anda ubah dan mengapa. Mengapa sangat penting, sedapat mungkin, mendokumentasikan mengapa Anda melakukan sesuatu. Ini adalah jenis komentar yang paling berguna.
biziclop

6
@ Maxm - Anda menyalin file kode. Lakukan apa pun yang Anda inginkan lalu kembali dan bantu mereka memperbaiki masalah di sistem yang ada. Ya begitulah cara saya akan melakukannya.
Erin

@Maxpm, buat salinan kode dan jalankan melalui astyle ( astyle.sourceforge.net ) terlebih dahulu. Orang yang belajar bagaimana memprogram jarang memiliki gaya pengkodean yang konsisten. Melihat kode yang diformat dengan benar sangat membantu ketika secara visual "parsing" itu.
Vitor Py

1
@ Maxm, menyalin dan bekerja pada sistem Anda adalah yang terbaik tetapi bahkan jika Anda harus melakukannya di depan mereka (seperti jika mereka meminta Anda untuk datang dan membantu Anda) jika Anda perlu mengganti nama variabel, katakan saja kepada mereka bahwa Anda tidak melakukannya. dapat menulisnya, jadi tidak tahu apa yang semuanya lakukan sehingga Anda perlu mengubah nama untuk mencari tahu.
Dominique McDonnell

20

Bolehkah saya mengatakan bahwa saya pikir Anda mengambil pendekatan yang salah dengan ini. Jika orang-orang meminta bantuan Anda dengan kode mereka, saya pikir Anda memiliki tanggung jawab untuk berbalik dan mengatakan kepada mereka untuk memandu Anda membaca kode mereka. Anda dapat memperbaiki kesalahan mereka untuk mereka, dan mereka dapat mempelajari sesuatu (dengan cara menghafal), jika mereka dapat menemukan kesalahan mereka sendiri (dengan bantuan Anda) mereka cenderung belajar lebih banyak. Selain itu, Anda akan mendapatkan pengalaman yang lebih luas dengan bagaimana orang yang berbeda mendekati pengkodean (yang pada gilirannya akan memungkinkan Anda untuk membaca / memahami lebih banyak kode) - siklus yang baik ...;)


2
mengapa memilih bawah? ini sepertinya ide yang bagus.
Matt Ellen

Saya setuju. Tampak sangat aneh.
Michael K

@Matt ad Michael, drive-by-downvoters, tidak banyak yang bisa Anda lakukan saya kira ...
Nim

Sebuah ide yang bagus tetapi dalam kehidupan nyata Anda lebih cenderung diberi kode "yang berasal dari dukungan yang dipecat karena menonton film porno di kantor menulis delapan tahun yang lalu" dan kemudian apa, tidak ada yang lari ke sana. Ditambah apa nilai sebenarnya dari penjelasan yang diberikan oleh seseorang yang mungkin berjuang dengan dasar-dasarnya?
biziclop

Ini jawaban yang bagus. Mereka harus memiliki gagasan tentang apa yang menurut mereka seharusnya dilakukan oleh kode mereka atau paling tidak ingin melakukannya.
JeffO

3

Saya percaya kemampuan ini adalah campuran dari pengalaman dan hanya memiliki bakat untuk itu. Kami memiliki karyawan yang dapat memecahkan lebih atau kurang apa pun jika kami meminta mereka membuat sesuatu dari awal, sementara pada saat yang sama sama sekali tidak dapat menemukan bug yang jelas dalam potongan kode yang tidak mereka tulis. Dan, secara bersamaan, kami memiliki karyawan yang tidak akan kami percayai dengan sesuatu yang melebihi desain dasar, tetapi yang dapat menyelami kode orang lain dan melacak masalah dalam waktu singkat.

Yang mengatakan, cara untuk mendekati ini adalah dengan mengubah kode. Format ulang sesuai keinginan Anda, ubah nama variabel menjadi sesuatu yang masuk akal bagi Anda, tambahkan komentar jika kode tidak jelas. Jika dia meminta bantuan Anda, Anda harus melanjutkan dan mengubah beberapa hal sampai Anda menemukan masalah. Kemudian serahkan kepada teman Anda apakah akan memperbaiki kode asli atau menggunakan kode Anda.


+1 - Mengembangkan kode dan melacak bug yang ditulis oleh orang lain adalah 2 keahlian yang sangat berbeda. Pengusaha tidak menghargai apa yang mereka miliki ketika mereka menemukan seseorang yang dapat melakukan keduanya dengan sangat baik.
Dunk

2

Pertama, jika ada kesalahan sintaks, Anda hanya perlu membaca kesalahan kompiler dengan hati-hati. Sering garis disorot sebagai kesalahan, tapi itu benar-benar sebelumnya baris yang memiliki kesalahan.

Sadarilah bahwa, untuk siswa pengantar, mungkin ada beberapa artefak pengeditan yang akan mencegah program dikompilasi yang tidak dapat dilihat. Misalnya, saya pernah melihat seorang siswa (bukan salah satu dari saya) yang menggunakan bilah spasi alih-alih kembali: Kodenya tampak normal pada editor yang dibungkus setelah 80 kolom (siswa sangat sabar), dan kode itu bahkan berfungsi sampai dia menambahkan //komentar gaya " ", yang mengomentari semua sisa program. Demikian pula, jika Anda menyalin sampel kode dari situs web, sering kali ada karakter yang tidak dapat dicetak yang juga disalin (tergantung bagaimana situs web memformat kode). Jika ragu, ketikkan ulang baris tanpa salin dan tempel. [Agak luar biasa, tapi aku melihat ini terjadi jauh lebih belakangan.]

Untuk kesalahan kompiler jahat, Anda mungkin harus menumbuhkan program, dengan membuat file baru dan mengetik semua kode saat Anda melanjutkan. Pastikan untuk mengkompilasi setelah setiap langkah utama sebelum melanjutkan ke langkah berikutnya.

OK, jadi bagaimana kalau tidak ada kesalahan sintaks? Maka sekarang saatnya untuk menelusuri kode! Anda dapat menggunakan debugger untuk ini, tetapi melakukan panggilan ke printfseluruh kode juga sangat efektif. Misalnya, jika ada forloop, tambahkan pernyataan cetak untuk penghitung loop. Dalam kasus forloop bersarang , Anda mungkin menemukan bahwa variabel yang salah sedang bertambah.

Keuntungan menggunakan printfs adalah kemampuannya untuk "memampatkan" dari waktu ke waktu / ruang yang sedang Anda lihat. Ketika Anda melangkah dengan debugger, Anda juga melihat banyak kondisi yang tidak relevan dan itu bisa lebih membosankan. Juga, tanpa melihat riwayat apa yang telah dicetak ke konsol, Anda mungkin kehilangan beberapa pola. Intinya di sini adalah bahwa debugger dan printfs adalah teknik yang saling melengkapi, dan tidak ada yang selalu lebih baik dari yang lain.

Akhirnya, tanyakan saja kepada teman Anda apa yang terjadi! Alih-alih melihat itu dan berkata "eh" tanyakan kepada mereka apa yang mereka lakukan: "sekarang apa yang nharus dilakukan?" Dengan memulai dialog, mereka mungkin akhirnya menjawab pertanyaan mereka sendiri, atau, Anda mungkin menyadari cara mereka membuat konsep program memiliki kelemahan, yang dapat mengarahkan Anda ke solusi.

Seperti yang dikomentari di tempat lain, semua ini menjadi lebih baik dengan pengalaman. Meskipun saya telah pemrograman selama 20 tahun, tidak sampai 5 tahun terakhir saya telah bekerja dengan siswa bahwa saya menjadi lebih baik dalam membantu mereka dengan kesalahan mereka.


1

Aku benci mengatakan ini, tapi tidak ada peluru perak di sini.

Terus terang jika saya peramal cukup untuk dapat memahami apa yang orang lain maksudkan ketika mereka menulis apa yang mereka lakukan bahkan dalam 10% dari kasus, saya akan tanpa keraguan membuat jutaan sekarang.

Pada catatan yang lebih praktis, menggunakan IDE yang cerdas adalah langkah 1.

Langkah 2 adalah menjalankan doxygen atau yang serupa untuk mengetahui hierarki kode sumber.

Langkah 3 adalah untuk mengetahui fungsi jangkar atau objek, hal-hal yang memproses baris perintah atau file Anda dan kemudian melakukan logika.

Sejalan dengan Langkah 3, pantau global jika Anda menggunakannya. Tanyakan juga kepada teman Anda apakah mereka menggunakan algoritma spesifik yang dikenal - membaca algoritme (jika ada) sebelum melihat kode selalu bermanfaat.


1

Dalam satu kata: Pengalaman, semakin Anda mendapatkan pengalaman, semakin banyak Anda mempelajari praktik terbaik dan dapat menilai / memahami kode orang lain. Itu tidak datang secara otomatis, melainkan sering hanya berasal dari melakukan kesalahan yang sama sendiri!

Yang mengatakan, sangat penting bahwa programmer belajar untuk mengomentari kode mereka dengan benar karena ketika Anda melihat kode itu sering hanya merupakan hasil dari proses pemikiran utama yang sering sangat sulit untuk diekstrapolasi dari kode. Beberapa komentar, file teks dengan pemikiran desain dapat membuat perbedaan antara memahami kode dan benar-benar salah paham.


1

Saya sering ditanya hal yang sama di lab di sekolah. Biasanya pertanyaan dimulai dengan, "Bagaimana cara memperbaiki kesalahan kompiler ini?" jadi saya cukup pandai melihat menggantung else, kehilangan titik koma dan sejenisnya. (Macro juga menyenangkan untuk debug - #define CUBE(x) x * x * xadalah kesalahan yang kita semua ditakdirkan untuk membuat.) Keuntungan yang saya miliki adalah bahwa saya telah melalui kelas yang sama dengan guru yang sama, jadi saya sudah terbiasa dengan persyaratan.

Proses yang saya temukan berfungsi paling baik adalah menjaga dialog tetap berjalan. Anda tidak ingin menulis program untuk mereka, karena merekalah yang perlu belajar. Ini berarti Anda harus berada di komputer yang sama dengan mereka. Di lab saya akan datang ke komputer mereka. Saya akan mencoba untuk membuat mereka menemukan kesalahan, dengan memulai dengan pesan kompiler. (Kami menggunakan C.) Mulai dengan nomor baris, dan tunjukkan di mana pesan dan kesalahan sesuai. Jika ada lebih dari satu kesalahan yang sama, saya akan bertanya kepada mereka apa yang mirip dengan kedua kesalahan itu.

Seluruh ide adalah untuk membantu membimbing siswa lainnya. Menulis ulang kode mereka untuk mereka tidak akan membantu mereka belajar.


apa yang salah dengan #define CUBE(x) x * x * xselain tipe-tidak aman?
Ayub

Ketika dipanggil seperti CUBE(3), tidak apa-apa. Sebut dengan CUBE(x + 1)dan Anda mendapatkan x + 1 * x + 1 * x + 1yang di C dievaluasi x + (1 * x) + (1 * x) + 1. Ini mengevaluasi 3x + 1yang bukan x <sup> 3 </sup>! Anda memperbaikinya dengan menyatakan #define CUBE(x) (x) * (x) * (x).
Michael K

0

Kesalahan sintaksis jauh lebih mudah ditemukan daripada kesalahan logika. Jika sebagian besar masalah mereka adalah sintaksis, cari IDE, salin dan tempel kode mereka ke dalamnya, dan perbaiki kesalahannya. Kesalahan logika jauh lebih sulit. Saya tidak yakin mengapa Anda mengatakan Anda tidak dapat meminta mereka menjelaskan kode mereka. Saya telah menemukan banyak kesalahan logika dengan menjelaskan kode kepada orang lain.

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.