เมื่อใดที่ฉันจะใช้ pseudocode แทนผังงาน

9

ฉันเป็นนักเรียนที่ทำงานกับเทคนิคการเขียนโปรแกรมที่หลากหลายและฉันเจอ pseudocode และผังงาน ฉันรู้ว่าสิ่งเหล่านี้ถูกใช้เพื่อคิดผ่านปัญหาก่อนการเขียนโปรแกรมจริง แต่ฉันมีคำถามสองสามข้อนี้

ฉันจะใช้ pseudocode เพื่อวางแผนและเมื่อใดฉันจะใช้ผังงาน หรือดีกว่าที่จะทำทั้งสองอย่างก่อนการเขียนโปรแกรมจริง โดยเฉพาะอย่างยิ่งสำหรับเกมอาร์เคดขนาดเล็กใน JAVA เนื่องจากเป็นโปรเจ็กต์ต่อไปของฉัน
ฉันสังเกตว่ารหัสเทียมคล้ายกับรหัสจริงมากกว่าผังงาน สิ่งนี้จะทำให้การเข้ารหัสเทียมดีขึ้นหรือไม่เพราะคุณต้องคัดลอก / วางรหัสเทียมลงในโปรแกรมของคุณ (แน่นอนคุณต้องเปลี่ยนให้เหมาะกับภาษาฉันเข้าใจส่วนนั้น)
เป็นจริงหรือไม่ที่จะใช้ทั้งสองอย่างนี้ในขณะที่เขียนโปรแกรม? โดยเฉพาะเกมเดียวกันที่กล่าวถึงก่อนหน้านี้ ขอบคุณ

java flowchart pseudocode

— kullalok
แหล่งที่มา

เห็นได้ชัดว่าคุณจะไม่ใช้ผังงานที่ไม่มีกระแส - เช่นสำหรับหน่วยงานที่เปิดเผยเกือบทั้งหมด

— SK-logic

1

ฉันจำไม่ได้ว่าครั้งสุดท้ายที่ฉันเห็นผังการเข้ารหัส คลาสและไดอะแกรมการไหลของข้อมูลไดอะแกรมกรณีการใช้ใช่ แต่ไม่ใช่ผังงาน บางทีพวกเขาจะแพร่หลายมากขึ้นในการพัฒนาเกม

— Robert Harvey

@ RobertHarvey, ไดอะแกรม FSM (ซึ่งโดยพื้นฐานแล้วเป็นผังงาน) มักใช้ในการออกแบบฮาร์ดแวร์

— SK-logic

7

ผังงานและ pseudocode มักจะมีระดับของการแสดงออกที่เหมือนกัน แต่แตกต่างกันในการทำเส้นตรง Pseudocode เป็นแบบเชิงเส้น (เช่นลำดับของบรรทัดที่มีคำแนะนำ) ผังงานไม่ได้ ดังนั้นผังงานเป็นระดับนามธรรมที่สูงกว่าใช้ก่อนที่จะเขียน pseudocode หรือเอกสารประกอบ

ในความคิดของฉันผังงานมีสองข้อได้เปรียบที่แข็งแกร่งกว่า pseudocode: ประการแรกพวกเขาเป็นกราฟิก คนที่ไม่ใช่ด้านเทคนิคหลายคนมีความกลัวอย่างมากต่อข้อความที่มีโครงสร้าง แต่ไม่ใช่คำอธิบายเชิงกราฟิกดังนั้นผังงานจะนั่งได้ดีกว่ามาก ประการที่สองผังงานจะดีกว่ามากในการแสดงเมตา - ข้อพิจารณาเช่นการแสดงบรรทัดหลักของการดำเนินการเมื่อเทียบกับสาขา

คำถามของคุณในรายละเอียด:

สำหรับปัญหาที่ซับซ้อนมากคุณต้องใช้ผังงานก่อนจากนั้นจึงใช้ pseudocode ทั้งสองเป็นทางเลือกเมื่อคุณรู้สึกปลอดภัยเพียงพอ
ใช่ pseudocode มีข้อดีของการรวมเข้ากับรหัสจริง ตัวอย่างเช่น Steve McConnell แนะนำอย่างยิ่งให้วิธีการเขียนใน pseudocode ก่อนจากนั้นปล่อย pseudocode ในรหัสเป็นความคิดเห็น
ฉันมักจะรู้สึกว่าจำเป็นต้องวาดผังงานในระหว่างการออกแบบแสดงพาร์ทิชันไม่เพียงพอของปัญหาของคุณ ผังงานที่ไม่ใช่เรื่องไร้สาระบ่งบอกถึงตรรกะที่ซับซ้อนซึ่งควรหลีกเลี่ยงในราคาที่คุ้มค่า

— thiton
แหล่งที่มา

1

แผนภูมิการไหลยังเป็นวิธีที่ดีในการตรวจสอบให้แน่ใจว่าการตัดสินใจทุกจุดกำหนดการกระทำสำหรับเส้นทางที่พบได้น้อยกว่าและเส้นทางที่พบได้บ่อยที่สุด สิ่งนี้จะช่วยให้แน่ใจว่าคุณจะรู้ว่าต้องทำอย่างไรเมื่อการอนุมัติถูกปฏิเสธหรือคำสั่งนั้นถูกยกเลิก! มักจะมีข้อบกพร่องมากขึ้นในกรณีขอบเพราะคนลืมที่จะทำพวกเขาหรือทำอย่างเร่งด่วนในช่วง QA เมื่อการทดสอบพบพวกเขา

— HLGEM

2

ในรหัสหลอก

พูดตามตรงฉันไม่ได้ใช้ pseudocode มาก โดยทั่วไปแล้วมันเร็วกว่าที่จะเขียนรหัสดังนั้นเมื่อฉันทำกับรหัสของฉันมันเป็นรหัสจริง มีบางกรณีที่รหัสหลอกอาจเป็นประโยชน์ แต่โดยทั่วไปคุณกำลังทำงานกับสิ่งที่ซับซ้อนมากและเพียงพยายามที่จะทำลายโครงสร้างของวิธีการหรือบางสิ่งบางอย่าง ในกรณีเหล่านั้นฉันใช้ความคิดเห็นใน IDE ของฉันเพื่อจัดโครงสร้างจนกว่าฉันจะได้รับสิ่งที่ถูกต้อง จากนั้นฉันไปและเขียนรหัสจริงในความคิดเห็น สิ่งนี้ช่วยให้ฉันทำบางสิ่ง:

ฉันสามารถดูพื้นที่ที่ฉันมีและยังไม่ได้ใช้งานโดยการอ่านความคิดเห็นและเห็นช่องว่างที่ชัดเจนในพวกเขา
เมื่อฉันกรอกรหัสจริงฉันมีความคิดเห็นอธิบายเป็นภาษาอังกฤษว่าฉันกำลังทำอะไร (พวกเขาอาจต้องการมันถ้ามันซับซ้อนมากจนฉันต้องเขียนโค้ดหลอกก่อน)

บนผังงาน

โดยทั่วไปแล้วรหัสจะเปลี่ยนไปมากจนทำให้ผังงานไม่มีประโยชน์ยกเว้นการออกแบบสถาปัตยกรรมหรือเอกสารที่มีขนาดใหญ่ขึ้นและกว้างขึ้น ในกรณีเหล่านั้นฉันจะเขียนกระดานไวท์บอร์ดเพื่อรับส่วนสำคัญหรือแสดงให้คนอื่นเห็นในทีม ถ้าคุณไม่จำเป็นต้องมีแผนผังลำดับงานเพื่อช่วยให้คุณเข้าใจคุณไม่จำเป็นต้องใช้ซอฟต์แวร์เหล่านั้นเพื่อ "ทำ" ทุกวันนี้มีปลั๊กอินจำนวนมากสำหรับ IDEsที่จะสร้างผังงานจากโค้ดรวมถึงแผนภาพคลาสและอื่น ๆ (และในทางกลับกัน ) เรียลไทม์เดียวที่คุณต้องทำแผนผังลำดับงานที่แม่นยำอย่างจริงจังคือถ้าคุณไม่สามารถรักษาทั้งสถาปัตยกรรมและวิธีการทำงานของสิ่งต่าง ๆ ในหัวของคุณในครั้งเดียวและจำเป็นต้องพูดถึงบางสิ่งบางอย่าง

— Ryan Hayes
แหล่งที่มา

0

โดยทั่วไปฉันไม่ได้เขียนผังงานในขณะที่ฉันกำลังทำงานในโครงการส่วนบุคคล (เนื่องจากโครงการไม่ใหญ่มาก) และอินพุต, ผลลัพธ์และกระบวนการส่วนใหญ่นั้นชัดเจน

แต่ในขณะที่คุณจะเริ่มทำงานกับโครงการขนาดใหญ่ที่ซับซ้อนที่มีแหล่งอินพุตที่แตกต่างกันไฟล์แบน, ฐานข้อมูล, อินเทอร์เฟซแบบแมนนวล ฯลฯ ผังงานมีประโยชน์

ฉันขอแนะนำให้คุณเขียนโค้ดหลอกและดิจิตัล UML เนื่องจากเครื่องมือเหล่านี้จะช่วยให้คุณเรียนได้ดีขึ้นวิธีการและอื่น ๆ บางครั้งในขณะที่เขียนโค้ดหลอกคุณจะพบวิธีที่แตกต่างและมีประสิทธิภาพมากขึ้นในการแก้โปรแกรม

— CodeCracker
แหล่งที่มา

0

โค้ดหลอกใช้สำหรับแสดงความคิดต่อผู้ที่เข้าใจอย่างน้อยพื้นฐานของโค้ด ผังงานกำลังวาดภาพสวย ๆ ให้ทุกคนได้เข้าใจในสิ่งเดียวกัน

แผนภูมิลำดับงานมักใช้เพื่อวัตถุประสงค์ด้านเอกสารเนื่องจากผู้ใช้หลายคนใช้เอกสารและผังงานได้ง่ายกว่ารหัสหลอกสำหรับโปรแกรมเมอร์ที่ไม่ใช่ ในโครงการที่คุณกำลังทำงานด้วยตัวคุณเองโดยใช้โค้ดหลอกก็ดีเพราะมันมีประโยชน์มากกว่าและง่ายกว่ามากในการสร้างเนื่องจากตัวแก้ไขข้อความเป็นสิ่งที่คุณต้องการ

— Ryathal
แหล่งที่มา

0

ผังงานเป็นสิ่งที่เป็นนามธรรมในระดับสูงซึ่งช่วยให้คุณวางแผนว่าจะดำเนินการอย่างไรต่อไปตัวอย่างเช่น

ถ้า x ตาย y ชนะ

พวกเขาไม่จำเป็นต้องขึ้นอยู่กับว่าคุณออกแบบโปรแกรมในแง่ของคลาสและวิธีการอย่างไรโค้ดหลอกในทางกลับกันให้ระดับที่ต่ำกว่าของนามธรรม (แม้ว่ามันจะขึ้นอยู่กับมันจริงๆ)

ถ้า (isdead) y.win ()

ดังนั้นโค้ดหลอกสามารถแปลเป็นโปรแกรมจริงตามภาษาที่คุณใช้

สำหรับเกมที่ฉันอยากจะแนะนำให้ใช้ผังงานก่อนจากนั้นออกแบบคลาสและวิธีการเขียนโค้ดหลอกและในที่สุดก็แปลงมันเป็นโปรแกรม

— nischayn22
แหล่งที่มา

0

ฉันจะพิจารณาลักษณะของรหัสที่คุณเขียน ถ้ามันเป็น:

วนซ้ำ / เวียนซ้ำสูง
สาขาในรูปแบบที่ซับซ้อน
นำไปใช้ในหลายระบบซึ่งคุณต้องการเป็นตัวแทน

ในสองกรณีแรก pseudocode จะยากต่อการอ่านมากกว่าแผนภาพรูปภาพขนาดใหญ่ ในทางกลับกันรหัสที่เป็นเชิงเส้นส่วนใหญ่จะทำให้ไดอะแกรมน่าเบื่ออย่างไม่น่าเชื่อซึ่งทำให้กระบวนการเข้าใจยากขึ้นเพราะมันระเบิดมากเพียงใด

สำหรับกรณีที่สามผังงานจะดีกว่าในการแสดงกระบวนการที่ข้ามขอบเขตของระบบและเป็นตัวแทนของกระบวนการทั้งหมด

— Chris Pitman
แหล่งที่มา

0

คุณควรใช้สิ่งที่คุณรู้สึกสบายใจ ที่กล่าวว่าความประทับใจของฉันคือผังงานที่ไม่ได้ใช้อย่างหนักเพื่อร่างการควบคุมโปรแกรมวันนี้; สำหรับสิ่งหนึ่งพวกเขามักจะไม่มีโครงสร้างเมื่อเทียบกับ pseudocode เป็นเรื่องปกติที่จะใช้ไดอะแกรมอ้างอิงคลาสเช่น UML เพื่ออธิบายสถาปัตยกรรมของคุณในระดับที่สูงขึ้นมาก นอกจากนี้หากแอปพลิเคชันของคุณมีเครื่องสถานะการวาดไดอะแกรมสถานะเครื่อง (เหมือนผังงาน) เป็นสิ่งจำเป็น
ฉันคิดว่าคุณถูกต้องที่นี่ วิธีหนึ่งในการทำงานคือการเขียนรหัสเทียมของคุณเป็นความคิดเห็นในซอร์สไฟล์ของคุณเพื่อเริ่มต้นและแทรกบรรทัดการนำไปใช้จริงระหว่างพวกเขา
ใช้สิ่งที่คุณรู้สึกสะดวกสบายอีกครั้ง หากคุณไม่แน่ใจลองทั้งคู่ ฉันคาดหวังว่าการฝึกฝนของคุณจะมาบรรจบกันอย่างรวดเร็วในสิ่งที่เป็นประโยชน์กับคุณ โดยส่วนตัวฉันไม่พบว่ามีผังงานที่มีประโยชน์เว้นแต่ฉันพยายามที่จะแก้ปัญหาคำสั่งการดำเนินการที่ซับซ้อนเป็นพิเศษ

— comingstorm
แหล่งที่มา

0

ทำไมต้องเขียนโค้ดหลอกเมื่อคุณสามารถเขียน Java ได้? ฉันได้พบชวา IDE ที่ดีและ Javadoc เป็นวิธีที่ง่ายที่สุดในการเข้าใจปัญหาการเขียนโปรแกรม - อย่างน้อยObject Orientedหนึ่ง (และเกมอาร์เคดควรจะเป็น OO) ภาษาได้รับการออกแบบมาตั้งแต่ต้นสำหรับเรื่องนี้ มันง่ายและตรงไปตรงมา (ง่ายเกินไปสำหรับวัตถุประสงค์หลายอย่าง แต่อาจเป็นสิ่งที่ดีที่สุดที่ฉันเคยเห็นมา) ไฮเปอร์เท็กซ์ใน Javadoc และผ่าน IDE ในโค้ดนั้นทำให้เป็น "ไดอะแกรม" ที่เข้าใจได้มากกว่าที่คุณสามารถวาดได้ กระดาษแผ่นใหญ่ โค้ด Java นั้นง่ายเหมือนโค้ดหลอก ๆ และมีความเข้มงวดมากขึ้น และเมื่อคุณได้รับมัน "แผนภาพ" และ "หลอก" รหัสโปรแกรมจะทำงานจริง!

— RalphChapin
แหล่งที่มา

1

java และอื่น ๆ สามารถยืดยาวได้ "public void main .. " หรือ "system.out.println" หรือตัวระบุแบบยาวที่มีเครื่องหมาย camelback, winded ยาวนั้นมีข้อยกเว้นที่มีการจับ 2b .. และการเรียกใช้ไลบรารีใด ๆ ยืดยาวฉันจำได้ 10 ปีที่แล้วเปิดไฟล์ สิ่งที่ต้องการ BufferedReader ใหม่ (InputStreamReader ใหม่ (System.in)); เห็นได้ชัดว่าง่ายขึ้นในขณะนี้mkyong.com/java/ แต่จริงๆแล้วห้องสมุดใด ๆ ที่คุณโทรติดต่ออาจยืดเยื้อไม่เหมือน pseudocode ซึ่งสามารถกระชับได้อย่างที่คุณจินตนาการ

— barlop

ในจาวาหรือภาษาใด ๆ คุณพบข้อผิดพลาดในการรวบรวม ไม่มีสิ่งใดด้วยรหัสเทียม คุณจะมุ่งเน้นไปที่การออกแบบโดยไม่มีสิ่งรบกวน ความคิดเห็นเกี่ยวกับ pseudocode นั้นสามารถสรุปได้สั้นกว่าเนื่องจาก pseudocode นั้นมีความชัดเจนในใจมากขึ้นเพราะมันมาจากจิตใจ คุณไม่ได้ถูก จำกัด ด้วยการคิดในภาษาเดียวและคุณอาจเห็นว่าฉันจะใช้ภาษาอื่นนี้ มันเร็วและเจ็บปวดน้อยกว่าในการเขียน (ไม่จำเป็นต้องมีการรวบรวม - แม้แต่ข้อผิดพลาดในการรวบรวมข้อผิดพลาดอย่างคล่องแคล่ว) และเวลาในการเขียนที่น้อยก็ทำให้การออกแบบใหม่ง่ายขึ้น

— barlop

@barlop: มันเหมาะกับฉัน แต่มันอาจจะไม่ได้ผลสำหรับทุกคน ฉันทิ้งโค้ดไว้จำนวนมาก (เช่น "BufferedReader") ออกจากคลาสจนกว่าฉันจะต้องการหรือต้องการทราบว่าฉันสามารถใช้งานได้หรือไม่ แม้ว่าฉันจะมีมันก็เก็บไว้อย่างดีในชั้นเรียนที่ฉันไม่จำเป็นต้องมองเมื่อพิจารณาการออกแบบโดยรวม ข้อผิดพลาดของคอมไพเลอร์ได้รับการแก้ไขอย่างง่ายดายและสามารถป้องกันข้อบกพร่องในการออกแบบที่สำคัญเช่นการใช้คลาสที่ไม่ถูกต้อง ณ จุดที่คุณไม่สามารถรับอินสแตนซ์ของคลาสที่เหมาะสมได้ ผมยอมรับว่าผมมี "การออกแบบซอฟต์แวร์" วิธีนี้ที่อาจเพียง แต่จะเขียนใน Java แต่สหกรณ์จะใช้ Java

— RalphChapin

ดังนั้นถ้าคุณต้องการเปิดไฟล์คุณเห็นว่า pseudocode ของ openfile ("c: \ blah \ file") นั้นสั้นกว่า java หรือไม่? หรือพิมพ์ "dfdfd" นั้นสั้นกว่า java เพื่อทำมัน? ฉันไม่เคยทำหน้า pseudocode และหลายคลาสมาก่อน ส่วนหนึ่ง 'เพราะฉันไม่ได้เขียนโปรแกรมใหญ่ในวัยข) บางส่วน' เพราะฉันไม่คิดว่าฉันจะทำฉันคิดว่าฉันจะเขียนรหัสปลอมบางส่วนจากนั้นจึงนำไปใช้งาน รหัสเทียมอื่น ๆ หากมีจะเป็นระดับที่สูงขึ้น ฉันอาจมีรายการของคลาสและวิธีการทั้งหมดรวมถึงตัวสร้าง ดังนั้นฉันจึงรู้ว่าคลาสเรียนคืออะไรและฉันสามารถรับอินสแตนซ์ของมันได้บ้าง ..

— barlop

ดังนั้นฉันจะไม่อยู่ในสถานการณ์ที่ใช้คลาสที่ไม่ถูกต้อง แต่ถ้าเป็นโปรแกรมของฉันฉันได้เขียนลงในบันทึกย่อของฉันว่าคลาสคืออะไร .. คลาสนั้นค่อนข้างสูง ฉันต้องการทราบว่าถ้าฉันจำไม่ได้ และ pseudocode นั้นเกี่ยวกับความหมายเดียวดังนั้นถ้าคุณตั้งใจทำตัวอย่างของคลาส blah และคุณเขียน bleh มันก็แค่การเขียนผิด แต่มันไม่ขัดขวางการออกแบบของคุณ (ถ้าคุณเขียนเพื่อคุณเองคุณรู้ว่าคุณหมายถึงอะไรและคุณใช้มันเหมือน blah)

— barlop

0

คุณสามารถใช้ผังงานได้ถ้าคุณรู้สึกสับสนมากถ้าข้อความและคุณพยายามที่จะเข้าใจ หรือถ้าคุณกำลังพยายามที่จะเข้าใจการวนรอบดูผลของตัวนับ หากคุณกำลังเรียนรู้มันสามารถช่วยได้มาก

มันอาจรู้สึกว่าเป็นข้อ จำกัด เล็กน้อยเพราะคุณต้องใส่ข้อความสั้น ๆ ลงไปในกล่อง และถ้าโปรแกรมของคุณเป็นแบบเส้นตรงและลูปและ ifs ของคุณไม่สำคัญฉันก็ไม่เห็นประโยชน์อะไรเลย

Pseudocode มีประโยชน์สำหรับการออกแบบโปรแกรมโดยไม่ต้องมีสิ่งที่ทำให้ไขว้เขวต้องได้รับไวยากรณ์ที่ถูกต้องและไม่มีความเยิ่นเย้อนานที่บางภาษาสามารถทำได้ ความจริงที่ว่ามันเร็วกว่าในการเขียนยังทำให้ง่ายต่อการออกแบบรหัสใหม่ และคุณสามารถกระชับได้ตามที่ใจต้องการมันเป็นเรื่องดีที่จะเขียนต้องใช้ความพยายามในการทำงานให้น้อยลง

ดังนั้นมีประโยชน์สำหรับตัวคุณเอง

พวกเขายังสามารถใช้ในการสื่อสารกับผู้อื่น

— barlop
แหล่งที่มา