(Các) lập trình viên Novice bực bội vì thiếu bảng chú giải lỗi biên dịch

66

Một người bạn của gia đình tôi đã nhờ tôi giúp đỡ một chút khi anh ấy học lập trình (bằng ngôn ngữ C). Khi chúng tôi đang nói chuyện, anh ấy đã bày tỏ sự thất vọng về việc khó hiểu các thông báo lỗi mà trình biên dịch của anh ấy (GCC) đưa ra cho anh ấy khi anh ấy mắc lỗi. Anh ta không hiểu tất cả các thuật ngữ được sử dụng, và đôi khi đó là sự kết hợp của họ vượt quá tầm hiểu biết của anh ta. Anh ấy hỏi tôi "Làm thế nào mà tài liệu trình biên dịch không bao gồm các giải thích dài hơn về các thông báo lỗi?" - và tôi đã không có một câu trả lời tốt cho anh ta.

Bản thân tôi - với tư cách là một lập trình viên giàu kinh nghiệm hơn - rất hiếm khi gặp tình huống này, nhưng những sự cố hiếm gặp đó đã xảy ra - một số thông báo lỗi kỳ lạ mà tôi chưa gặp phải trước đây. Tôi quản lý để có được bằng cách tìm kiếm thông báo lỗi trong công cụ tìm kiếm, nhưng dường như điều đó không phải lúc nào cũng phù hợp với anh ta - đặc biệt là vì các lỗi anh ta gặp phải phổ biến hơn và xảy ra trong nhiều trường hợp khác nhau, anh ta gặp rắc rối liên quan đến sở hữu.

Vì vậy, làm thế nào một lập trình viên mới làm quen tiếp cận thách thức hiểu các thông báo lỗi trình biên dịch? Cụ thể, với sự kết hợp của C và GCC?

— einpoklum - phục hồi Monica
nguồn

7

"Vì vậy, làm thế nào một lập trình viên mới làm quen tiếp cận thách thức hiểu các thông báo lỗi trình biên dịch?" / mỉa mai Kỹ năng đầu tiên cần có là có thể đọc mọi bit từ thông điệp của trình biên dịch, bao gồm cả việc liên kết nó với chính ngữ cảnh. / mỉa mai. Nó hiếm khi trở thành một lỗ hổng, hoặc lỗi trong trình biên dịch.

— πάντα ῥεῖ

10

@MasonWheeler: Một người mới thường không chọn trình biên dịch nào để sử dụng khi trải qua đào tạo. Và GCC là mẫu số chung của nhiều, nhiều hệ thống ...

— einpoklum - phục hồi Monica

24

Khi gặp lỗi mẫu GCC C ++, tôi thấy nếu tôi dừng đọc sau "Error <file: line>" và nghiên cứu (các) tệp nguồn, tôi thấy lỗi nhanh hơn, với tác dụng phụ được thêm vào là duy trì sự tỉnh táo của tôi, hơn nếu tôi đọc lỗi thực tế do GCC đưa ra .....

— mattnz

18

Giải pháp rất rõ ràng: Sử dụng trình biên dịch có đầu ra ít gây nhầm lẫn. Tôi đề nghị rmcc . Nó in Yes.hoặc No.tùy thuộc vào nếu mã của bạn được biên dịch hay không. Ngay lập tức lấy đi sự thất vọng từ việc không hiểu những tin nhắn dài và vô nghĩa!

— ống

21

C không phải là một ngôn ngữ tốt cho người mới bắt đầu - và bạn đã vấp phải một trong những lý do. Điều đó đang được nói, Clang có xu hướng cung cấp các lỗi tốt hơn nhiều cũng có thể hấp dẫn hơn cho người mới bắt đầu.

— Theodoros Chatzigiannakis

164

Một vài kỹ thuật hữu ích:

Bật -Wallvà -Werror. Điều này có vẻ trái ngược khi bạn đang vật lộn với việc giải mã các thông báo lỗi để tạo ra nhiều thông báo lỗi hơn , nhưng các cảnh báo thường dễ hiểu và gần với nguồn thực tế của vấn đề hơn và bỏ qua chúng có thể dẫn đến các lỗi khó hiểu .
Chỉ cần cố gắng sửa lỗi đầu tiên trong danh sách. Thông thường lỗi kết hợp lẫn nhau, dẫn đến các thông báo lỗi sau này không thực sự là lỗi thực tế. Sửa một cái và biên dịch lại. Bạn sẽ trở nên tốt hơn trong việc sửa nhiều thông báo lỗi khi bạn có thêm kinh nghiệm.
Sử dụng phiên bản trình biên dịch mới nhất có thể. C là một ngôn ngữ cực kỳ ổn định. Do đó, một phần lớn các cải tiến trong trình biên dịch mới hơn không phải là thêm các tính năng ngôn ngữ, mà là để cải thiện trải nghiệm của nhà phát triển, bao gồm các thông báo lỗi tốt hơn. Nhiều bản phân phối linux được sử dụng rộng rãi có các phiên bản gcc rất cũ theo mặc định.
Chương trình tăng dần. Đừng cố viết một tấn mã trước khi biên dịch. Viết số tiền ngắn nhất có thể vẫn sẽ biên dịch. Nếu bạn chỉ thay đổi một dòng kể từ lần cuối cùng nó được biên dịch sạch sẽ, việc tìm ra dòng nào chứa vấn đề thực sự sẽ dễ dàng hơn rất nhiều.
Viết bài kiểm tra đơn vị. Nó làm cho bạn tự tin hơn để làm rõ các thay đổi tái cấu trúc khi sửa lỗi biên dịch.

— Karl Bielefeldt
nguồn

23

Một IDE tốt cũng có thể giúp ích rất nhiều cho trải nghiệm này. lỗi gạch chân màu đỏ.

— BlueRaja - Daniel Pflughoeft

86

"Chương trình tăng dần. Đừng cố viết một tấn mã trước khi biên dịch. Viết số tiền ngắn nhất có thể vẫn sẽ biên dịch. Nếu bạn chỉ thay đổi một dòng kể từ lần cuối cùng được biên dịch sạch sẽ, việc tìm ra sẽ dễ dàng hơn rất nhiều dòng nào chứa vấn đề thực tế. " Cái này, rất nhiều cái này Ngoài ra, hầu hết các IDE sẽ cảnh báo bạn nếu bạn viết mã không được biên dịch và làm nổi bật các erros.

— Polygnome

4

@einpoklum: đừng đánh giá thấp lựa chọn thứ ba; thông báo lỗi trình biên dịch đã được cải thiện rất nhiều. Trong một tĩnh mạch tương tự, sử dụng một số trình biên dịch (ví dụ gcc và clang) - bắt được nhiều lỗi / cảnh báo hơn và một trong số chúng có thể có chẩn đoán tốt hơn cho một vấn đề cụ thể so với các vấn đề khác.

— Mat

19

@einpoklum: viết nhiều thứ tăng dần là rất được chú ý , đặc biệt là cho người mới bắt đầu. Heck, nếu bạn tin rằng "các bài tập lập trình ngắn" không thể được thực hiện tăng dần, bằng cách chia chúng thành nhiều chức năng nhỏ và thực hiện và biên dịch chúng từng cái một, bạn nên cố gắng cải thiện kỹ năng đó cho chính mình ..

— Doc Brown

4

Một mẹo giúp tôi: nếu thông báo lỗi đề cập đến Dòng N, hãy kiểm tra Dòng N-1. Ví dụ: nếu bạn thiếu dấu chấm phẩy trên dòng 17, thông báo lỗi sẽ nói rằng có gì đó không đúng với dòng 18. Điều này là do trình biên dịch đang mong đợi một dấu chấm phẩy nhưng thay vào đó lại có một cái gì đó khác.

— 2023861

56

Bạn của bạn không cần một thuật ngữ. Một thuật ngữ sẽ không giúp anh ta. Những gì anh ta cần là trực giác tốt hơn về những gì phải làm khi xảy ra lỗi trình biên dịch.

Lỗi trình biên dịch C không trực quan như lỗi trình biên dịch C #, vì nhiều lý do chủ yếu liên quan đến bản chất "gần với kim loại" của C. Giải quyết lỗi trình biên dịch trong C không phải là bài tập khớp mẫu, vì lỗi bạn nhận có thể không có gì để làm với vấn đề thực tế. Không giống như C # hoặc Java, trong đó một thông báo lỗi thường ánh xạ tới một vị trí và vấn đề mã chính xác, các lỗi trong C có thể có rất nhiều và xa.

Một ví dụ về điều này là "dấu chấm phẩy mong đợi" hoặc bất kỳ số lỗi cú pháp nào cho thấy trình phân tích cú pháp đã bị treo trên một cái gì đó (không nhất thiết phải là dấu chấm phẩy). Hoặc một cái gì đó như "khai báo chuyển tiếp bất ngờ", một lỗi mà khi tôi nhìn thấy nó luôn có nghĩa là tôi đã viết hoa sai trong một trong các tệp .h của mình, nhưng không chỉ ra tệp .h là nguồn gốc của vấn đề.

Chiến lược của bạn của bạn không nên để mô hình này khớp với danh sách các lỗi và giải pháp; cần hiểu rõ cú pháp và đặc điểm kỹ thuật của ngôn ngữ C để tìm ra vấn đề thực sự là gì.

— Robert Harvey
nguồn

17

Không. Ý tưởng là để biết ngôn ngữ đủ tốt để biết rằng bạn không thể thực hiện gán cho một biểu thức số, mà chỉ cho một biến. Bạn không cần phải biết giá trị của nó là gì, đó là lý do tại sao họ không dạy điều đó trong các khóa học mới bắt đầu.

— Robert Harvey

18

Về cơ bản, có. Nhưng thực tế, điều đó là không thể. Tôi đã làm điều này trong một thời gian rất dài và tôi vẫn nhận được thông báo lỗi trình biên dịch tối nghĩa mỗi khi tôi viết chương trình C. Tuy nhiên, tôi hiếm khi đọc những tin nhắn đó và cố gắng hiểu chúng; thay vào đó, tôi nhìn vào nơi thông báo lỗi đang chỉ và vì tôi biết cấu trúc cú pháp cơ bản của chương trình C trông như thế nào, tôi có thể phát hiện ra vấn đề tương đối nhanh chóng mà không mất thời gian giải mã thông báo lỗi.

— Robert Harvey

36

Nói cách khác, yêu cầu một thuật ngữ để hiểu lỗi trình biên dịch giống như đọc từ điển để hiểu ngôn ngữ tiếng Anh; đó không phải là cách nó hoạt động. Bạn học và hiểu tiếng Anh bằng cách đọc và viết nó, không đọc từ điển.

— Robert Harvey

14

[nhún vai] Nếu bạn không sử dụng từ điển để chỉ bổ sung kiến thức tiếng Anh đã có của mình, tôi sẽ khuyên bạn nên làm sai. Điều cuối cùng tôi muốn đề xuất là bất cứ điều gì khiến các lập trình viên mới làm quen với từ vựng nhiều hơn họ đã có. Lập trình viên không cần nhiều từ hơn; họ cần nhiều kỹ năng

— Robert Harvey

13

@einpoklum, một thuật ngữ sẽ không giúp đỡ ở đây. Mô tả của từ 'lvalue' có thể là quá kỹ thuật cho người mới bắt đầu hoặc dọc theo dòng chữ 'rằng những gì có thể ở phía bên trái của một bài tập', điều đó cũng không ích lợi gì.

— Bart van Ingen Schenau

26

Một kỹ thuật có liên quan đáng được đề cập là sử dụng trình biên dịch thứ hai. Clang đã đầu tư vào các thông báo lỗi tốt hơn, ví dụ, nhưng bất kỳ cách nào khác để phát hiện lỗi có thể được khai sáng.

Điều này đặc biệt là như vậy đối với các loại lỗi phức tạp nhất. Chẳng hạn, khi bạn trộn lẫn hai cấu trúc tương tự (không phải là bất thường đối với người mới bắt đầu), trình biên dịch thường có vấn đề trong việc tạo thông báo lỗi đúng. Điều này có thể gây nhầm lẫn khi trình biên dịch đưa ra thông báo lỗi về việc sử dụng sai cấu trúc A khi bạn thực sự có ý định xây dựng B. Trình biên dịch thứ hai có thể suy ra rằng bạn dự định B.

— MSalters
nguồn

13

Ai đó đã thử một thuật ngữ lỗi GCC trên Wikibooks một thời gian trước đây, nhưng có vẻ như nó chưa bao giờ hoàn toàn tắt và chưa được cập nhật.

Phần "Lỗi" nằm xa hơn nhiều so với phần "Cảnh báo". Có vẻ như nó đã nhắm vào G ++, nhưng vẫn có khả năng có một số thông tin sử dụng cho bạn của bạn ở đó.

— nurn
nguồn

12

Ngoài các câu trả lời ở trên, lưu ý rằng hầu hết các trình biên dịch không có bảng chú giải lỗi toàn diện - đây sẽ là rất nhiều công việc phải duy trì vì bản thân các thông báo thường thay đổi và có khá nhiều trong số chúng.

Sự thay thế tốt nhất cho một thuật ngữ là truy cập internet. Bất cứ khi nào trình biên dịch tạo ra một lỗi mà bạn không hiểu, hãy thoải mái rằng rất khó có khả năng bạn là người đầu tiên gặp phải nó và bị nhầm lẫn. Google nhanh chóng thông báo chính xác thường đủ để cung cấp cho bạn nhiều thông tin ở định dạng dễ đọc, thường có mã ví dụ rất giống với mã của bạn.

Ngoài ra, thời gian và sự quen thuộc với ngôn ngữ và trình biên dịch là tất cả những gì bạn cần. Điều đó, và lời khuyên tốt được đưa ra bởi Karl Bielefeldt .

— Đức Bà
nguồn

1

Tôi không nghĩ rằng nó sẽ có rất nhiều công việc để duy trì. Thêm vào đó, nó có thể được thêm vào bởi công chúng, như Stackoverflow hoặc Wiki, với những người đáng tin cậy được cấp quyền biên tập.

— einpoklum - phục hồi Monica

6

@einpoklum Bạn đã bao giờ thấy các tài liệu PHP chưa? Đó là những gì xảy ra khi bạn để cộng đồng chăm sóc những thứ đó.

— Kevin

4

Ngày xửa ngày xưa, sách hướng dẫn được xuất bản (in) là tài nguyên duy nhất có sẵn. Chúng thường được viết đủ tốt để cung cấp thông tin / hướng dẫn cần thiết để giải quyết vấn đề. Với sự phát triển của Internet, không ai xuất bản in nữa (nếu có, nó trực tuyến). Chất lượng của tài liệu tham khảo "chính thức" (trực tuyến hoặc cách khác) đã giảm đáng kể trong nhiều thập kỷ tôi đã lập trình, vì vậy tài nguyên tốt nhất có sẵn thường là Google và các kết quả hữu ích nhất thường xuất hiện trong Stackoverflow.

— Zenilogix

2

Thậm chí nếu một thuật ngữ không tồn tại, công cụ tìm kiếm có thể là cách tốt nhất để truy cập chúng. Chúng cũng hữu ích để phát hiện khi bạn ở trong lãnh thổ chưa được khám phá: khi kết quả tìm kiếm duy nhất là mã nguồn xác định thông báo lỗi;)

— Warbo

2

Ở trường đại học, tôi đã từng gặp lỗi trình biên dịch "Dave không nghĩ điều này sẽ xảy ra. Vui lòng gửi email cho anh ấy tại <dave@example.com>". Tôi đã gửi email cho anh ấy và thực tế tôi là người đầu tiên gặp phải lỗi đặc biệt đó!

— dùng1118321

6

Tiêu chuẩn C sử dụng một số thuật ngữ như "lvalue" và "object" theo những cách khác với các ngôn ngữ lập trình khác và các thông điệp của trình biên dịch thường được viết bằng các thuật ngữ đó. Việc sử dụng thuật ngữ không nhất quán trong một số phần của Tiêu chuẩn, nhưng bất kỳ ai muốn học C nên xem các bản nháp của các tiêu chuẩn C89, C99 và / hoặc C11 cũng như các tài liệu hợp lý cho chúng. Tìm kiếm ví dụ "dự thảo C99" hoặc "lý do C89" sẽ hoạt động khá tốt, mặc dù bạn có thể cần đảm bảo rằng bạn nhận được tài liệu mà bạn mong đợi. Mặc dù hầu hết các trình biên dịch hỗ trợ Tiêu chuẩn C99, nhưng có thể hữu ích khi biết nó khác với Tiêu chuẩn C89 như thế nào và lý do C89 có thể cung cấp một số bối cảnh lịch sử mà các phiên bản sau này không có.

— siêu mèo
nguồn

11

Tiêu chuẩn C là một văn bản rất dày đặc và nặng nề. Một người mới bắt đầu không có cơ hội hiểu nó.

— NieDzejkob

4

@NieDzejkob: Thuật ngữ được sử dụng bởi các trình biên dịch - dường như là câu hỏi về điều gì - có nguồn gốc từ Tiêu chuẩn. Mặc dù bạn đúng rằng các phần của Tiêu chuẩn là không thể hiểu được (một phần vì nó được thiết kế bởi ủy ban và các tác giả dường như không có sự hiểu biết nhất quán về những phần được cho là có nghĩa), nhưng bất cứ ai cũng muốn hiểu những gì các thuật ngữ như "lvalue" có nghĩa là nên biết họ đến từ đâu. Hơn nữa, nếu ai đó muốn hiểu tại sao thứ gì đó như gây x=0x1e-xra lỗi, tôi thực sự không biết gì khác ngoài Tiêu chuẩn ...

— supercat

3

Tôi đồng ý với @NieDzejkob: Tiêu chuẩn C không phải là loại văn bản bạn muốn đối đầu với người mới. Người mới cần kinh nghiệm thực hành tích cực nhanh chóng . Và họ cần học từng thứ một khi chúng bật lên. Đọc một tiêu chuẩn hoặc lý do chiếm quá nhiều thời gian trong khi hoàn toàn làm quá tải thông tin của một người mới.

— cmaster

2

@cmaster: Tôi đã bắt đầu với C89 Standard từ lâu và nó không quá tệ ngay cả trong những ngày trước khi các trình duyệt có tính năng 'tìm văn bản' tiện dụng. Tôi sẽ cho rằng các tiêu chuẩn sau này ngày càng tệ hơn. Mặc dù không ai nên dựa vào Tiêu chuẩn như một tài liệu tham khảo duy nhất, nhưng điều quan trọng là phải nhận ra sự khác biệt giữa trí tuệ dân gian về cách các trình biên dịch máy vi tính hành xử và các cách mà Tiêu chuẩn cho phép các hành vi chất lượng thấp hành xử, vì vậy người ta sẽ chuẩn bị nếu có để đối phó với cái sau

— supercat

3

@cmaster: Trong mọi trường hợp, ai đó đang lập trình C nên biết về Tiêu chuẩn và biết cách tư vấn khi cần, ngay cả khi họ sẽ không cố gắng đọc toàn bộ. Ví dụ, nếu một người tìm kiếm một chức năng thư viện tiêu chuẩn, người ta có thể tìm thấy một tham chiếu mô tả hành vi của một thực thi trong một số trường hợp góc mà không đề cập đến điều đó, theo quan điểm của Tiêu chuẩn, các trường hợp góc đó gọi Hành vi không xác định và các triển khai khác có thể không làm việc theo cùng một cách. Nếu một người thay vì tìm kiếm Tiêu chuẩn, người ta có thể tránh được vấn đề đó.

— supercat

5

Tôi ngạc nhiên không ai đưa ra câu trả lời rõ ràng và, tôi nghi ngờ, câu hỏi thường được sử dụng nhất trong thực tế: chỉ không đọc các thông báo lỗi.

Phần lớn giá trị của hầu hết các thông báo lỗi chỉ đơn giản là có gì đó không ổn trên dòng như vậy và như vậy. Hầu hết thời gian tôi chỉ nhìn vào số dòng và đi đến dòng đó. Việc "đọc" thông báo lỗi của tôi tại thời điểm đó thường chỉ là bất cứ điều gì mắt tôi bắt gặp khi đi qua, thậm chí không đọc lướt qua. Nếu nó không ngay lập tức rõ ràng những gì sai trên hoặc gần dòng, thì tôi thực sự sẽ đọc tin nhắn. Quy trình công việc này thậm chí còn tốt hơn với một IDE hoặc công cụ làm nổi bật các lỗi tại chỗ và tự động thực hiện đề xuất của Karl Bielefeldt để chỉ xem xét các thay đổi nhỏ.

Tất nhiên, các thông báo lỗi không phải luôn luôn chỉ đến dòng thích hợp, nhưng sau đó chúng thường không chỉ ra nguyên nhân gốc thích hợp, do đó, ngay cả sự hiểu biết đầy đủ về thông báo lỗi cũng sẽ được trợ giúp hạn chế. Sẽ không mất nhiều thời gian để có ý tưởng về thông báo lỗi nào đáng tin cậy hơn về việc định vị dòng thích hợp.

Một mặt, hầu hết các lỗi mà một người mới có khả năng mắc phải có khả năng rất rõ ràng đối với một lập trình viên có kinh nghiệm mà không cần sự trợ giúp từ trình biên dịch. Mặt khác, họ ít có khả năng trở nên quá rõ ràng đối với người mới (mặc dù nhiều người sẽ rõ ràng, hầu hết sai lầm là những sai lầm ngu ngốc). Tại thời điểm này, tôi hoàn toàn đồng ý với Robert Harvey, người mới chỉ cần làm quen với ngôn ngữ này. Không có tránh điều này. Lỗi trình biên dịch tham chiếu các khái niệm xa lạ hoặc có vẻ đáng ngạc nhiên nên được xem là lời nhắc để đào sâu kiến thức về ngôn ngữ. Tương tự như vậy đối với các trường hợp trình biên dịch phàn nàn nhưng bạn không thể hiểu tại sao mã bị sai.

Một lần nữa, tôi đồng ý với Robert Harvey rằng cần có một chiến lược tốt hơn để sử dụng các lỗi biên dịch. Tôi đã phác thảo một số khía cạnh ở trên và câu trả lời của Robert Harvey đưa ra các khía cạnh khác. Thậm chí còn không rõ bạn của bạn hy vọng sẽ làm gì với một "bảng chú giải" như vậy và rất khó có thể một "bảng chú giải" như vậy sẽ thực sự có ích với bạn của bạn. Thông điệp trình biên dịch chắc chắn không phải là nơi để giới thiệu về các khái niệm của ngôn ngữ ¹ và "bảng chú giải" không phải là nơi tốt hơn cho nó. Ngay cả với một mô tả sáng suốt về ý nghĩa của thông báo lỗi, nó sẽ không cho bạn biết cách khắc phục vấn đề.

¹ Một vài ngôn ngữ, như Elm và Dhall (và có lẽ là Vợt), cũng như một vài triển khai ngôn ngữ "định hướng cho người mới bắt đầu" cố gắng thực hiện điều này. Theo hướng này, lời khuyên của MSalters về việc sử dụng một triển khai khác có liên quan trực tiếp. Cá nhân tôi thấy những điều như vậy không hấp dẫn và không hoàn toàn nhắm vào vấn đề đúng. Điều này không có nghĩa là không có cách nào tạo ra thông báo lỗi tốt hơn, nhưng, đối với tôi, chúng có xu hướng xoay quanh việc làm cho niềm tin của nhà soạn nhạc và nền tảng của những niềm tin đó rõ ràng hơn.

— Derek Elkins
nguồn

4

Vì vậy, làm thế nào một lập trình viên mới làm quen tiếp cận thách thức hiểu các thông báo lỗi trình biên dịch? Cụ thể, với sự kết hợp của C và GCC?

Nói với bạn của bạn để làm những điều sau đây khi gặp lỗi mà họ không hiểu:

Xóa / nhận xét mã được thêm vào từ lần xây dựng thành công cuối cùng.
Đặt các phần nhỏ của nó trở lại và biên dịch
Lặp lại cho đến khi xảy ra lỗi

Lỗi trình biên dịch chỉ cho bạn biết trình biên dịch không hiểu gì về mã của bạn chứ không phải lỗi gì với trình biên dịch. Cách tiếp cận này mất khoảng thời gian tương đương với việc xử lý lỗi và đọc một số tài liệu hoặc bài đăng StackOverflow, nhưng hiểu rõ hơn về những gì bạn đang làm sai.

Cũng làm cho chúng biên dịch thường xuyên cho đến khi chúng bắt đầu làm việc với các dự án mất vài phút để xây dựng, phát hiện lỗi trước khi thêm quá nhiều mã khác giúp ích rất nhiều.

Cuối cùng, hãy bảo họ làm một việc một lúc, không làm việc trong nhiều tệp mà không biên dịch ở giữa, không giới thiệu nhiều phụ thuộc cùng một lúc, v.v.

— Kevin
nguồn

4

Một kỹ thuật khác sẽ là cho người bạn viết chú giải của riêng mình theo thời gian khi anh ta gặp các thông báo lỗi khác nhau. Thường thì cách tốt nhất để học một cái gì đó là dạy nó. Tất nhiên, vào thời điểm thuật ngữ được thực hiện, có lẽ anh ta sẽ không cần nó nữa.

Kinh nghiệm cá nhân của tôi với GCC là mỗi thông báo lỗi liên quan đến một bộ lỗi "thông thường". Ví dụ: khi GCC nói "bạn đã quên &", điều đó thường có nghĩa là tôi quên dấu ngoặc đơn. Tất nhiên, những lỗi nào tương ứng với thông báo lỗi nào sẽ phụ thuộc vào lập trình viên, một lý do chính đáng khác để người bạn viết chú giải của riêng mình.

— Owen
nguồn

1

Tài liệu này có lợi ích cực kỳ quan trọng là nó có thể được đưa lên mạng (ngay cả khi nó chỉ có 5-10 mục) và sẽ là một điểm khác biệt lớn khi nộp đơn xin thực tập.

— Josh Rumbut