Giải thích mã nguồn của người khác [đã đóng]

Lưu ý: Tôi nhận thức được câu hỏi này . Câu hỏi này cụ thể hơn và chuyên sâu hơn một chút, tuy nhiên, tập trung vào việc đọc mã thực tế hơn là gỡ lỗi hoặc hỏi tác giả.

Là một học sinh trong một lớp học khoa học máy tính giới thiệu, bạn bè của tôi thỉnh thoảng nhờ tôi giúp họ làm bài tập. Lập trình là điều tôi rất tự hào, vì vậy tôi luôn vui vẻ bắt buộc. Tuy nhiên, tôi thường gặp khó khăn trong việc diễn giải mã nguồn của họ.

Đôi khi điều này là do một phong cách lạ hoặc không nhất quán, đôi khi do các yêu cầu thiết kế lạ được chỉ định trong bài tập và đôi khi chỉ là do sự ngu ngốc của tôi. Trong mọi trường hợp, tôi cuối cùng trông giống như một thằng ngốc nhìn chằm chằm vào màn hình trong vài phút và nói "Uh ..."

Tôi thường kiểm tra các lỗi phổ biến trước tiên - thiếu dấu chấm phẩy hoặc dấu ngoặc đơn, sử dụng dấu phẩy thay vì toán tử trích xuất, v.v.

Những rắc rối đến khi thất bại. Tôi thường không thể bước qua với trình gỡ lỗi vì đó là lỗi cú pháp và tôi thường không thể hỏi tác giả vì anh ấy / cô ấy không hiểu các quyết định thiết kế.

Làm thế nào để bạn thường đọc mã nguồn của người khác? Bạn có đọc qua mã từ trên xuống hay bạn theo dõi từng chức năng như nó được gọi? Làm thế nào để bạn biết khi nào nên nói "Đã đến lúc tái cấu trúc?"

Mẹo đầu tiên: sử dụng IDE (hoặc trình soạn thảo rất tốt :)) để phát hiện lỗi cú pháp, dấu ngoặc sai và các lỗi nhỏ khác.

Bước thứ hai: Tự động định dạng tất cả mã theo định dạng mà bạn cảm thấy thoải mái. Bạn sẽ nghĩ rằng điều này không quan trọng lắm nhưng thật đáng kinh ngạc, nó có.

Đừng ngại đổi tên các biến cục bộ nếu chúng được đặt tên kém. (Nếu bạn có quyền truy cập vào toàn bộ hệ thống, bạn có thể đổi tên mọi thứ và bạn nên.)

Thêm nhận xét cho chính bạn khi bạn khám phá những gì một chức năng / phương pháp đang làm.

Kiên nhẫn. Hiểu mã người ngoài hành tinh không dễ nhưng luôn có một khoảnh khắc đột phá khi hầu hết các mảnh ghép hình đột nhiên rơi vào vị trí. Cho đến thời điểm đó, tất cả công việc khó khăn và vất vả tôi sợ. Tin tốt là với việc thực hành khoảnh khắc eureka này sẽ đến sớm hơn.

Tôi có thể nói rằng tôi nghĩ bạn đang dùng sai phương pháp này. Nếu mọi người đang nhờ bạn giúp đỡ về mã của họ, tôi nghĩ bạn có trách nhiệm quay lại và nói với họ để hướng dẫn bạn về mã của họ. Bạn có thể sửa lỗi của họ cho họ và họ có thể học được điều gì đó (bằng cách học vẹt), nếu họ có thể phát hiện ra lỗi của mình (với sự giúp đỡ của bạn), họ có khả năng tìm hiểu thêm. Ngoài ra, bạn sẽ có được trải nghiệm rộng hơn với cách mọi người tiếp cận mã hóa (điều này sẽ cho phép bạn đọc / hiểu thêm mã) - một chu trình có đạo đức ...;)

Tôi tin rằng khả năng này là sự pha trộn giữa kinh nghiệm và chỉ cần có một tài năng cho nó. Chúng tôi đã có những nhân viên có thể giải quyết ít nhiều bất cứ điều gì nếu chúng tôi yêu cầu họ làm một cái gì đó từ đầu, đồng thời hoàn toàn không thể tìm thấy các lỗi rõ ràng trong các đoạn mã họ không viết. Và đồng thời, chúng tôi đã có những nhân viên mà chúng tôi sẽ không tin tưởng vào bất cứ thứ gì vượt quá thiết kế cơ bản, nhưng ai có thể đi sâu vào mã của người khác và theo dõi các vấn đề ngay lập tức.

Điều đó nói rằng, cách để tiếp cận điều này là thay đổi mã. Định dạng lại nó thành những gì bạn đã quen, thay đổi tên biến thành một cái gì đó có ý nghĩa với bạn, thêm nhận xét nếu mã không rõ ràng. Nếu anh ấy nhờ bạn giúp đỡ, bạn chỉ nên tiếp tục và thay đổi mọi thứ cho đến khi bạn phát hiện ra vấn đề. Sau đó để lại cho bạn của bạn xem có sửa mã gốc hay sử dụng mã của bạn không.

Đầu tiên, nếu có lỗi cú pháp, bạn chỉ cần đọc kỹ các lỗi biên dịch. Thường thì một dòng được tô sáng là một lỗi, nhưng thực ra đó là dòng trước đó có lỗi.

Xin lưu ý rằng, đối với một sinh viên giới thiệu, có thể có một số tạo tác chỉnh sửa sẽ ngăn chương trình được biên dịch mà không thể nhìn thấy. Ví dụ, tôi đã từng thấy một sinh viên (không phải là của tôi) đã sử dụng phím cách thay vì trả về: Mã của anh ta trông bình thường trên một trình soạn thảo được gói sau 80 cột (sinh viên rất kiên nhẫn) và mã này thậm chí còn hoạt động cho đến khi anh ta thêm vào một //bình luận kiểu "", trong đó nhận xét tất cả phần còn lại của chương trình. Tương tự, nếu bạn sao chép các mẫu mã từ một trang web, thường có các ký tự không thể in được cũng được sao chép (tùy thuộc vào cách trang web định dạng mã). Khi nghi ngờ, hãy nhập lại vào một dòng mà không cần sao chép và dán. [Thật là tuyệt vời, nhưng tôi đã thấy nó xảy ra gần đây hơn rất nhiều.]

Đối với các lỗi biên dịch khó chịu, bạn có thể phải phát triển chương trình, bằng cách tạo một tệp mới và nhập tất cả các mã khi bạn đi cùng. Đảm bảo biên dịch sau mỗi bước chính trước khi chuyển sang bước tiếp theo.

OK, vậy nếu không có lỗi cú pháp thì sao? Sau đó là thời gian để bước qua mã! Bạn có thể sử dụng trình gỡ lỗi cho việc này, nhưng thực hiện các cuộc gọi đến printftrong toàn bộ mã cũng có hiệu quả cao. Ví dụ: nếu có một forvòng lặp, hãy thêm vào một câu lệnh in cho bộ đếm vòng lặp. Trong trường hợp các forvòng lặp lồng nhau , bạn có thể thấy rằng biến sai đang được tăng lên.

Ưu điểm của việc sử dụng printfs là khả năng "nén" theo thời gian / không gian những gì bạn đang xem. Khi bạn bước qua với một trình sửa lỗi, bạn cũng thấy rất nhiều trạng thái không liên quan và nó có thể tẻ nhạt hơn. Ngoài ra, không nhìn thấy lịch sử của những gì đã được in lên bàn điều khiển, bạn có thể bỏ lỡ một số mẫu. Vấn đề ở đây là trình gỡ lỗi và bản in là các kỹ thuật bổ sung và không phải lúc nào cũng tốt hơn các trình gỡ lỗi khác.

Cuối cùng, chỉ cần hỏi bạn của bạn những gì đang xảy ra! Thay vì nhìn vào nó và nói "uh" hãy hỏi họ những gì họ đang làm: "bây giờ phải nlàm gì?" Bằng cách bắt đầu hộp thoại, cuối cùng họ có thể trả lời câu hỏi của chính họ hoặc bạn có thể nhận ra cách họ khái niệm hóa chương trình có một lỗ hổng, điều này có thể đưa bạn đến một giải pháp.

Như đã nhận xét ở nơi khác, tất cả điều này trở nên tốt hơn với kinh nghiệm. Mặc dù tôi đã lập trình được 20 năm, nhưng mãi đến 5 năm qua tôi mới làm việc với các sinh viên mà tôi đã giúp họ khắc phục lỗi tốt hơn.

Tôi ghét phải nói điều này, nhưng không có viên đạn bạc nào ở đây.

Thành thật mà nói, nếu tôi đủ thông minh để có thể hiểu người khác có ý gì khi họ viết những gì họ đã làm ngay cả trong 10% các trường hợp, tôi sẽ không có chút nghi ngờ nào khiến hàng triệu người nghi ngờ.

Trên một lưu ý thực tế hơn, sử dụng IDE thông minh là bước 1.

Bước 2 sẽ là chạy doxygen hoặc một cái gì đó tương tự để tìm ra hệ thống phân cấp mã nguồn.

Bước 3 là tìm ra các hàm hoặc đối tượng neo, thứ xử lý dòng lệnh hoặc tệp của bạn và sau đó thực hiện logic.

Song song với Bước 3, hãy theo dõi toàn cầu nếu bạn đang sử dụng chúng. Cũng hỏi bạn bè của bạn nếu họ đang sử dụng bất kỳ thuật toán cụ thể đã biết nào - đọc thuật toán (nếu có tồn tại) trước khi xem mã luôn có lợi.

Trong một từ: Kinh nghiệm, bạn càng có nhiều kinh nghiệm, bạn càng học được nhiều cách thực hành tốt nhất và có thể đánh giá / hiểu mã của người khác. Nó không tự động đến, thay vào đó nó thường chỉ xuất phát từ chính lỗi lầm đó!

Điều đó nói rằng, điều cần thiết là các lập trình viên học cách nhận xét mã của họ một cách chính xác bởi vì khi bạn nhìn vào mã, nó thường chỉ là kết quả của một quá trình suy nghĩ lớn mà thường rất khó để ngoại suy mã. Một vài bình luận, một tệp văn bản với những suy nghĩ thiết kế có thể tạo ra sự khác biệt giữa việc hiểu mã và hoàn toàn hiểu sai về nó.

Tôi thường được hỏi tương tự trong phòng thí nghiệm ở trường. Thông thường câu hỏi bắt đầu bằng "Làm cách nào để sửa lỗi trình biên dịch này?" Vì vậy, tôi đã khá giỏi trong việc phát hiện ra lủng lẳng else, thiếu dấu chấm phẩy và tương tự. (Macros cũng rất vui khi gỡ lỗi - đó #define CUBE(x) x * x * xlà một sai lầm mà tất cả chúng ta đều mắc phải.) Một lợi thế tôi có là tôi đã trải qua cùng một lớp học với cùng một giáo viên, vì vậy tôi đã quen với các yêu cầu.

Quá trình tôi thấy hoạt động tốt nhất là giữ một hộp thoại đang chạy. Bạn không muốn viết chương trình cho họ, vì họ là người cần học. Điều này có nghĩa là bạn phải ở cùng máy tính với họ. Trong phòng thí nghiệm tôi sẽ đến máy tính của họ. Tôi sẽ cố gắng để họ phát hiện ra lỗi, bằng cách bắt đầu với thông báo trình biên dịch. (Chúng tôi đã sử dụng C.) Bắt đầu với số dòng và chỉ ra nơi thông báo và lỗi tương ứng. Nếu có nhiều hơn một lỗi giống nhau, tôi sẽ hỏi họ những gì giống nhau về hai lỗi này.

Toàn bộ ý tưởng là để giúp hướng dẫn các sinh viên khác. Viết lại mã của họ cho họ sẽ không giúp họ học.

Lỗi cú pháp dễ tìm hơn rất nhiều so với lỗi logic. Nếu hầu hết các vấn đề của họ là cú pháp, hãy tìm một IDE, sao chép và dán mã của họ vào đó và sửa lỗi. Lỗi logic khó khăn hơn nhiều. Tôi không chắc tại sao bạn nói bạn không thể yêu cầu họ giải thích mã của họ. Tôi đã tìm thấy nhiều lỗi logic bằng cách giải thích mã cho người khác.