Khi nào tôi sẽ sử dụng mã giả thay vì lưu đồ?

Tôi là một sinh viên làm việc với các kỹ thuật lập trình khác nhau, và tôi đã bắt gặp mã giả và sơ đồ. Tôi biết rằng cả hai đều được sử dụng để suy nghĩ vấn đề trước khi thực sự lập trình, nhưng tôi có một vài câu hỏi với điều này.

1. Khi nào tôi sẽ sử dụng mã giả để lập kế hoạch và khi nào tôi sẽ sử dụng sơ đồ? Hoặc là tốt hơn để làm cả hai trước khi thực sự lập trình. Đặc biệt đối với một loại trò chơi arcade nhỏ trong JAVA vì đó là dự án tiếp theo của tôi.
2. Tôi đã nhận thấy rằng mã giả rất giống với mã thực tế hơn là sơ đồ. Điều này sẽ làm cho mã giả tốt hơn vì về cơ bản bạn sao chép / dán mã giả vào chương trình của bạn (tất nhiên, bạn phải thay đổi nó để phù hợp với ngôn ngữ. Tôi hiểu phần đó).
3. Có thực tế để sử dụng cả hai trong khi lập trình? Đặc biệt cùng một trò chơi đã đề cập trước đó. Cảm ơn.

Lưu đồ và mã giả thường có cùng mức độ biểu cảm, nhưng khác nhau về tuyến tính hóa. Mã giả là tuyến tính (tức là một chuỗi các dòng có hướng dẫn), lưu đồ là không. Do đó, sơ đồ khối là một mức độ trừu tượng cao hơn, được sử dụng trước khi viết mã giả hoặc cho tài liệu.

Theo tôi, lưu đồ có hai ưu điểm mạnh so với mã giả: Thứ nhất, chúng là đồ họa. Nhiều người không có kỹ thuật có một nỗi sợ hãi mạnh mẽ đối với văn bản có cấu trúc, nhưng không mô tả đồ họa, vì vậy sơ đồ sẽ ngồi tốt hơn nhiều với họ. Thứ hai, sơ đồ khối tốt hơn nhiều trong việc thể hiện các cân nhắc meta như hiển thị dòng thực thi chính trái ngược với các nhánh.

Câu hỏi của bạn một cách chi tiết:

1. Đối với một vấn đề thực sự phức tạp, bạn sẽ sử dụng sơ đồ trước, sau đó là mã giả. Cả hai đều là tùy chọn khi bạn cảm thấy đủ an toàn.
2. Có, mã giả có lợi thế là có thể kết hợp với mã thực. Steve McConnell, ví dụ, khuyến nghị mạnh mẽ các phương pháp viết bằng mã giả trước và sau đó để lại mã giả trong mã dưới dạng nhận xét.
3. Tôi luôn cảm thấy rằng sự cần thiết phải vẽ sơ đồ trong quá trình thiết kế cho thấy không đủ phân vùng cho vấn đề của bạn. Lưu đồ không tầm thường chỉ ra logic phức tạp, cần tránh với chi phí lớn.

Trên mã giả

Thành thật mà nói, tôi không sử dụng mã giả nhiều. Thông thường, việc viết mã sẽ nhanh hơn, để khi tôi hoàn thành mã của mình, đó là mã thực tế. Có một số trường hợp khi mã giả có thể hữu ích, nhưng nhìn chung bạn đang làm việc trên một cái gì đó rất phức tạp và chỉ cố gắng phá vỡ cấu trúc của một phương thức hoặc một cái gì đó. Trong những trường hợp đó, tôi sử dụng các bình luận trong IDE của mình để bố trí cấu trúc cho đến khi tôi làm mọi thứ đúng. Sau đó, tôi đi vào và viết mã thực tế trong các ý kiến. Điều này giúp tôi làm một số điều:

• Tôi có thể thấy các khu vực tôi có và chưa thực hiện bằng cách đọc các bình luận và thấy các lỗ hổng rõ ràng trong đó.
• Khi tôi điền mã thực, tôi có ý kiến ​​giải thích bằng tiếng Anh những gì tôi đang làm. (Họ có thể sẽ cần nó nếu nó phức tạp đến mức tôi cần phải viết mã giả trước).

Trên sơ đồ

Mã thường thay đổi nhiều đến mức lưu đồ không hữu ích ngoại trừ tài liệu hoặc thiết kế kiến ​​trúc toàn hệ thống lớn hơn. Trong những trường hợp đó, tôi sẽ chỉ vẽ một sơ đồ để có ý chính hoặc hiển thị cho người khác trong nhóm. Trừ khi bạn thực sự cần một sơ đồ để giúp bạn hiểu, thì bạn không thực sự cần chúng để "làm" phần mềm ngay. Ngày nay, có rất nhiều plugin cho IDE sẽ tạo ra sơ đồ từ chính mã, cũng như sơ đồ lớp và các loại khác (và ngược lại `). Thời gian thực duy nhất bạn cần thực hiện một sơ đồ chính xác nghiêm túc là nếu bạn không thể giữ toàn bộ kiến ​​trúc và cách mọi thứ hoạt động trong đầu bạn và cần nói chuyện qua một cái gì đó trực quan để nắm bắt được.

Nói chung tôi không viết Flowcharts trong khi tôi đang làm việc trên các dự án cá nhân (vì các dự án không lớn lắm) và hầu hết các đầu vào, đầu ra và quy trình đều rõ ràng.

nhưng vì bạn sẽ bắt đầu làm việc trên các dự án lớn phức tạp với các nguồn đầu vào khác nhau, các tệp phẳng, cơ sở dữ liệu, giao diện thủ công, vv lưu đồ rất tiện dụng.

Tôi khuyên bạn nên viết mã giả và mã UML vì các công cụ này sẽ giúp bạn đưa ra các lớp, phương thức tốt hơn, v.v. Đôi khi, khi viết mã giả, bạn sẽ tìm thấy các cách khác nhau và hiệu quả hơn để giải quyết chương trình.

Mã giả là để nhanh chóng thể hiện một ý tưởng cho những người hiểu ít nhất những điều cơ bản của mã. Sơ đồ khối đang vẽ những bức tranh đẹp để mọi người khác hiểu điều tương tự.

Biểu đồ luồng thường được sử dụng cho mục đích tài liệu vì nhiều người khác nhau sử dụng tài liệu đó và sơ đồ dễ theo dõi hơn mã giả cho người không lập trình. Trong một dự án, bạn đang tự mình làm việc với mã giả là tốt vì nó hữu ích hơn nhiều và dễ dàng hơn nhiều vì trình soạn thảo văn bản là tất cả những gì bạn cần.

Sơ đồ khối là một mức độ trừu tượng cao, chúng cho phép bạn lên kế hoạch mọi thứ nên tiến hành như thế nào, ví dụ

nếu x chết y thắng

Họ không cần phụ thuộc vào cách bạn thiết kế chương trình theo các lớp và phương thức, mặt khác mã giả cung cấp mức độ trừu tượng thấp hơn (mặc dù nó thực sự phụ thuộc)

if (isdead (s)) y.win ()

do đó mã giả bây giờ có thể được dịch sang chương trình thực tế dựa trên ngôn ngữ bạn đang sử dụng.

Đối với một trò chơi, trước tiên tôi khuyên bạn nên sử dụng sơ đồ, sau đó thiết kế các lớp và phương thức, viết mã giả và cuối cùng chuyển đổi nó thành một chương trình

Tôi sẽ xem xét bản chất của mã bạn đang viết. Nếu nó là:

1. Lặp đi lặp lại / đệ quy cao
2. Chi nhánh theo những cách phức tạp
3. Được triển khai trong một số hệ thống mà bạn muốn đại diện

Trong hai trường hợp đầu tiên, mã giả ngày càng khó đọc hơn một sơ đồ hình ảnh lớn. Mặt khác, mã chủ yếu là tuyến tính tạo ra các sơ đồ cực kỳ nhàm chán, điều này thực sự làm cho quá trình khó hiểu hơn vì nó thổi nó lên bao nhiêu.

Đối với trường hợp thứ ba, sơ đồ khối tốt hơn trong việc biểu diễn các quy trình vượt qua ranh giới hệ thống và thể hiện toàn bộ quy trình.

1. Bạn nên sử dụng bất cứ điều gì bạn cảm thấy thoải mái. Điều đó nói rằng, ấn tượng của tôi là lưu đồ không được sử dụng nhiều để phác thảo kiểm soát chương trình những ngày này; đối với một điều, chúng thường không có cấu trúc, so với mã giả. Việc sử dụng các sơ đồ phụ thuộc lớp như UML là phổ biến hơn, để mô tả kiến ​​trúc của bạn ở mức cao hơn nhiều. Ngoài ra, nếu ứng dụng của bạn có máy trạng thái, việc vẽ sơ đồ máy trạng thái (giống như sơ đồ) là điều cần thiết.
2. Tôi nghĩ bạn đúng ở đây. Một cách để làm việc là viết mã giả của bạn dưới dạng các nhận xét trong tệp nguồn của bạn để bắt đầu và chèn các dòng thực hiện thực tế trong số chúng.
3. Một lần nữa, sử dụng bất cứ điều gì bạn cảm thấy thoải mái. Nếu bạn không chắc chắn, hãy thử cả hai; Tôi hy vọng thực hành của bạn sẽ nhanh chóng hội tụ vào bất cứ điều gì hữu ích nhất cho bạn. Cá nhân tôi không thấy sơ đồ hữu ích trừ khi tôi đang cố gắng gỡ rối một lệnh thực thi đặc biệt phức tạp.

Tại sao phải viết mã giả khi bạn có thể viết Java? Tôi đã tìm thấy Java, một IDE tốt và Javadoc là cách dễ nhất để nắm bắt một vấn đề lập trình - ít nhất là một Hướng đối tượng . (Và một game arcade phải là OO.) Ngôn ngữ được thiết kế từ đầu cho việc này. Nó đơn giản và dễ hiểu. (Quá đơn giản cho nhiều mục đích, có lẽ, nhưng điều tốt nhất tôi từng thấy cho điều này.) Siêu văn bản trong Javadoc và, thông qua một IDE, trong chính mã tạo ra một "sơ đồ" dễ hiểu hơn bạn có thể vẽ một tờ giấy lớn. Mã Java đơn giản như bất kỳ mã giả nào và một thỏa thuận tốt hơn nghiêm ngặt hơn. Và một khi bạn đã mã hóa "sơ đồ" và "giả", chương trình sẽ thực sự chạy!

Bạn có thể sử dụng sơ đồ nếu bạn thực sự bối rối bởi các câu lệnh if và bạn đang cố gắng hiểu điều đó. Hoặc nếu bạn đang cố gắng hiểu một vòng lặp, hãy xem tác dụng của bộ đếm. Nếu bạn đang học nó có thể giúp rất nhiều.

Nó có thể cảm thấy một chút hạn chế - vì bạn phải đặt các câu ngắn gọn vào các hộp. Và nếu chương trình của bạn rất tuyến tính và các vòng lặp và if của bạn là tầm thường, thì tôi thấy không có ích gì cho nó.

Pseudocode rất hữu ích cho việc thiết kế một chương trình. Không có sự phân tâm phải có cú pháp đúng và không có sự dài dòng mà một số ngôn ngữ có thể liên quan. Thực tế là viết nhanh hơn cũng giúp thiết kế lại mã dễ dàng hơn. Và bạn có thể ngắn gọn như tâm trí của bạn mong muốn, thật dễ chịu để viết, đòi hỏi ít nỗ lực tinh thần hơn để làm cho nó hoạt động (vì không có hoặc ít gỡ lỗi hơn), và có nhiều khả năng tập trung vào bức tranh lớn và thiết kế.

Vì vậy, hữu ích cho chính mình.

Chúng cũng có thể được sử dụng để giao tiếp với người khác.