Phần mềm coi tất cả các cảnh báo là lỗi trừ


124

Trong Visual Studio, tôi có thể chọn tùy chọn "Xử lý cảnh báo là lỗi" để ngăn mã của tôi biên dịch nếu có bất kỳ cảnh báo nào. Nhóm của chúng tôi sử dụng tùy chọn này, nhưng có hai cảnh báo chúng tôi muốn giữ làm cảnh báo.

Có một tùy chọn để chặn các cảnh báo, nhưng chúng tôi muốn chúng hiển thị dưới dạng các cảnh báo, vì vậy nó sẽ không hoạt động.

Dường như cách duy nhất để có được hành vi mà chúng ta muốn là nhập danh sách mỗi số cảnh báo C # vào hộp văn bản "Cảnh báo cụ thể", ngoại trừ hai cảnh báo chúng ta muốn coi là cảnh báo.

Bên cạnh vấn đề đau đầu về bảo trì, nhược điểm lớn nhất của phương pháp này là một vài cảnh báo không có số, vì vậy chúng không thể được tham chiếu rõ ràng. Ví dụ: "Không thể giải quyết tham chiếu này. Không thể định vị cụm 'Dữ liệu ....'"

Có ai biết một cách tốt hơn để làm điều này?


Làm rõ cho những người không nhìn thấy ngay tại sao điều này hữu ích. Hãy suy nghĩ về cách hầu hết các cảnh báo hoạt động. Họ nói với bạn một cái gì đó là một chút trong mã bạn vừa viết. Mất khoảng 10 giây để sửa chúng và điều đó giữ cho cơ sở mã sạch hơn.

Cảnh báo "lỗi thời" rất khác với điều này. Đôi khi sửa nó có nghĩa là chỉ tiêu thụ một chữ ký phương thức mới. Nhưng nếu toàn bộ một lớp đã lỗi thời và bạn sử dụng nó nằm rải rác trong hàng trăm ngàn dòng mã, có thể mất hàng tuần hoặc nhiều hơn để sửa. Bạn không muốn bản dựng bị hỏng quá lâu, nhưng bạn chắc chắn KHÔNG muốn thấy cảnh báo về nó. Đây không chỉ là một trường hợp giả định - điều này đã xảy ra với chúng tôi.

Cảnh báo "#warning" theo nghĩa đen cũng là duy nhất. Tôi thường muốn kiểm tra nó, nhưng tôi không muốn phá vỡ công trình.


Bạn có thể vui lòng đặt khoảng trắng vào danh sách số lớn của bạn không? Nó đã nhồi lên các gói bọc.
Ray

Gawd Tôi ghét các quy tắc phức tạp được tạo ra bởi mọi người, đôi khi để làm dịu cái tôi của một số người cụ thể.
Jon Limjap

21
Tôi thấy quan điểm của ông về cảnh báo lỗi thời, điều này không phải là tùy tiện.
Ed S.

Theo kinh nghiệm của tôi, cho phép thậm chí một cảnh báo trong bản dựng của bạn cũng giống như thêm async / await đầu tiên. Sẽ sớm có hàng chục người trong số họ. Trong tất cả các thiết lập, tôi nhớ rằng một nhà phát triển có thể thấy ít hơn 10 cảnh báo trong cửa sổ Danh sách Lỗi trong VS. Tôi có thể đặt cược rằng khi có nhiều hơn 5 cảnh báo, phần lớn các nhà phát triển trong một nhóm sẽ không thể phát hiện ra một nhóm mới - trong khi bạn thiết lập, điều đó có nghĩa là họ sẽ không phát hiện ra cảnh báo rằng phương pháp đó đã lỗi thời toàn bộ mục đích của việc cảnh báo nó :) Kinh nghiệm của bạn với Neil này là gì?
tymtam

@mayu, nó là một câu hỏi hóc búa. Nhiều lần, tôi đã thấy những cảnh báo bị bỏ qua trong một thời gian dài. Nhưng cuối cùng, hoặc bạn hiển thị cảnh báo hoặc bạn không hiển thị gì cả. Nếu bạn đang hiển thị cảnh báo, ít nhất có khả năng ai đó đang học được điều gì đó hữu ích từ nó. Nếu bạn coi hầu hết các cảnh báo là lỗi, thì số ít còn lại có thể được chú ý nhiều hơn.
Neil

Câu trả lời:


155

Bạn có thể thêm một WarningsNotAsErrors-tag trong tệp dự án.

<PropertyGroup>
    ...
    ...
    <WarningsNotAsErrors>618,1030,1701,1702</WarningsNotAsErrors>
</PropertyGroup>

Lưu ý: 612618cả hai cảnh báo về Lỗi thời, không biết sự khác biệt nhưng dự án tôi đang thực hiện đang báo cáo Lỗi thời với cảnh báo 618.


24
Sự khác biệt giữa 612 và 618 là nhận xét của ObsoleteAttribution. Một ObsoleteAttribution không có bình luận sẽ tạo ra lỗi 612 và một lỗi với một bình luận sẽ tạo ra 618.
Marco Spatz

@MarcoSpatz Chính xác. Sau đó, chúng tôi có thể coi [Obsolete]các thành viên messagenulllỗi, trong khi chúng tôi chỉ để những người messageđược đặt cảnh báo. Nếu errortham số được đặt thành truetrong ObsoleteAttribute, CS0619 được tạo thay thế. Điều này dường như không hoạt động nếu messagenull(nhưng ai sẽ làm [Obsolete(null, true)]gì?).
Jeppe Stig Nielsen

Đối với F #, sử dụng --warnaserror-:618,1030trên trường Build-> Other flags. Tùy chọn dự án này chưa được triển khai cho các dự án F #. github.com/Microsoft/visualfsharp/issues/3395
Asik

2
Điều tốt để biết "WarningsNotAsErrors" tồn tại. Nó nên có sẵn trong cài đặt dự án mà không cần chỉnh sửa tập tin theo cách thủ công. Cảm ơn.
Thu hút

1
Microsoft thực sự đã làm hỏng việc này (và 11 năm sau, đã không sửa chữa mọi thứ!). Các thiết lập dự án thay đổi <NoWarn>, kém hơn trong hầu hết các trường hợp và không thể đưa <WarningsNotAsErrors>vào UI. Thanh danh.
dùng2864740

13

/ warnaserror / warnaserror-: 618


1
Cảm ơn về thông tin bạn vừa nhập. Mặc dù họ không giải quyết được vấn đề IDE, đây là những bình luận hữu ích nhất cho đến nay.
Neil

2
Nơi nào bạn thêm điều này?
checho

@checho, những công tắc đó sẽ được thêm vào dòng lệnh khi gọi msbuild. Đối với mục đích của chúng tôi, câu trả lời hàng đầu là hữu ích hơn, bởi vì chúng tôi có thể nướng nó vào dự án thay vì phải sửa đổi cách chúng tôi gọi msbuild.
Neil

Không hoạt động với MSBuild 15.9,21 + g9802d43bc3: MSBUILD : error MSB1001: Unknown switch. Switch: /warnaserror-:618
Paul B.

3

hoặc cụ thể hơn, trong trường hợp của bạn:

/ warnaserror / warnaserror-: 612,1030,1701,1702

điều này sẽ coi tất cả các cảnh báo là lỗi ngoại trừ những lỗi trong danh sách được phân tách bằng dấu phẩy của bạn


1

Tại sao bạn muốn tiếp tục thấy cảnh báo rằng bạn không coi là lỗi? Tôi bối rối về lý do tại sao điều này là mong muốn - hoặc bạn sửa chúng hoặc bạn không.

Hai tệp xây dựng / giải pháp khác nhau có hoạt động không - hoặc một tập lệnh để sao chép một và sau đó sửa đổi mức cảnh báo / mức cảnh báo là phù hợp. Có vẻ như có lẽ bạn muốn một số thực thi của trình biên dịch để squawk, nhưng những cái khác bạn muốn tiếp tục.

Vì vậy, các trình biên dịch chuyển đổi khác nhau có vẻ như là một cách tốt để đi. Bạn có thể làm điều này với các mục tiêu khác nhau - một mục được gỡ lỗi hoặc phát hành và các mục tiêu khác được gắn nhãn phù hợp về các cảnh báo.


7
Hầu hết các cảnh báo xảy ra do một sự nhầm lẫn đơn giản trong mã của tôi (ví dụ: tôi đã khai báo một biến mà tôi không sử dụng). Một cảnh báo lỗi thời thường xảy ra do thay đổi mã của người khác. Sửa lỗi này có thể mất vài tuần phát triển. #warning là một cảnh báo tôi muốn trong mã (có thể là bản sửa lỗi dài hạn).
Neil

4
Nói cách khác, có những cảnh báo rằng tôi không muốn phá vỡ công trình của mình. Nếu #warning phá vỡ bản dựng, thì tôi không bao giờ có thể kiểm tra một bản. Nếu Lỗi thời phá vỡ bản dựng, thì một nhóm khác mà chúng tôi phụ thuộc có thể vô tình phá vỡ bản dựng của nhóm chúng tôi chỉ bằng cách thêm một thuộc tính lỗi thời.
Neil

@Neil Tôi đồng ý với một số đối số của bạn, nhưng việc xóa một var bạn không sử dụng không mất nhiều thời gian bạn chắc chắn muốn biết rằng một nhóm khác đã làm một cái gì đó lỗi thời.
tymtam

@mayu, cảm ơn bình luận của bạn. Tôi đồng ý về một var bạn không sử dụng. Đó là lý do tại sao tôi sẽ có trình biên dịch coi nó là một lỗi. Tôi cũng đồng ý bạn muốn biết khi nào một cái gì đó đã lỗi thời. Nhưng nếu mất quá nhiều thời gian để cấu trúc lại thứ gì đó đã lỗi thời với mã của bạn, thì các lựa chọn của bạn là 1) Hãy coi cảnh báo này là cảnh báo 2) Hãy để bản dựng của bạn bị hỏng trong một thời gian dài 3) Một số giải pháp khác như tắt cảnh báo là lỗi. Với hầu hết các cảnh báo là lỗi, danh sách cảnh báo của bạn có thể bị thiếu, do đó bạn có nhiều khả năng nhận thấy khi chúng xuất hiện. Giải pháp ưa thích của bạn là gì?
Neil

1
@mayu, một nhóm khác (cho dù trong cùng một công ty hoặc bên ngoài nó) có thể muốn thông báo một cách hợp pháp rằng một lớp, phương thức, thành phần khác sẽ bị loại bỏ trong một khoảng thời gian. Thêm một thuộc tính là một cách tốt để báo hiệu điều này đến người tiêu dùng của thư viện. Tôi không thấy nó là rắc rối để làm điều này. Trong thực tế, thêm thuộc tính càng sớm càng tốt là một cách tốt để đảm bảo những người khác nhận thức được những thay đổi trong tương lai.
Neil

1

Tôi đang sử dụng cảnh báo coi là lỗi.

Trong một số trường hợp hiếm hoi, khi một số cảnh báo có thể chấp nhận xuất hiện (nghĩa là tham chiếu thành viên lỗi thời hoặc tài liệu bị thiếu trong các lớp tuần tự hóa XML), thì nó phải được loại bỏ rõ ràng với vô hiệu hóa #pragma (và có thể cung cấp lý do không có mã sạch như một bình luận cùng).

Sự hiện diện của chỉ thị này cũng cho phép tìm ra, người đã chấp nhận vi phạm cảnh báo này (bằng cách "đổ lỗi" cho kiểm soát phiên bản) trong trường hợp có một số câu hỏi.


3
Tôi cũng sử dụng điều này, mặc dù nó không giải quyết được các vấn đề được đề cập trong mô tả của tôi. Tôi muốn một số cảnh báo nhất định được coi là cảnh báo, không bị ẩn.
Neil

0

Tại sao không chỉ đơn giản là có một quy tắc "Bất cứ ai kiểm tra mã với bất kỳ cảnh báo nào bên trong nó ngoài 612, 1030, 1701 hoặc 1702 trong đó đều phải vào bảng trắng và viết một trăm lần 'Tôi sẽ không kiểm tra lại mã với các cảnh báo không được phép. ""


9
Chúc may mắn thực thi rằng ... Xử lý các cảnh báo là lỗi là một bước rất quan trọng để tăng chất lượng mã tổng thể nó sẽ buộc các nhà phát triển thực sự sửa mã của họ! Tất cả tự động hóa mưa đá, lao động chân tay là để thế kỷ 20: ish!
Andreas Magnusson

@AndreasMagnusson Nếu chỉ thiếu cảnh báo thực sự đảm bảo chất lượng mã ..
user2864740

2
@ user2864740: Đồng ý, không có đạn bạc. Nhưng đó là một sai lầm quá phổ biến để từ chối thứ gì đó hữu ích với tiền đề rằng đó không phải là viên đạn bạc.
Andreas Magnusson


-4

Đối với tôi, vấn đề gốc thực sự là sự kết hợp của các cảnh báo đối xử của bạn là lỗi, khi chúng rõ ràng là không và chính sách rõ ràng của bạn về việc cho phép đăng ký vi phạm điều này. Như bạn nói, bạn muốn có thể tiếp tục làm việc bất chấp cảnh báo. Bạn chỉ đề cập đến một vài cảnh báo mà bạn muốn có thể bỏ qua, nhưng nếu ai đó trong nhóm gây ra bất kỳ loại cảnh báo nào khác, bạn sẽ mất nhiều thời gian để khắc phục? Bạn có muốn bỏ qua điều đó không?

Giải pháp hợp lý sẽ là 1) Không cho phép đăng nhập nếu mã không được biên dịch (có nghĩa là những người đã tạo cảnh báo sẽ phải sửa chúng, vì thực tế, họ đã phá vỡ bản dựng) hoặc 2) coi cảnh báo là cảnh báo. Tạo hai cấu hình bản dựng, một cấu hình coi các cảnh báo là lỗi, có thể chạy thường xuyên để đảm bảo mã không có cảnh báo và một cấu hình khác, chỉ coi chúng là cảnh báo và cho phép bạn làm việc ngay cả khi có người khác đưa ra cảnh báo.


1
Sử dụng câu trả lời đã chọn, thật dễ dàng để thêm vào danh sách các cảnh báo được coi là cảnh báo. Điều đó làm việc tốt hơn nhiều so với một trong những giải pháp được đề xuất của bạn. Các cảnh báo rõ ràng không phải là lỗi, nhưng coi hầu hết các cảnh báo là lỗi có nghĩa là mã sẽ không bao giờ được kiểm tra trong các cảnh báo đó.
Neil
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.