Làm thế nào để giữ các dòng gỡ lỗi của riêng bạn mà không cần kiểm tra chúng?

Question

Khi làm việc trên một số mã, tôi thêm đăng nhập gỡ lỗi bổ sung của một số loại để làm cho nó dễ dàng hơn cho tôi để theo dõi nhà nước và các giá trị mà tôi quan tâm cho sửa chữa cụ thể này.

Nhưng nếu tôi kiểm tra điều này trong kho lưu trữ mã nguồn, đồng nghiệp của tôi sẽ tức giận với tôi vì đã làm ô nhiễm đầu ra Log và gây ô nhiễm mã.

Vậy làm cách nào để giữ các dòng mã này quan trọng đối với tôi, mà không kiểm tra chúng?

Làm rõ: Nhiều câu trả lời liên quan đến đầu ra nhật ký và bạn với mức nhật ký có thể lọc ra. Và tôi đồng ý với điều đó.

Nhưng. Tôi cũng đã đề cập đến vấn đề gây ô nhiễm mã thực tế. Nếu ai đó đặt một tuyên bố đăng nhập giữa mỗi dòng mã khác, để in giá trị của tất cả các biến tất cả các thời gian. Nó thực sự làm cho mã khó đọc. Vì vậy, tôi thực sự muốn tránh điều đó là tốt. Về cơ bản là không kiểm tra mã đăng nhập. Vì vậy, câu hỏi đặt ra là: làm thế nào để giữ các dòng ghi chép chuyên dụng của riêng bạn. Vì vậy, bạn có thể sử dụng chúng cho các bản dựng lỗi của bạn, mà không làm lộn xộn mã được kiểm tra.

Answer 1

Nếu chỉ objetive của mã gỡ lỗi bạn đang gặp vấn đề là để theo dõi các giá trị của một số varibles Tôi nghĩ rằng những gì bạn thực sự cần là một debugger. Với trình gỡ lỗi, bạn có thể xem trạng thái của bất kỳ biến nào trong bất kỳ thời điểm nào.

Nếu bạn không thể sử dụng trình gỡ lỗi, thì bạn có thể thêm một số mã để in các giá trị trong một số đầu ra gỡ lỗi. Nhưng mã này chỉ nên là một vài dòng mà mục tiêu của nó là làm cho việc sửa lỗi bạn đang thực hiện dễ dàng hơn. Một khi nó cam kết cố định nó cố định và sau đó bạn không nên cần thêm những dòng gỡ lỗi, vì vậy bạn phải xóa chúng. Không xóa tất cả các mã gỡ lỗi, mã gỡ lỗi tốt là rất hữu ích, chỉ xóa "cá nhân" của bạn truy tìm mã gỡ lỗi.

Nếu khắc phục quá lâu mà bạn muốn lưu tiến trình của bạn cam kết vào kho lưu trữ, thì những gì bạn cần là chi nhánh , trong nhánh này bạn có thể thêm quá nhiều mã như bạn muốn, nhưng bạn nên loại bỏ nó khi sáp nhập trong thân cây.

Answer 2

Bạn đang sử dụng hệ thống kiểm soát nguồn nào? Git cho phép bạn giữ các chi nhánh địa phương. Nếu tồi tệ hơn đến tồi tệ nhất, bạn chỉ có thể tạo chi nhánh 'Andreas' của riêng bạn trong kho, mặc dù quản lý chi nhánh có thể trở nên khá đau đớn.

Answer 3

Nhưng nếu tôi sẽ kiểm tra này trong vào kho mã nguồn, đồng nghiệp của tôi sẽ nổi giận với tôi cho ô nhiễm đầu ra Log và gây ô nhiễm mã.

Tôi hy vọng rằng khung nhật ký của bạn có khái niệm về mức nhật ký, để gỡ lỗi của bạn có thể dễ dàng bị tắt. Cá nhân tôi không thể thấy tại sao mọi người sẽ tức giận khi đăng nhập gỡ lỗi nhiều hơn - bởi vì họ chỉ có thể tắt nó đi!

Answer 4

Tại sao không bọc chúng trong các chỉ thị tiền xử lý (giả sử cấu trúc tồn tại bằng ngôn ngữ bạn chọn)?

#if DEBUG 
    logger.debug("stuff I care about"); 
#endif 

Ngoài ra, bạn có thể sử dụng cấp nhật ký như theo dõi hoặc gỡ lỗi, không được bật trong sản xuất.

if(logger.isTraceEnabled()) { 
    logger.log("My expensive logging operation"); 
} 

Bằng cách này, nếu có điều gì đó trong khu vực này mọc lên một ngày, bạn có thể quay lại ở mức đó và thực sự nhận được một số phản hồi hữu ích (hy vọng).

---

Lưu ý rằng cả hai giải pháp này sẽ vẫn cho phép đăng nhập báo cáo, nhưng tôi không thấy lý do chính đáng không phải là để họ đăng ký. Tôi đang cung cấp giải pháp để giữ chúng khỏi nhật ký sản xuất.

Answer 5

Tương tự như

#if DEBUG #endif.... 

Nhưng điều đó vẫn sẽ có nghĩa là bất cứ ai chạy với cấu hình 'Debug' sẽ tung ra những dòng này.

Nếu bạn thực sự muốn họ bỏ qua thì hãy sử dụng cấp độ nhật ký mà không ai khác sử dụng hoặc ....

Tạo một cấu hình chạy khác nhau gọi là MYDEBUGCONFIG và sau đó đặt gỡ lỗi mã của bạn ở giữa các khối như thế này:

#if MYDEBUGCONFIG 
...your debugging code 
#endif; 

Answer 6

Nếu đây là thực sự là một vấn đề đang diễn ra, tôi nghĩ rằng tôi muốn giả định rằng kho trung tâm là phiên bản tổng thể và tôi sẽ sử dụng các tệp vá để chứa sự khác biệt giữa phiên bản chính thức (phiên bản cuối cùng mà tôi đã thực hiện) và phiên bản của tôi có mã gỡ lỗi. Sau đó, khi tôi cần khôi phục bản sửa lỗi, tôi sẽ kiểm tra phiên bản chính thức, áp dụng bản vá của tôi (với lệnh patch), khắc phục sự cố và trước khi đăng ký, xóa bản vá với patch -R (đối với bản vá được đảo ngược).

Tuy nhiên, không cần thiết cho việc này. Bạn sẽ có thể đồng ý về một phương pháp bảo tồn thông tin trong dòng mã chính thức, với các cơ chế để kiểm soát lượng lỗi được tạo ra. Và nó sẽ có thể bất kể cho dù ngôn ngữ của bạn có biên dịch có điều kiện theo nghĩa C hay C++, với bộ xử lý trước C.

Answer 7

IMHO, bạn nên tránh giải pháp #if. Đó là cách thực hiện gỡ lỗi có điều kiện của C/C++. Thay vào đó, hãy gán tất cả các chức năng ghi/gỡ lỗi với ConditionalAttribute. Hàm khởi tạo của thuộc tính có trong một chuỗi. Phương thức này sẽ chỉ được gọi nếu định nghĩa tiền xử lý cụ thể có cùng tên với chuỗi thuộc tính được định nghĩa. Điều này có ý nghĩa thời gian chạy chính xác giống như giải pháp # if/# endif nhưng nó trông có vẻ tốt hơn trong mã.

Answer 8

Nếu bạn thực sự đang làm một cái gì đó như:

đặt một tuyên bố đăng nhập giữa mỗi dòng khác mã, để in giá trị của tất cả các biến tất cả thời điểm đó. Nó thực sự làm cho mã số khó đọc.

đó là vấn đề. Thay vào đó, hãy cân nhắc sử dụng khung kiểm tra và viết mã số gỡ lỗi tại đó. Mặt khác, nếu bạn đang viết chỉ là một vài dòng gỡ lỗi, thì bạn có thể quản lý để tránh những dòng đó bằng tay (vd loại bỏ các dòng có liên quan với trình soạn thảo trước khi commit và hoàn tác thay đổi sau khi hoàn thành) - nhưng tất nhiên nó phải rất không thường xuyên!

Answer 9

Tôi biết tôi sẽ nhận được số phiếu phủ định cho điều này ...
Nhưng nếu tôi là bạn, tôi chỉ cần xây dựng công cụ của riêng mình.

Nó sẽ đưa bạn một ngày cuối tuần, có, nhưng bạn sẽ giữ cho phong cách mã hóa của bạn, và kho lưu trữ của bạn sạch sẽ, và tất cả mọi người sẽ được hạnh phúc.

Không chắc chắn bạn đang sử dụng điều khiển nguồn nào. Với của tôi, bạn có thể dễ dàng có được một danh sách những thứ "đang chờ được kiểm tra". Và bạn có thể kích hoạt một cam kết, tất cả thông qua một API.

Nếu tôi có cùng nhu cầu đó, tôi sẽ thực hiện một chương trình để cam kết, thay vì sử dụng lệnh tích hợp trong GUI điều khiển nguồn. Chương trình của bạn sẽ đi qua danh sách các nội dung đang chờ xử lý, lấy tất cả các tệp bạn đã thêm/thay đổi, tạo bản sao của chúng, xóa tất cả các dòng nhật ký, cam kết và sau đó thay thế chúng bằng phiên bản của bạn.

Tùy thuộc vào dòng đăng nhập của bạn, bạn có thể phải thêm nhận xét đặc biệt vào cuối chúng để chương trình của bạn nhận ra chúng.

Một lần nữa, không nên tốn quá nhiều công sức, và nó không phải là một nỗi đau để sử dụng sau này.
Tôi không nghĩ rằng bạn sẽ tìm thấy một cái gì đó thực hiện điều này cho bạn đã làm (và để kiểm soát nguồn của bạn), nó khá cụ thể, tôi nghĩ.

Answer 10

gợi ý tiếp theo này là điên rồ không làm điều đó nhưng bạn có thể ...

Đắm mã đăng nhập cá nhân của bạn với ý kiến ​​như

// ##LOG-START## 
logger.print("OOh A log statment"); 
// ##END-LOG## 

Và trước khi bạn cam mã của bạn chạy một kịch bản shell mà loại bỏ các bản ghi của bạn.

Tôi thực sự sẽ không đề nghị điều này vì đó là ý tưởng rác rưởi, nhưng điều đó không bao giờ dừng bất kỳ ai.

Alternative bạn cũng có thể không thêm một lời nhận xét vào cuối mỗi dòng nhật ký và có một kịch bản loại bỏ chúng ...

logger.print("My Innane log message"); //##LOG 

Cá nhân tôi nghĩ rằng việc sử dụng một khuôn khổ khai thác gỗ thích hợp với một mức độ debug logging vv nên đủ tốt. Và xóa bất kỳ nhật ký thừa nào trước khi bạn gửi mã của mình.