Bạn có thường xuyên sử dụng mã giả trong thế giới thực?

Question

Trở lại đại học, chỉ việc sử dụng mã giả đã được truyền giáo nhiều hơn OOP trong chương trình giảng dạy của tôi. Cũng giống như bình luận (và các phương pháp hay nhất khác được rao giảng '), tôi thấy rằng trong thời gian bẻ khóa psuedocode thường bị bỏ quên. Vì vậy, câu hỏi của tôi là ... những người thực sự sử dụng nó rất nhiều thời gian? Hay bạn chỉ sử dụng nó khi thuật toán thực sự khó để khái niệm hoàn toàn trong đầu của bạn? Tôi quan tâm đến câu trả lời từ mọi người: những nhà phát triển trẻ sơ sinh dưới tai, những người đã quay lưng lại trong những ngày thẻ đục lỗ.

Đối với cá nhân tôi, tôi chủ yếu chỉ sử dụng nó cho những thứ khó khăn.

Answer 1

Tôi sử dụng nó mọi lúc. Bất cứ lúc nào tôi phải giải thích một quyết định thiết kế, tôi sẽ sử dụng nó. Nói chuyện với nhân viên phi kỹ thuật, tôi sẽ sử dụng nó. Nó có ứng dụng không chỉ cho lập trình, mà còn để giải thích cách mọi thứ được thực hiện.

Làm việc với một nhóm trên nhiều nền tảng (Java front-end với phần phụ trợ COBOL, trong trường hợp này) sẽ dễ dàng hơn để giải thích cách mã bit hoạt động bằng cách sử dụng mã giả hơn là hiển thị mã thực.

Trong giai đoạn thiết kế, mã giả đặc biệt hữu ích vì nó giúp bạn xem giải pháp và có khả thi hay không. Tôi đã nhìn thấy một số thiết kế trông rất tao nhã, chỉ để cố gắng thực hiện chúng và nhận ra tôi thậm chí không thể tạo ra mã giả. Hóa ra, nhà thiết kế chưa bao giờ thử suy nghĩ về việc thực hiện lý thuyết. Nếu anh ta cố gắng viết một số giả mã đại diện cho giải pháp của mình, tôi sẽ không bao giờ phải lãng phí 2 tuần để tìm ra lý do tại sao tôi không thể làm cho nó hoạt động được.

Answer 2

Tôi sử dụng mã giả khi ở xa máy tính và chỉ có giấy và bút. Nó không có nhiều ý nghĩa để lo lắng về cú pháp cho mã mà sẽ không biên dịch (không thể biên dịch giấy).

Answer 3

Chủ yếu sử dụng nó để tắt mã thực sự phức tạp hoặc khi giải thích mã cho các nhà phát triển khác hoặc nhà phát triển không hiểu hệ thống.

Tôi cũng chảy sơ đồ hoặc loại uml sơ đồ khi cố gắng làm ở trên cũng ...

Answer 4

Tôi thường sử dụng nó khi phát triển nhiều nếu báo cáo khác được lồng nhau mà có thể gây nhầm lẫn.

Bằng cách này, tôi không cần phải quay lại và ghi lại nó vì nó đã được thực hiện.

Answer 5

Khá hiếm khi, mặc dù tôi thường ghi lại một phương pháp trước khi viết phần thân của nó.

Tuy nhiên, nếu tôi đang trợ giúp một nhà phát triển khác cách tiếp cận vấn đề, tôi thường viết email có giải pháp giả mã.

Answer 6

Tôi hầu như luôn sử dụng nó ngày nay khi tạo bất kỳ thói quen không tầm thường nào. Tôi tạo mã giả như bình luận, và tiếp tục mở rộng nó cho đến khi tôi nhận được đến mức tôi có thể viết mã tương đương bên dưới nó. Tôi đã tìm thấy điều này tăng tốc đáng kể sự phát triển, làm giảm hội chứng "chỉ viết mã" thường đòi hỏi phải viết lại những thứ không được coi là nó buộc bạn phải suy nghĩ qua toàn bộ quá trình trước khi viết mã thực tế, và phục vụ như là cơ sở tốt cho tài liệu mã sau khi nó được viết.

Answer 7

Tôi không sử dụng mã giả. Tôi thấy thoải mái hơn với cú pháp của ngôn ngữ kiểu C hơn là với Mã giả.

Điều tôi làm thường xuyên cho mục đích thiết kế về cơ bản là kiểu phân tách chức năng của mã hóa.

public void doBigJob(params) 
{ 
    doTask1(params); 
    doTask2(params); 
    doTask3(params); 
} 
private void doTask1(params) 
{ 
    doSubTask1_1(params); 
    ... 
} 

Mà, trong một thế giới lý tưởng, cuối cùng sẽ trở thành mã làm việc như phương pháp ngày càng trở nên tầm thường. Tuy nhiên, trong cuộc sống thực, có rất nhiều việc tái cấu trúc và xem xét lại thiết kế.

Chúng tôi thấy điều này hoạt động tốt, vì hiếm khi chúng tôi bắt gặp một thuật toán vừa là phức tạp vừa khó mã hóa và không được giải quyết tốt hơn bằng cách sử dụng UML hoặc kỹ thuật tạo mô hình khác.

Answer 8

Nếu tôi đang nghiên cứu một điều gì đó phức tạp, tôi sử dụng nó rất nhiều, nhưng tôi sử dụng nó làm nhận xét. Ví dụ, tôi sẽ đưa ra các thủ tục, và đặt trong mỗi bước tôi nghĩ rằng tôi cần phải làm. Khi tôi viết mã, tôi sẽ để lại nhận xét: nó nói những gì tôi đang cố gắng làm.

procedure GetTextFromValidIndex (input int indexValue, output string textValue) 
// initialize 
// check to see if indexValue is within the acceptable range 
// get min, max from db 
// if indexValuenot between min and max 
//  then return with an error 
// find corresponding text in db based on indexValue 
// return textValue 
    return "Not Written"; 
end procedure; 

Answer 9

Tôi chưa bao giờ, thậm chí một lần, cần viết mã giả của chương trình trước khi viết.

Tuy nhiên, đôi khi tôi phải viết mã giả sau mã viết, thường xảy ra khi tôi cố gắng mô tả triển khai cấp cao của chương trình để giúp ai đó tăng tốc với mã mới trong ngắn hạn khoảng thời gian. Và bằng cách "thực hiện cấp cao", ý tôi là một dòng mã giả mô tả 50 hoặc lâu hơn dòng C#, ví dụ:

 
Core dumps a bunch of XML files to a folder and runs the process.exe 
    executable with a few commandline parameters. 

The process.exe reads each file 
    Each file is read line by line 
    Unique words are pulled out of the file stored in a database 
    File is deleted when its finished processing 

Đó là loại giả là tốt, đủ để mô tả khoảng 1.000 dòng mã, và tốt đủ để thông báo chính xác cho người mới biết chương trình thực sự đang làm gì. Nhiều lần khi tôi không biết cách giải quyết vấn đề, tôi thực sự thấy mình vẽ các mô-đun trên bảng trắng ở các mức độ rất cao để có được bức tranh rõ ràng về cách tương tác của chúng, vẽ một mẫu thử nghiệm của cơ sở dữ liệu lược đồ, vẽ một datastructure (đặc biệt là cây, đồ thị, mảng, vv) để có được một xử lý tốt về cách đi qua và xử lý nó, v.v.

Answer 10

Tôi không bao giờ sử dụng hoặc sử dụng nó.

Tôi luôn cố gắng thử nghiệm bằng ngôn ngữ thực khi tôi cần làm điều gì đó phức tạp, thường là kiểm tra đơn vị viết trước để tìm ra mã cần làm gì.

Answer 11

Tôi và các nhà phát triển khác trong nhóm của tôi luôn sử dụng nó. Trong email, bảng trắng, hoặc chỉ trong sự chia sẻ. Psuedocode được suy nghĩ để giúp bạn suy nghĩ theo cách bạn cần, để có thể lập trình. Nếu bạn thực sự không hiểu psuedocode, bạn có thể bắt gặp hầu như bất kỳ ngôn ngữ lập trình nào vì sự khác biệt chính giữa chúng là cú pháp.

Answer 12

Tôi sử dụng nó khi giải thích các khái niệm. Nó giúp để cắt ra các bit không cần thiết của ngôn ngữ để các ví dụ chỉ có các chi tiết thích hợp cho câu hỏi được hỏi.

Tôi sử dụng số tiền hợp lý trên StackOverflow.

Answer 13

Tôi không sử dụng mã giả như được dạy ở trường và không có thời gian rất dài.

Tôi sử dụng mô tả bằng tiếng Anh về thuật toán khi logic đủ phức tạp để đảm bảo; chúng được gọi là "bình luận".;-)

khi giải thích mọi thứ cho người khác, hoặc những thứ làm việc ra trên giấy, tôi sử dụng sơ đồ càng nhiều càng tốt -, trong chương của nó 9, "Quá trình Lập trình Mã giả thì càng tốt

Answer 14

Steve McConnel của Code Complete đơn giản hơn "đề xuất một cách tiếp cận thú vị: khi viết một hàm dài hơn một vài dòng, hãy sử dụng mã giả đơn giản (dưới dạng nhận xét) để phác họa chức năng/thủ tục cần làm trước khi viết mã thực tế. Nhận xét giả tạo sau đó có thể trở thành nhận xét thực tế trong phần thân của hàm.

Tôi có xu hướng sử dụng tính năng này cho bất kỳ chức năng nào hoạt động nhiều hơn những gì có thể được hiểu nhanh chóng bằng cách xem xét một mã (tối đa) có màn hình. Nó hoạt động đặc biệt tốt nếu bạn đã được sử dụng để tách cơ thể chức năng của bạn trong mã "đoạn văn" - đơn vị của mã ngữ nghĩa liên quan cách nhau bởi một dòng trống. Sau đó, "nhận xét giả tạo" hoạt động như "tiêu đề" cho các đoạn văn này.

PS: Một số người có thể cho rằng "bạn không nên nhận xét điều gì, nhưng tại sao và chỉ khi nó không tầm thường để hiểu người đọc biết ngôn ngữ được đề cập tốt hơn thì bạn". Tôi thường đồng ý với điều này, nhưng tôi thực hiện một ngoại lệ cho PPP. Các tiêu chí cho sự hiện diện và hình thức của một bình luận không nên được đặt trong đá, nhưng cuối cùng được điều chỉnh bởi wise, well-thought application of common sense anyway. Nếu bạn thấy mình từ chối thử một chút cong vào một "quy tắc" chủ quan chỉ vì lợi ích của nó, bạn có thể cần phải bước trở lại và nhận ra nếu bạn không phải đối mặt với nó cực kỳ đủ.