Bạn có đọc lỗi biên dịch C hoặc C ++ sau lần đầu tiên không?

Tôi không bao giờ hiểu tại sao trình biên dịch C và C ++ cố gắng phục hồi từ các lỗi và tiếp tục phân tích cú pháp. Hầu như luôn luôn, lỗi đầu tiên tạo ra một luồng lỗi không có thật sẽ biến mất ngay sau khi lỗi đầu tiên được sửa. Sau vài năm kinh nghiệm, tôi chỉ đơn giản dừng lại xem xét bất kỳ lỗi nào ngoại trừ lỗi đầu tiên của mỗi tệp. Tôi chạy lại trình biên dịch và sau đó làm lại cho đến khi không còn lỗi nữa. Nó có phải là một thực tế phổ biến?

Đôi khi các lỗi không liên quan. Tôi thấy dễ dàng hơn khi xem danh sách các lỗi và khắc phục nguyên nhân gốc của một loạt các lỗi liên quan, sau đó sửa lỗi không liên quan tiếp theo . Nếu dự án lớn và mất một thời gian để xây dựng, tôi thấy làm việc theo cách này ít gây khó chịu hơn sửa lỗi đầu tiên, biên dịch lại, lặp lại ...

Nó phụ thuộc vào thời gian biên dịch . Ví dụ, nếu tôi biết rằng tôi vừa thay đổi một tiêu đề chính sẽ kích hoạt việc xây dựng lại toàn bộ dự án, tôi chắc chắn sẽ xem xét kỹ hơn phần còn lại của ngăn xếp lỗi và xem liệu tôi có thể sửa một số trong số chúng không. Điều đó mang lại cho tôi cảm giác tốt hơn khi tôi đứng lên để pha cà phê trong khi trình biên dịch chạy.

Có, tôi cũng làm như vậy, trừ khi tôi đang sử dụng trình biên dịch để giúp tôi cấu trúc lại trong trường hợp tôi thích danh sách đầy đủ các lỗi :)

Nếu có một khoảng trống trong các số dòng, trình biên dịch có thể đã phục hồi và sau đó tìm thấy một lỗi khác.

Thường chỉ cố gắng sửa một lỗi trong mỗi bó.

Trình biên dịch tốt hơn sẽ tạo ra kết quả tốt hơn và cung cấp cho bạn các lỗi hữu ích hơn sau lần đầu tiên, thường thông qua một số loại sửa lỗi tự động để có thể kiểm tra mã tốt ít nhất. Nhưng sau đó, tôi đã quen làm việc với Java, trong Eclipse, nơi các lỗi chính tả được phát hiện ngay lập tức và dễ dàng sửa chữa, và các lỗi trình biên dịch khác có xu hướng đa dạng hơn và dễ dàng hơn cho trình biên dịch phục hồi. Tôi chỉ có thể giả định rằng nó tương tự nhau khi làm việc trong IDE của Microsoft và những người khác trong C ++ hoặc C #.

Có - hoặc ít nhất là tôi lướt qua chúng. Khá dễ dàng để tìm ra nếu các lỗi có liên quan (thường là nhìn vào số dòng là đủ) và tôi thích sửa tất cả chúng trong một lần và sau đó biên dịch lại.

Tôi làm điều này (để đọc các lỗi qua cái đầu tiên) chỉ khi quá trình biên dịch 1 cpp rất dài. Hoặc không có sẵn. Sau đó, tôi muốn đảm bảo rằng tôi đã sửa mọi thứ tôi có thể xác định trong các lỗi trình biên dịch là không liên quan đến lỗi đầu tiên.

Khi tệp cpp của bạn có thể được biên dịch một mình và thực hiện trong chưa đầy một giây (hoặc bạn có lỗi trỏ "intellisense" trước khi quá trình biên dịch bắt đầu), bạn không phải làm điều này hầu hết thời gian.

Tôi hiện đang làm việc trong một dự án mà tôi không thể biên dịch một cpp một mình (và tôi không có hệ thống xây dựng nên tôi không thể thay đổi O__o đó) và một số tệp cpp có thể mất hơn mười phút để biên dịch ( ngay cả sau rất nhiều nỗ lực để giảm bớt điều đó, chúng tôi chỉ cắt giảm tới 50% thời gian biên dịch ban đầu ...).

Trong kiểu thiết lập biên dịch rất dài này, bạn có xu hướng suy nghĩ nhiều trước khi thuê "xây dựng" ... và thậm chí nghĩ rất nhiều sau đó, để có thể tìm thấy lỗi trước trình biên dịch vì bạn chắc chắn sẽ nhanh chóng hiểu được chúng hơn về mặt tinh thần .

Nó khá phổ biến để làm như bạn làm. Tôi thường nói với các thực tập sinh hoặc lập trình viên mới làm quen với số lượng lỗi để bỏ qua gần như tất cả các lỗi ngoại trừ lỗi đầu tiên. Đây rất có thể là một lỗi thực sự cần được sửa chữa, và không phải là một lỗi ảo gây hiểu lầm gây ra bởi một lỗi trước đó. Một số trình biên dịch (hầu hết?) Có tùy chọn dừng biên dịch sau lỗi đầu tiên vì lý do này. Xây dựng hệ thống thường có thể được cấu hình để dừng sau khi tệp đầu tiên cũng có lỗi.

Tuy nhiên, có những lý do để tiếp tục biên dịch sau khi phát hiện lỗi quá. Ví dụ: bạn có thể muốn đếm có bao nhiêu tệp có lỗi hoặc để xem liệu một tệp tiêu đề được bao gồm có gây ra lỗi trong nhiều tệp không.