2009-03-09 24 views
13

Hãy tưởng tượng một ai đó mã hóa như sau:C# Compiler Enhancement Đề xuất

string s = "SomeString"; 
s.ToUpper(); 

Chúng ta đều biết rằng trong ví dụ trên, các cuộc gọi đến “ToUpper()” phương pháp là vô nghĩa vì chuỗi trả lại không được xử lý ở tất cả các . Tuy nhiên, nhiều người mắc lỗi đó và dành thời gian cố gắng khắc phục sự cố là bằng cách tự hỏi “Tại sao các ký tự trên biến‘ s ’của tôi không được viết hoa” ???? Vì vậy, nó sẽ không tuyệt vời nếu có một thuộc tính có thể được áp dụng cho phương thức "ToUpper()" có thể mang lại lỗi trình biên dịch nếu đối tượng trả về không được xử lý không? Không. Một cái gì đó như sau:

[MustHandleReturnValueAttribute] 
public string ToUpper() 
{ 
… 
} 

Nếu trật tự cho mã này để biên dịch một cách chính xác người dùng sẽ phải xử lý giá trị trả về như thế này:

string s = "SomeString"; 
string uppers = s.ToUpper(); 

Tôi nghĩ rằng điều này sẽ làm cho nó tinh thể rõ ràng rằng bạn phải xử lý giá trị trả lại nếu không có không có điểm khi gọi hàm đó.

Trong trường hợp ví dụ về chuỗi, đây có thể không phải là vấn đề lớn nhưng tôi có thể nghĩ ra các lý do hợp lệ khác tại sao điều này có ích.

Các bạn nghĩ sao?

Cảm ơn.

+0

Tôi đã thực hiện điều đó trước đây, +1 –

+0

@Rene: điểm hợp lệ, +1 – Codex

Trả lời

8

Người gọi có phải là phương pháp cho các tác dụng phụ của nó, cho giá trị trả về của nó hoặc cho cả hai? Các hàm "Pure" (không có hiệu ứng và chỉ phục vụ để tính toán giá trị trả về) sẽ là tốt để chú thích như vậy, cả để loại bỏ lỗi bạn mô tả, cũng như để cho phép một số tối ưu hóa/phân tích tiềm năng. Có lẽ trong 5 năm nữa chúng ta sẽ thấy điều này xảy ra.

(Lưu ý rằng F # biên dịch sẽ cảnh báo bất cứ lúc nào bạn mặc nhiên bỏ qua một giá trị trả về. Các 'bỏ qua' chức năng có thể được sử dụng khi bạn muốn bỏ qua nó một cách rõ ràng.)

+0

Việc khái quát khái niệm về các chú thích 'thuần khiết' sẽ là tốt, bởi vì sau đó trình biên dịch có thể tối ưu hóa nhiều hơn. Tương tự như từ khóa const C++, thực sự. – Thomas

+0

Ngoài ra, việc thêm chú thích [Pure] sẽ giải quyết các vấn đề mà mọi người nói về bên dưới nơi họ gọi hàm và không quan tâm đến các tác dụng phụ. Tôi cho rằng đó là những gì tác giả đã thực sự nhận được. – Mason

0

Ít nhất một cảnh báo trình biên dịch sẽ hữu ích. Có lẽ họ thêm một cái gì đó tương tự cho C# 4.0 (Design-By-Contract).

+0

Tôi muốn cảnh báo về lỗi. Nếu bạn chỉ cần ném mã với nhau, bạn sẽ không muốn điều này để ngăn chặn bạn chạy mã, ví dụ. – Andy

+0

Thiết kế theo hợp đồng là về điều kiện tiên quyết, postconditions và bất biến. Không phải về việc thiết lập các điều khoản về cách các giá trị trả lại có thể/phải được sử dụng. –

0

này không đảm bảo cho một cảnh báo hoặc pragma. Có quá nhiều nơi mà nó được dự định để loại bỏ kết quả, và tôi sẽ khá khó chịu nhận được một cảnh báo/lỗi từ trình biên dịch chỉ vì phương pháp được trang trí với một số thuộc tính dodge.

Loại 'cảnh báo' này nên được chú thích trong Trình chỉnh sửa của IDE, như một biểu tượng nhỏ trên máng xối "Cảnh báo: Hủy bỏ giá trị trả về" hoặc tương tự.

2

Tôi không chắc chắn rằng tôi thích điều này. Tôi đã gọi nhiều phương thức trả về một giá trị mà tôi chọn không chụp. Thêm một số loại mặc định (trình biên dịch tạo ra một cảnh báo khi một giá trị trả về không được xử lý) có vẻ như sai với tôi.

Tôi đồng ý rằng điều gì đó dọc theo các dòng gợi ý có thể giúp lập trình viên mới nhưng thêm thuộc tính vào thời điểm này trong trò chơi sẽ chỉ ảnh hưởng đến một số lượng rất nhỏ các phương thức tương đối với cơ thể lớn hiện có. Cùng một lập trình viên cơ sở sẽ không bao giờ có được đầu của họ xung quanh vấn đề khi hầu hết các giá trị trả về không được giải quyết của họ không được gắn cờ bởi trình biên dịch.

Có thể đã có cách tốt đẹp trở lại khi nào nhưng những con ngựa ra khỏi chuồng.

+0

Việc thêm thuộc tính sẽ hơi nhiều, nhưng tôi không thấy lý do tại sao trình biên dịch không thể đưa ra cảnh báo "Mã không có hiệu lực". –

+0

Vấn đề đối với tôi là bạn đang sử dụng một cấu trúc hợp lệ và làm cho nó tạo ra một cảnh báo. Có, nó có thể gây nhầm lẫn nhưng tôi sử dụng các phương thức trả về giá trị tất cả thời gian mà không nắm bắt được giá trị trả về nói trên. – andleer

+0

bool DoStuff() {doStuff(); nếu (thành công) trả về true; return false; } Bây giờ khi gọi DoStuff() có thể có những lúc tôi không quan tâm đến thành công hay thất bại. Không cần phải kiểm tra kết quả ngay cả khi nghĩ rằng họ được trả lại. Lần khác, chắc chắn, tôi có thể quan tâm. – andleer

6

Nếu bạn đã Resharper nó sẽ làm nổi bật những thứ như thế này cho bạn. Không khuyên bạn nên resharper đủ cao, nó có rất nhiều bổ sung IDE hữu ích đặc biệt là xung quanh refactoring.

http://www.jetbrains.com/resharper/

1

tôi thực sự thích một cách để cờ một struct hay class như [Immutable], và có điều này xử lý tự động (với một cảnh báo) cho các phương pháp gọi mà không sử dụng các giá trị trở lại của họ trên các đối tượng không thay đổi. Điều này cũng có thể bảo vệ đối tượng bằng trình biên dịch từ những thay đổi sau khi tạo.

Nếu đối tượng thực sự là một đối tượng bất biến, thực sự sẽ không có cách nào để xử lý nó. Nó cũng có khả năng có thể được sử dụng bởi trình biên dịch để bắt những sai lầm phổ biến khác. Tuy nhiên,

Việc gắn thẻ chính phương thức này có vẻ ít hữu ích hơn đối với tôi. Tôi đồng ý với hầu hết các ý kiến ​​khác về điều đó. Nếu đối tượng có thể thay đổi, gọi phương thức có thể có các tác dụng phụ khác, vì vậy mã trên có thể hoàn toàn hợp lệ.

1

Tôi đang có flashback để đặt (void) phôi trên tất cả các printf() cuộc gọi vì tôi không thể nhận được Lint để đóng lên về giá trị trả lại bị bỏ qua.

Điều đó có nghĩa là, có vẻ như chức năng này phải ở trong một số công cụ kiểm tra mã thay vì bản thân trình biên dịch.

Các vấn đề liên quan