Tại sao gỡ lỗi tốt hơn trong IDE? [đóng cửa]

Tôi đã là một nhà phát triển phần mềm trong hơn hai mươi năm, lập trình bằng C, Perl, SQL, Java, PHP, JavaScript và gần đây là Python. Tôi chưa bao giờ gặp sự cố tôi không thể gỡ lỗi bằng cách sử dụng một số suy nghĩ cẩn thận và các printcâu lệnh gỡ lỗi được đặt đúng chỗ .

Tôi tôn trọng rằng nhiều người nói rằng các kỹ thuật của tôi còn sơ khai và sử dụng trình gỡ lỗi thực sự trong IDE tốt hơn nhiều. Tuy nhiên, theo quan sát của tôi, người dùng IDE dường như không gỡ lỗi nhanh hơn hoặc thành công hơn tôi có thể, sử dụng dao đá và da gấu của tôi. Tôi chân thành cởi mở để học các công cụ phù hợp, tôi chưa bao giờ thấy được lợi thế hấp dẫn khi sử dụng trình gỡ lỗi trực quan.

Hơn nữa, tôi chưa bao giờ đọc một hướng dẫn hoặc cuốn sách chỉ ra cách gỡ lỗi hiệu quả bằng cách sử dụng IDE, ngoài những điều cơ bản về cách đặt điểm dừng và hiển thị nội dung của các biến.

Tôi đang thiếu gì? Điều gì làm cho các công cụ gỡ lỗi IDE hiệu quả hơn nhiều so với việc sử dụng chu đáo các printcâu lệnh chẩn đoán ?

Bạn có thể đề xuất các tài nguyên (hướng dẫn, sách, screencasts) cho thấy các kỹ thuật gỡ lỗi IDE tốt hơn không?

Câu trả lời ngọt ngào! Cảm ơn tất cả mọi người đã dành thời gian. Rất sáng. Tôi đã bỏ phiếu nhiều, và bỏ phiếu không xuống.

Một số điểm đáng chú ý:

• Trình gỡ lỗi có thể giúp tôi kiểm tra đột xuất hoặc thay đổi các biến, mã hoặc bất kỳ khía cạnh nào khác của môi trường thời gian chạy, trong khi gỡ lỗi thủ công yêu cầu tôi dừng, chỉnh sửa và thực hiện lại ứng dụng (có thể yêu cầu biên dịch lại).
• Trình gỡ lỗi có thể gắn vào một quy trình đang chạy hoặc sử dụng kết xuất sự cố, trong khi với gỡ lỗi thủ công, "các bước để tạo lại" một lỗi là cần thiết.
• Trình gỡ lỗi có thể hiển thị các cấu trúc dữ liệu phức tạp, môi trường đa luồng hoặc ngăn xếp thời gian chạy đầy đủ một cách dễ dàng và theo cách dễ đọc hơn.
• Trình gỡ lỗi cung cấp nhiều cách để giảm thời gian và công việc lặp đi lặp lại để thực hiện hầu hết mọi tác vụ sửa lỗi.
• Trình gỡ lỗi trực quan và trình gỡ lỗi giao diện điều khiển đều hữu ích và có nhiều tính năng chung.
• Trình gỡ lỗi trực quan được tích hợp vào IDE cũng cho phép bạn truy cập thuận tiện vào chỉnh sửa thông minh và tất cả các tính năng khác của IDE, trong một môi trường phát triển tích hợp duy nhất (do đó có tên).

Một số ví dụ về một số khả năng mà trình gỡ lỗi IDE sẽ cung cấp cho bạn qua các thông báo theo dõi trong mã:

• Xem ngăn xếp cuộc gọi tại bất kỳ thời điểm nào, cung cấp cho bạn bối cảnh cho khung ngăn xếp hiện tại của bạn.
• Bước vào các thư viện mà bạn không thể biên dịch lại cho mục đích thêm dấu vết (giả sử bạn có quyền truy cập vào các biểu tượng gỡ lỗi)
• Thay đổi giá trị biến trong khi chương trình đang chạy
• Chỉnh sửa và tiếp tục - khả năng thay đổi mã trong khi nó đang chạy và ngay lập tức thấy kết quả của thay đổi
• Có thể xem các biến, nhìn thấy khi chúng thay đổi
• Có thể bỏ qua hoặc lặp lại các phần của mã , để xem cách mã sẽ thực hiện. Điều này cho phép bạn kiểm tra các thay đổi lý thuyết trước khi thực hiện chúng.
• Kiểm tra nội dung bộ nhớ trong thời gian thực
• Thông báo cho bạn khi một số ngoại lệ nhất định được ném, ngay cả khi chúng được ứng dụng xử lý.
• Điểm dừng có điều kiện ; chỉ dừng ứng dụng trong trường hợp đặc biệt để cho phép bạn phân tích ngăn xếp và biến.
• Xem ngữ cảnh luồng trong các ứng dụng đa luồng, có thể khó đạt được bằng dấu vết (vì các dấu vết từ các luồng khác nhau sẽ được xen kẽ trong đầu ra).

Tóm lại, các câu lệnh in là (nói chung) tĩnh và bạn sẽ cần biên dịch lại để có thêm thông tin nếu các câu lệnh gốc của bạn không đủ chi tiết. IDE loại bỏ rào cản tĩnh này, cung cấp cho bạn bộ công cụ động trong tầm tay.

Khi tôi mới bắt đầu viết mã, tôi không thể hiểu được vấn đề lớn với trình gỡ lỗi là gì và tôi nghĩ rằng tôi có thể đạt được bất cứ điều gì với dấu vết (được cho là trên unix và trình gỡ lỗi là GDB). Nhưng một khi bạn học cách sử dụng đúng trình gỡ lỗi đồ họa, bạn không muốn quay lại để in các câu lệnh.

• Trình gỡ lỗi IDE cho phép bạn thay đổi giá trị của các biến trong thời gian chạy.

• Trình gỡ lỗi IDE cho phép bạn xem giá trị của các biến bạn không biết bạn muốn thấy khi bắt đầu thực thi.

• Trình gỡ lỗi IDE cho phép bạn xem ngăn xếp cuộc gọi và kiểm tra trạng thái của hàm thông qua các giá trị lạ. (nghĩ rằng chức năng này được gọi từ hàng trăm địa điểm, bạn không biết những giá trị kỳ lạ này đến từ đâu)

• Trình gỡ lỗi IDE cho phép bạn phá vỡ điều kiện thực thi tại bất kỳ điểm nào trong mã, dựa trên một điều kiện, không phải số dòng.

• Trình gỡ lỗi IDE sẽ cho phép bạn kiểm tra trạng thái của chương trình trong trường hợp ngoại lệ chưa được xử lý thay vì chỉ xuất hiện.

Đây là một điều mà bạn chắc chắn không thể gỡ lỗi với câu lệnh "in", đó là khi một khách hàng mang đến cho bạn bộ nhớ và nói "chương trình của bạn bị hỏng, bạn có thể cho tôi biết tại sao không?"

• In tất cả các câu lệnh thông qua mã của bạn làm giảm khả năng đọc.
• Thêm và xóa chúng cho mục đích gỡ lỗi chỉ tốn thời gian
• Trình gỡ lỗi theo dõi ngăn xếp cuộc gọi giúp dễ dàng xem bạn đang ở đâu
• Các biến có thể được sửa đổi khi đang bay
• Các lệnh Adhoc có thể được thực thi trong khi tạm dừng thực thi để hỗ trợ chẩn đoán
• Có thể được sử dụng IN CONJUNCTION với các câu lệnh in: Debug.Write ("...")

Tôi nghĩ rằng gỡ lỗi bằng cách sử dụng các câu lệnh in là một nghệ thuật bị mất và rất quan trọng đối với mọi nhà phát triển để học hỏi. Khi bạn biết cách thực hiện điều đó, một số lớp lỗi nhất định trở nên dễ dàng hơn để gỡ lỗi theo cách đó hơn là thông qua một IDE. Các lập trình viên biết kỹ thuật này cũng có cảm giác thực sự tốt về những thông tin hữu ích để đưa vào một thông điệp tường trình (chưa kể đến việc bạn thực sự sẽ đọc nhật ký) cho mục đích không gỡ lỗi.

Điều đó nói rằng, bạn thực sự nên biết cách sử dụng trình gỡ lỗi từng bước, vì đối với một loại lỗi khác, nó dễ dàng hơn. Tôi sẽ để lại cho đến những câu trả lời xuất sắc khác đã được đăng để giải thích tại sao :)

Off đỉnh đầu của tôi:

1. Gỡ lỗi các đối tượng phức tạp - Trình gỡ lỗi cho phép bạn bước sâu vào bên trong đối tượng. Nếu đối tượng của bạn có một mảng các đối tượng phức tạp, các câu lệnh in sẽ chỉ đưa bạn đến nay.
2. Khả năng bước qua mã - Trình gỡ lỗi cũng sẽ cho phép bạn bỏ qua mã quá khứ mà bạn không muốn thực thi. Đúng, bạn cũng có thể làm điều này bằng tay, nhưng đó là nhiều mã hơn bạn phải tiêm.

Thay thế cho gỡ lỗi trong IDE, bạn có thể dùng thử Bảng điều khiển PHP mở rộng tuyệt vời của Google Chrome với thư viện php cho phép:

• Xem lỗi & ngoại lệ trong bảng điều khiển Chrome JavaScript và trong cửa sổ bật lên thông báo.
• Kết xuất bất kỳ loại biến.
• Thực thi mã PHP từ xa.
• Bảo vệ truy cập bằng mật khẩu.
• Nhật ký bảng điều khiển nhóm theo yêu cầu.
• Chuyển đến tập tin lỗi: dòng trong trình soạn thảo văn bản của bạn.
• Sao chép dữ liệu lỗi / gỡ lỗi vào clipboard (đối với người kiểm tra).

Tôi đã không phát triển được gần 20 năm, nhưng tôi thấy rằng bằng cách sử dụng IDE / trình gỡ lỗi tôi có thể:

• xem tất cả các loại điều mà tôi có thể không nghĩ là đã bao gồm trong một tuyên bố in
• bước qua mã để xem nó có khớp với đường dẫn tôi nghĩ nó sẽ đi không
• đặt các biến thành các giá trị nhất định để làm cho mã lấy các nhánh nhất định

Một lý do để sử dụng IDE có thể là các IDE hiện đại hỗ trợ nhiều hơn các điểm dừng đơn giản. Ví dụ: Visual Studio cung cấp các tính năng sửa lỗi nâng cao sau:

• xác định các điểm dừng có điều kiện (chỉ ngắt khi một điều kiện được đáp ứng hoặc chỉ vào lần thứ n, câu lệnh tại điểm dừng được thực thi)
• phá vỡ một ngoại lệ chưa được xử lý hoặc bất cứ khi nào một trò chơi điện tử (cụ thể) sẽ bị ném
• thay đổi biến trong khi gỡ lỗi
• lặp lại một đoạn mã bằng cách đặt dòng tiếp theo được thực thi
• Vân vân.

Ngoài ra, khi sử dụng trình gỡ lỗi, bạn sẽ không phải xóa tất cả các câu lệnh in của mình sau khi đã gỡ lỗi xong.

Một điều mà tôi ngạc nhiên tôi chưa thấy trong một câu trả lời khác là 2 phương pháp gỡ lỗi không loại trừ lẫn nhau .

printfgỡ lỗi có thể hoạt động khá độc đáo ngay cả khi bạn đang sử dụng trình gỡ lỗi tiêu chuẩn (cho dù dựa trên IDE hay không). Đặc biệt với khung đăng nhập để bạn có thể để lại tất cả hoặc hầu hết trong sản phẩm được phát hành để giúp chẩn đoán các vấn đề của khách hàng.

Như đã lưu ý trong hầu hết các câu trả lời khác ở đây, điều thú vị chính của trình gỡ lỗi tiêu chuẩn là nó cho phép bạn dễ dàng kiểm tra (và có khả năng thay đổi) các chi tiết của trạng thái chương trình. Bạn không cần phải biết trước những gì bạn có thể muốn xem - tất cả đều có sẵn trong tầm tay của bạn (nhiều hơn hoặc ít hơn).

Theo kinh nghiệm của tôi, các bản in đơn giản có một lợi thế rất lớn mà dường như không ai nhắc đến.

Vấn đề với trình gỡ lỗi IDE là mọi thứ xảy ra ở thời gian thực. Bạn tạm dừng chương trình tại một thời điểm nhất định, sau đó bạn bước qua các bước một lần và không thể quay lại nếu bạn đột nhiên muốn xem những gì đã xảy ra trước đó. Điều này hoàn toàn mâu thuẫn với cách thức hoạt động của bộ não. Bộ não thu thập thông tin, và dần dần hình thành một ý kiến. Có thể cần phải lặp lại các sự kiện nhiều lần để làm như vậy, nhưng một khi bạn đã bước qua một điểm nhất định, bạn không thể quay lại.

Ngược lại với điều này, một loạt các bản in / ghi nhật ký được chọn cung cấp cho bạn một "phép chiếu không gian của các sự kiện tạm thời". Nó cung cấp cho bạn một câu chuyện hoàn chỉnh về những gì đã xảy ra, và bạn có thể quay lại và thứ tư nhiều lần rất dễ dàng chỉ bằng cách cuộn lên xuống. Nó giúp bạn dễ dàng trả lời các câu hỏi như "đã xảy ra A trước khi B xảy ra". Nó có thể làm cho bạn thấy các mẫu bạn thậm chí không tìm kiếm.

Vì vậy, theo kinh nghiệm của tôi. IDE và trình gỡ lỗi là những công cụ tuyệt vời để giải quyết các vấn đề đơn giản khi một cái gì đó trong một ngăn xếp cuộc gọi bị lỗi và khám phá trạng thái hiện tại của máy trong một sự cố nhất định.

Tuy nhiên, khi chúng ta tiếp cận các vấn đề khác hơn, trong đó sự thay đổi dần dần của trạng thái có liên quan. Ví dụ, trong đó một thuật toán làm hỏng cấu trúc dữ liệu, chính điều đó đã khiến thuật toán anohter thất bại. Hoặc nếu chúng ta muốn trả lời các câu hỏi như "mức độ thường xuyên xảy ra", "hãy làm mọi thứ theo thứ tự và theo cách mà tôi tưởng tượng chúng xảy ra". vv Sau đó, kỹ thuật ghi / in "fashined" cũ có một lợi thế rõ ràng.

Điều tốt nhất là sử dụng một trong hai kỹ thuật khi nó phù hợp nhất, ví dụ sử dụng ghi nhật ký / bản in để gặp một số lỗi và tạm dừng tại một điểm dừng nơi chúng ta cần khám phá chi tiết hơn về trạng thái hiện tại.

Cũng có những cách tiếp cận lai. Ví dụ: khi bạn thực hiện console.log (đối tượng), bạn sẽ nhận được tiện ích cấu trúc dữ liệu trong nhật ký mà bạn có thể mở rộng và khám phá chi tiết hơn. Đây là lợi thế rõ ràng gấp nhiều lần so với nhật ký văn bản "chết".

Bởi vì gỡ lỗi các ứng dụng đa luồng với các câu lệnh in sẽ thúc đẩy bạn chuối. Có, bạn vẫn có thể làm điều đó với các câu lệnh in nhưng bạn cần rất nhiều trong số chúng và làm sáng tỏ bản in liên tiếp ra khỏi câu lệnh để mô phỏng thực thi đa luồng sẽ mất nhiều thời gian.

Não người chỉ có một luồng không may.

Vì bạn đã yêu cầu con trỏ tới sách ... Theo như Windows gỡ lỗi, John Robbins có một số phiên bản của một cuốn sách hay về gỡ lỗi Windows:

Ứng dụng gỡ lỗi cho Microsoft .NET và Microsoft Windows

Lưu ý rằng phiên bản gần đây nhất ( Gỡ lỗi Ứng dụng Microsoft .NET 2.0 ) chỉ là .NET, vì vậy bạn có thể muốn có phiên bản cũ hơn (như trong liên kết đầu tiên) nếu bạn muốn gỡ lỗi mã gốc (bao gồm cả .NET và bản địa).

Cá nhân tôi cảm thấy câu trả lời đơn giản như "Trình gỡ lỗi tích hợp / IDE cung cấp cho bạn rất nhiều thông tin khác nhau một cách nhanh chóng mà không cần phải bấm lệnh. Thông tin có xu hướng ở đó trước mặt bạn mà bạn không nói cho nó biết cho bạn xem.

Sự dễ dàng trong đó thông tin có thể được lấy là điều làm cho chúng tốt hơn là chỉ gỡ lỗi dòng lệnh hoặc gỡ lỗi "printf".

Ưu điểm của trình gỡ lỗi so với printf ( lưu ý không phải là trình gỡ lỗi IDE mà là bất kỳ trình gỡ lỗi nào )

1. Có thể đặt điểm quan sát. Đây là một trong những cách yêu thích của tôi để tìm các lỗi bộ nhớ

2. Có thể gỡ lỗi nhị phân mà bạn không thể biên dịch lại vào lúc này

3. Có thể gỡ lỗi một nhị phân mất nhiều thời gian để biên dịch lại

4. Có thể thay đổi các biến khi đang bay

5. Có thể gọi các chức năng một cách nhanh chóng

6. Không có vấn đề trong đó stHRenets gỡ lỗi không được xóa và do đó vấn đề thời gian không thể được gỡ lỗi một cách nhanh chóng

7. Trình gỡ lỗi giúp với các bãi chứa cốt lõi, in báo cáo không '

Đây là những gì tôi sử dụng nhiều nhất trên các cửa sổ gỡ lỗi VS.NET:

• Gọi ngăn xếp, cũng là một cách tuyệt vời để tìm ra mã của người khác
• Người dân địa phương & Đồng hồ.
• Cửa sổ ngay lập tức, về cơ bản là bảng điều khiển C # và cũng cho phép tôi thay đổi nội dung biến, khởi tạo công cụ, v.v.
• Khả năng bỏ qua một dòng, đặt câu lệnh tiếp theo được thực thi ở một nơi khác.
• Khả năng di chuột qua các biến và có một mẹo công cụ cho tôi thấy các giá trị của chúng.

Tóm lại, nó cho tôi cái nhìn 360 độ về trạng thái mã thực thi của tôi, không chỉ là một cửa sổ nhỏ.

Không bao giờ tìm thấy một cuốn sách dạy loại công cụ này, nhưng một lần nữa, nó có vẻ khá đơn giản, nó khá nhiều WYSIWYG.

• Trình gỡ lỗi có thể đính kèm vào một quy trình đang chạy

• Thường dễ dàng hơn để gỡ lỗi mã luồng từ trình gỡ lỗi

Với trình gỡ lỗi IDE, bạn có thể thấy các giá trị của TẤT CẢ các biến trong phạm vi hiện tại (tất cả các cách lên ngăn xếp cuộc gọi) bất cứ khi nào bạn dừng thực thi.

Báo cáo In có thể là tuyệt vời nhưng bán phá giá rất nhiều thông tin vào màn hình tại bất kỳ nơi nào có thể tạo ra một toàn bộ rất nhiều báo cáo in.

Ngoài ra, nhiều trình gỡ lỗi IDE cho phép bạn nhập và đánh giá các phương thức và đánh giá các thành viên trong khi bạn bị tạm dừng, điều này làm tăng thêm số lượng báo cáo in bạn phải làm.

Tôi cảm thấy rằng trình gỡ lỗi tốt hơn cho một số ngôn ngữ so với những ngôn ngữ khác tuy nhiên ...

Ý kiến ​​chung của tôi là các trình gỡ lỗi IDE hoàn toàn tuyệt vời đối với các ngôn ngữ được quản lý như Java hoặc C #, khá hữu ích cho C ++ và không hữu ích cho các ngôn ngữ script như Python (nhưng có thể là tôi chưa thử tốt trình gỡ lỗi cho bất kỳ ngôn ngữ kịch bản nào).

Tôi hoàn toàn thích trình gỡ lỗi trong IntelliJ IDEA khi tôi phát triển Java. Tôi chỉ sử dụng các câu lệnh in khi tôi sử dụng Python.

Như ai đó đã nói ở trên: Debugger! = IDE.

gdb và (trở lại trong ngày) TurboDebugger (độc lập) hoạt động tốt đối với các ngôn ngữ họ hỗ trợ [ed], cảm ơn bạn. (hoặc một công nghệ thậm chí cũ hơn: Trình gỡ lỗi của clip được liên kết với chính tệp thực thi xBase) - không ai trong số này yêu cầu IDE

Ngoài ra, mặc dù mã hóa C / ++ hiếm hơn, các câu lệnh printf đôi khi che giấu chính lỗi mà bạn đang cố gắng tìm! (ví dụ: sự cố khởi tạo trong các vars tự động trên ngăn xếp hoặc phân bổ / căn chỉnh bộ nhớ)

Cuối cùng, như những người khác đã nêu, bạn có thể sử dụng cả hai. Một số vấn đề thời gian thực hầu như yêu cầu in, hoặc ít nhất là "* video_dbg = (is_good? '+': '-');" một nơi nào đó vào bộ nhớ video. Tuổi của tôi đang hiển thị, đây là dưới DOS :-)

TMTOWTDI

Ngoài hầu hết những gì các áp phích khác đã nói, tôi thực sự thích bước qua từng dòng cùng với máy tính, vì nó buộc tôi phải suy nghĩ về từng dòng một. Thường thì tôi sẽ bắt lỗi mà không cần nhìn vào các giá trị biến vì tôi buộc phải nhìn vào nó khi tôi nhấp vào nút 'dòng tiếp theo'. Tuy nhiên, tôi không nghĩ câu trả lời của tôi sẽ giúp bạn, Bill, bởi vì bạn có thể đã có kỹ năng này rồi.

Theo như tài nguyên học tập, tôi chưa sử dụng bất kỳ - tôi chỉ khám phá tất cả các menu và tùy chọn.

Đây có phải là câu hỏi thậm chí thực sự từ lập trình viên thực sự?

Bất cứ ai đã dành thậm chí 5 phút để gỡ lỗi với các câu lệnh in và gỡ lỗi với IDE - nó sẽ OCCUR cho anh ấy / cô ấy mà không cần hỏi!

Tôi đã sử dụng cả bản in và IDE để gỡ lỗi và tôi muốn gỡ lỗi bằng IDE. Lần duy nhất đối với tôi khi nó không hoạt động là trong những tình huống nghiêm trọng (như gỡ lỗi trò chơi trực tuyến) khi bạn xả mã bằng các câu lệnh in và sau đó xem các tệp nhật ký sau khi nó bị lỗi khủng khiếp. Sau đó, nếu bạn vẫn không thể tìm ra nó, thêm nhiều bản in và lặp lại.

Chỉ muốn đề cập đến một tính năng hữu ích của trình gỡ lỗi giao diện điều khiển so với printf và vs trình gỡ lỗi trong IDE.

Bạn có thể đính kèm vào một ứng dụng từ xa (rõ ràng, được biên dịch ở chế độ DEBUG) và kiểm tra trạng thái của nó để loại bỏ đầu ra của trình gỡ lỗi vào một tệp bằng POSIX tee tiện ích . So với printf, bạn có thể chọn nơi xuất trạng thái trong thời gian chạy.

Nó giúp tôi rất nhiều khi tôi gỡ lỗi các ứng dụng Adobe Flash được triển khai trong môi trường khắc nghiệt . Bạn chỉ cần xác định một số hành động in trạng thái cần thiết trong mỗi điểm dừng, khởi động trình gỡ lỗi giao diện điều khiển fdb | tee output.logvà đi qua một số điểm dừng. Sau đó, bạn có thể in nhật ký và phân tích thông tin bằng cách so sánh kỹ lưỡng trạng thái trong các điểm dừng khác nhau.

Thật không may, tính năng này [đăng nhập vào một tệp] hiếm khi có sẵn trong trình gỡ lỗi GUI, khiến các nhà phát triển so sánh trạng thái của các đối tượng trong đầu họ.

Nhân tiện, ý kiến ​​của tôi là người ta nên lập kế hoạch gỡ lỗi ở đâu và trước khi bắt đầu trình gỡ lỗi.

Một điều nữa là nếu bạn tham gia một dự án cũ mới và không ai thực sự biết mã đang làm gì thì nó không thể gỡ lỗi bằng cách lặp lại các biến / đối tượng / ... b / c bạn không biết mã đó là gì thực hiện ở tất cả.

Trong công việc của mình, tôi đang đối mặt chính xác với tình huống đó và XDebuging trực quan giúp tôi có ý tưởng về những gì đang xảy ra và ở đâu, ở tất cả.

Trân trọng

Raffael

Ngoài nhiều điều đã được đề cập, một trong những ưu điểm quan trọng nhất của trình gỡ lỗi so với printf là sử dụng các câu lệnh printf giả định rằng bạn biết lỗi này nằm ở chức năng nào. Trong nhiều trường hợp bạn không làm như vậy, vì vậy bạn phải đưa ra một vài dự đoán và thêm các câu lệnh in vào nhiều chức năng khác để bản địa hóa nó. Lỗi có thể nằm trong mã khung hoặc ở một nơi nào đó cách xa nơi bạn nghĩ. Trong trình gỡ lỗi, việc đặt các điểm dừng để kiểm tra trạng thái trong các khu vực khác nhau của mã và tại các thời điểm khác nhau dễ dàng hơn nhiều.

Ngoài ra, một trình gỡ lỗi đàng hoàng sẽ cho phép bạn thực hiện gỡ lỗi kiểu printf bằng cách đính kèm các điều kiện và hành động với các điểm dừng, để bạn vẫn giữ được lợi ích của việc gỡ lỗi printf, nhưng không sửa đổi mã.

Gỡ lỗi trong IDE là vô giá trong môi trường không có bản ghi lỗi và quyền truy cập shell, chẳng hạn như máy chủ được chia sẻ. Trong trường hợp đó, một IDE có trình gỡ lỗi từ xa là công cụ duy nhất cho phép bạn thực hiện những việc đơn giản như xem stderrhoặc stdout.

Một vấn đề với việc sử dụng các câu lệnh in là nó làm cho mã của bạn bị rối. IE, bạn có một chức năng với 10 phần và nó biết nó bị hỏng ở đâu đó, nhưng bạn không chắc chắn ở đâu. Vì vậy, bạn thêm vào 10 câu lệnh in thêm để xác định lỗi ở đâu. Khi bạn đã tìm thấy và giải quyết lỗi của mình, bây giờ bạn phải dọn sạch bằng cách xóa tất cả các câu lệnh in đó. Có lẽ bạn sẽ làm điều đó. Có thể bạn sẽ quên và nó sẽ kết thúc sản xuất và bảng điều khiển của người dùng của bạn sẽ có đầy đủ các bản in gỡ lỗi.

Wauw, tôi có thích câu hỏi này không Tôi chưa bao giờ dám đặt ra ...

Dường như mọi người chỉ có cách làm việc khác nhau. Đối với tôi những gì làm việc tốt nhất là:

• Có một mô hình đầu óc vững chắc về mã của tôi, bao gồm cả quản lý bộ nhớ
• Sử dụng thiết bị (như báo cáo in) để theo dõi những gì đang xảy ra.

Tôi đã kiếm được chương trình sống của mình hơn 40 năm nay, làm việc tại các ứng dụng khoa học và kỹ thuật không tầm thường trong C ++ và Python hàng ngày và tôi có kinh nghiệm cá nhân rằng trình gỡ lỗi không giúp tôi một chút.

Tôi không nói điều đó tốt. Tôi không nói đó là xấu. Tôi chỉ muốn chia sẻ nó.

Nó không chỉ là gỡ lỗi. Một IDE giúp bạn xây dựng phần mềm tốt hơn nhanh hơn bằng nhiều cách:

• công cụ tái cấu trúc
• intellisense để làm cho api dễ khám phá hơn hoặc nhắc nhở chính tả / trường hợp chính xác của các vật phẩm quen thuộc (không sử dụng nhiều nếu bạn đã sử dụng cùng một hệ thống trong 15 năm, nhưng điều đó rất hiếm)
• tiết kiệm khi gõ bằng cách tự động hoàn thành tên biến và tên lớp
• tìm một số loại lỗi nhất định trước khi bạn bắt đầu biên dịch
• Tự động chuyển đến các khai báo / định nghĩa biến / phương thức / lớp, ngay cả khi chúng không nằm trong cùng một tệp hoặc thư mục.
• Phá vỡ các ngoại lệ chưa được xử lý và xử lý

Tôi có thể tiếp tục.