Kapan saya akan menggunakan pseudocode, bukan flowchart?


9

Saya seorang siswa yang bekerja dengan berbagai teknik pemrograman, dan saya telah menemukan pseudocode dan flowchart. Saya tahu bahwa keduanya digunakan untuk memikirkan masalah sebelum benar-benar pemrograman, tapi saya punya beberapa pertanyaan dengan ini.

  1. Kapan saya akan menggunakan pseudocode untuk merencanakan dan kapan saya akan menggunakan diagram alur? Atau lebih baik melakukan keduanya sebelum benar-benar pemrograman. Khususnya untuk jenis permainan arcade kecil di JAWA karena itu adalah proyek saya berikutnya.
  2. Saya perhatikan bahwa pseudocode sangat mirip dengan kode aktual daripada diagram alur. Apakah ini membuat pseudocoding lebih baik karena pada dasarnya Anda menyalin / menempelkan pseudocode ke program Anda (tentu saja, Anda harus mengubahnya agar sesuai dengan bahasa. Saya mengerti bagian itu).
  3. Apakah praktis untuk menggunakan keduanya saat pemrograman? Terutama game yang sama yang disebutkan sebelumnya. Terima kasih.

Jelas, Anda tidak akan menggunakan diagram alur di mana Anda tidak memiliki aliran - yaitu, untuk hampir semua entitas deklaratif.
SK-logic

1
Saya benar-benar tidak ingat kapan terakhir kali saya melihat diagram alur pengkodean. Diagram kelas dan aliran data, diagram use-case, ya. Tapi tidak bagan alur. Mungkin mereka lebih lazim dalam pengembangan game.
Robert Harvey

@RobertHarvey, diagram FSM (yang, pada dasarnya, diagram alur) cukup sering digunakan dalam desain perangkat keras
SK-logic

Jawaban:


7

Flowchart dan pseudocode sering memiliki tingkat ekspresi yang sama, tetapi berbeda dalam linierisasi. Pseudocode adalah linier (yaitu urutan garis dengan instruksi), diagram alur tidak. Oleh karena itu, diagram alur adalah tingkat abstraksi yang lebih tinggi, digunakan sebelum menulis kodesemu atau untuk dokumentasi.

Diagram alir, menurut saya, memiliki dua keunggulan kuat dibanding pseudocode: Pertama, mereka berbasis grafik. Banyak orang non-teknis memiliki ketakutan yang kuat terhadap teks terstruktur, tetapi tidak pada deskripsi grafis, sehingga diagram alur akan jauh lebih baik dengan mereka. Kedua, diagram alur jauh lebih baik dalam mengekspresikan pertimbangan meta seperti menunjukkan jalur utama pelaksanaan dibandingkan dengan cabang.

Pertanyaan Anda secara terperinci:

  1. Untuk masalah yang sangat rumit, Anda harus menggunakan diagram alur terlebih dahulu, kemudian pseudocode. Keduanya opsional ketika Anda merasa cukup aman.
  2. Ya, pseudocode memiliki keuntungan karena dapat digabung dengan kode asli. Steve McConnell, misalnya, sangat merekomendasikan metode penulisan dalam pseudocode terlebih dahulu dan kemudian meninggalkan pseudocode dalam kode sebagai komentar.
  3. Saya selalu merasa bahwa kebutuhan untuk menggambar diagram alur selama desain menunjukkan tidak cukupnya partisi masalah Anda. Diagram alir non-sepele menunjukkan logika berbelit-belit, yang harus dihindari dengan biaya besar.

1
Diagram alir juga merupakan cara yang bagus untuk memastikan bahwa setiap titik keputusan menentukan tindakan untuk jalur yang kurang umum serta yang paling umum. Ini membantu memastikan Anda akan tahu apa yang harus dilakukan ketika persetujuan ditolak atau pesanan dibatalkan! Seringkali ada lebih banyak bug dalam kasus tepi karena orang lupa untuk melakukannya atau terburu-buru selama QA ketika pengujian menemukan mereka.
HLGEM

2

Pada Kode Pseudo

Sejujurnya, saya tidak menggunakan pseudocode banyak. Biasanya lebih cepat menulis kode saja, sehingga ketika saya selesai dengan kode saya, itu adalah kode aktual. Ada beberapa kasus ketika kode pseudo mungkin membantu, tetapi Anda biasanya mengerjakan sesuatu yang sangat kompleks dan hanya mencoba memecah struktur metode atau sesuatu. Dalam kasus itu, saya menggunakan komentar di IDE saya untuk meletakkan struktur sampai saya mendapatkan hal yang benar. Lalu, saya masuk dan menulis kode aktual di komentar. Ini membantu saya melakukan beberapa hal:

  • Saya dapat melihat area yang saya miliki dan belum diimplementasikan dengan membaca komentar dan melihat celah yang jelas di dalamnya.
  • Ketika saya mengisi kode asli, saya memiliki komentar yang menjelaskan dalam bahasa Inggris apa yang saya lakukan. (Mereka mungkin akan membutuhkannya jika sangat rumit sehingga saya perlu menulis kode pseudo terlebih dahulu).

Di Bagan Alir

Kode biasanya berubah sangat banyak sehingga diagram alur tidak membantu kecuali untuk desain arsitektur atau dokumentasi yang lebih besar dan lebih luas. Dalam kasus-kasus itu saya hanya akan menulis papan tulis diagram untuk mendapatkan intisari hal-hal atau untuk menunjukkan kepada orang lain di tim. Kecuali Anda benar-benar membutuhkan diagram alur untuk membantu Anda memahami, maka Anda tidak benar-benar membutuhkannya untuk "melakukan" perangkat lunak dengan benar. Saat ini, ada banyak plugin untuk IDE yang akan menghasilkan diagram alur dari kode itu sendiri, serta diagram kelas dan lainnya (dan sebaliknya `). Satu-satunya waktu nyata yang Anda perlukan untuk membuat diagram alur yang benar-benar akurat adalah jika Anda tidak dapat mempertahankan seluruh arsitektur dan bagaimana segala sesuatunya bekerja di kepala Anda sekaligus dan perlu berbicara melalui sesuatu yang visual untuk menangkap kerutan.


0

Secara umum saya tidak menulis Flowchart ketika saya sedang mengerjakan proyek pribadi (karena proyek tidak terlalu besar) dan sebagian besar input, output dan proses jelas.

tetapi karena Anda akan mulai bekerja pada proyek-proyek besar yang kompleks dengan berbagai sumber input file flat, database, antarmuka manual, dll, diagram alur sangat berguna.

Saya akan merekomendasikan Anda menulis kode Pseudo dan UML digram karena alat ini akan membantu Anda menghasilkan kelas yang lebih baik, metode dll. Kadang-kadang saat menulis kode pseudo Anda akan menemukan cara yang berbeda dan lebih efisien untuk menyelesaikan suatu program.


0

Kode pseudo adalah untuk dengan cepat mewakili ide kepada mereka yang mengerti setidaknya dasar-dasar kode. Flowchart adalah fr menggambar gambar-gambar cantik untuk semua orang untuk memahami hal yang sama.

Diagram alir sering digunakan untuk tujuan dokumentasi karena banyak orang yang berbeda menggunakan dokumentasi dan diagram alur yang lebih mudah diikuti daripada kode pseudo untuk yang bukan programmer. Dalam sebuah proyek yang sedang Anda kerjakan sendiri dengan menggunakan kode pseudo baik-baik saja karena jauh lebih berguna dan jauh lebih mudah dibuat karena hanya editor teks yang Anda butuhkan.


0

Diagram alir adalah abstraksi tingkat tinggi yang memungkinkan Anda merencanakan bagaimana hal-hal harus berjalan, misalnya

jika x mati kamu menang

Mereka tidak perlu bergantung pada bagaimana Anda merancang program dalam hal kelas dan metode, kode pseudo di sisi lain memberikan tingkat abstraksi yang lebih rendah (meskipun itu benar-benar tergantung)

if (isdead) y.win ()

dengan demikian kode pseudo sekarang dapat diterjemahkan ke dalam program aktual berdasarkan bahasa yang Anda gunakan.

Untuk permainan, saya akan merekomendasikan menggunakan diagram alur terlebih dahulu, kemudian merancang kelas dan metode, menulis kode pseudo dan akhirnya mengubahnya menjadi sebuah program


0

Saya akan mempertimbangkan sifat kode yang Anda tulis. Jika memang:

  1. Sangat berulang / rekursif
  2. Cabang dengan cara yang rumit
  3. Diimplementasikan dalam beberapa sistem, yang ingin Anda wakili

Dalam dua kasus pertama, kodesemu menjadi semakin sulit dibaca daripada diagram gambar besar. Di sisi lain, kode yang sebagian besar linier membuat diagram yang sangat membosankan yang sebenarnya membuat proses lebih sulit untuk dipahami karena seberapa banyak pukulan itu.

Untuk kasus ketiga, diagram alur lebih baik dalam mewakili proses yang melintasi batas sistem dan mewakili seluruh proses.


0
  1. Anda harus menggunakan apa pun yang Anda rasa nyaman. Yang mengatakan, kesan saya adalah bahwa diagram alur tidak banyak digunakan untuk membuat sketsa kontrol program hari ini; untuk satu hal, mereka biasanya tidak terstruktur, dibandingkan dengan pseudocode. Lebih umum menggunakan diagram dependensi kelas seperti UML, untuk menggambarkan arsitektur Anda pada level yang jauh lebih tinggi. Juga, jika aplikasi Anda memiliki mesin keadaan, menggambar diagram mesin keadaan (seperti flowchart) sangat penting.
  2. Saya pikir Anda benar di sini. Salah satu cara untuk bekerja adalah dengan menuliskan pseudocode Anda sebagai komentar di file sumber Anda untuk memulai, dan masukkan baris implementasi aktual di antara mereka.
  3. Sekali lagi, gunakan apa pun yang Anda rasa nyaman. Jika Anda tidak yakin, cobalah keduanya; Saya berharap latihan Anda akan segera menyatu pada apa pun yang paling berguna bagi Anda. Saya pribadi tidak menemukan diagram alur berguna kecuali saya mencoba untuk menguraikan urutan eksekusi yang sangat rumit.

0

Mengapa menulis kode palsu ketika Anda bisa menulis Java? Saya telah menemukan Java, IDE yang bagus, dan Javadoc adalah cara termudah untuk memahami masalah pemrograman - setidaknya yang Berorientasi Objek . (Dan gim arcade seharusnya OO.) Bahasa dirancang dari bawah ke atas untuk ini. Sederhana dan mudah. (Terlalu sederhana untuk banyak tujuan, mungkin, tetapi hal terbaik yang pernah saya lihat untuk ini.) Hiperteks di Javadoc dan, melalui IDE, dalam kode itu sendiri membuat "diagram" yang lebih dimengerti daripada yang bisa Anda gambarkan bahkan selembar kertas besar. Kode Java sesederhana kode pseudo apa pun dan jauh lebih ketat. Dan begitu Anda sudah mendapatkan kode "diagram" dan "pseudo", program akan benar-benar berjalan!


1
java dan yang lainnya bisa jadi bertele-tele. "public static void main .." atau "system.out.println" atau pengidentifikasi panjang dengan notasi camelback, panjang bertele-tele di sana.n lalu pengecualian yang memiliki 2b ditangkap .. Dan memanggil perpustakaan dapat panjang lebar. Saya ingat 10 tahun yang lalu membuka file. sesuatu seperti BufferedReader baru (InputStreamReader baru (System.in)); rupanya lebih mudah sekarang mkyong.com/java/... Tapi sebenarnya perpustakaan yang Anda panggil bisa lama bertele-tele, tidak seperti pseudocode yang bisa sesingkat yang Anda bayangkan
barlop

juga dalam java atau bahasa apa pun, Anda menemukan kesalahan pada kompilasi. tidak ada yang dengan pseudocode. Anda bisa fokus pada desain tanpa gangguan. Komentar pada pseudocode bisa jauh lebih singkat karena pseudocode lebih jelas bagi pikiran karena itu berasal dari pikiran. Anda tidak dibatasi oleh berpikir hanya dalam satu bahasa, dan Anda mungkin melihat ah saya akan menggunakan bahasa lain ini. Lebih cepat dan tidak terlalu menyakitkan untuk menulis (tidak diperlukan kompilasi - bahkan yang sangat fasih mendapatkan kesalahan kompilasi) sehingga lebih sedikit waktu untuk menulis membuatnya lebih mudah untuk dirancang ulang.
barlop

@barlop: Ini berfungsi untuk saya, tetapi mungkin tidak berhasil untuk semua orang. Saya meninggalkan banyak kode ("BufferedReader", misalnya) dari kelas saya sampai saya membutuhkannya atau perlu tahu apakah saya dapat membuatnya bekerja. Bahkan ketika saya memilikinya, tersimpan dengan baik di kelas saya tidak perlu melihat ketika mempertimbangkan desain keseluruhan. Kesalahan kompiler mudah diperbaiki dan dapat mencegah cacat desain utama, seperti menggunakan kelas yang salah pada titik di mana Anda bahkan tidak bisa mendapatkan turunan dari kelas yang tepat. Saya akui, saya telah "dirancang" software cara ini yang bisa hanya ditulis di Jawa, tetapi OP adalah menggunakan Java.
RalphChapin

jadi katakan Anda ingin membuka file, apakah Anda melihat bagaimana pseudocode dari openfile ("c: \ blah \ file") lebih pendek daripada java untuk melakukannya? atau bahwa cetak "dfdfd" lebih pendek dari java untuk melakukannya? Saya belum pernah melakukan (belum) halaman pseudocode dan beberapa kelas. sebagian karena saya belum menulis program besar di usia b) sebagian karena saya tidak berpikir saya akan melakukannya, saya pikir saya akan menulis beberapa pseudocode kemudian mengimplementasikannya. Kode pseudocode lain jika ada, akan menjadi level yang lebih tinggi. Saya mungkin punya daftar semua kelas dan metode termasuk konstruktor. Jadi saya tahu kelas apa itu dan saya bisa mendapatkan contohnya ..
barlop

jadi saya tidak akan berada dalam situasi menggunakan kelas yang salah tetapi bagaimanapun, jika itu adalah program saya, saya akan menulis di catatan saya apa kelasnya apa .. kelasnya cukup tinggi. Saya akan memiliki catatan tentang itu jika saya tidak dapat mengingatnya. Dan pseudocode adalah semua tentang apa yang seseorang maksudkan, jadi jika Anda bermaksud membuat turunan dari kelas bla dan Anda menulisnya, maka itu hanya kesalahan penulisan tetapi tidak menghalangi desain Anda. (jika Anda menulis untuk diri sendiri karena Anda tahu apa yang Anda maksud, dan Anda menggunakannya seperti bla).
barlop

0

Anda bisa menggunakan diagram alur jika Anda benar-benar bingung dengan pernyataan if dan Anda mencoba memahaminya. Atau jika Anda mencoba memahami sebuah loop, lihat efek penghitung. Jika Anda belajar, ini bisa banyak membantu.

Ini bisa terasa agak membatasi karena Anda harus memasukkan pernyataan singkat ke dalam kotak. Dan jika program Anda sangat linier dan loop Anda dan jika sepele, maka saya tidak melihat gunanya.

Pseudocode berguna untuk merancang program. Tanpa gangguan karena harus mendapatkan sintaks yang benar, dan tanpa panjang lebar yang melibatkan beberapa bahasa. Fakta bahwa lebih cepat menulis juga memudahkan mendesain ulang kode. Dan Anda bisa sesingkat yang diinginkan oleh pikiran Anda, menyenangkan untuk menulis, membutuhkan sedikit upaya mental untuk membuatnya bekerja (karena tidak ada atau lebih sedikit debugging), dan lebih banyak kemampuan untuk fokus pada gambaran besar dan desain.

Jadi, bermanfaat untuk diri sendiri.

Mereka juga dapat digunakan untuk berkomunikasi dengan 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.