Tại sao StyleCop đề xuất phương thức tiền tố hoặc cuộc gọi thuộc tính bằng "this"?

Question

Tôi đã cố gắng làm theo hướng dẫn của StyleCop về một dự án, để xem liệu mã kết quả có tốt hơn không. Hầu hết các quy tắc đều hợp lý hoặc có ý kiến ​​về tiêu chuẩn mã hóa, nhưng có một quy tắc giải đố tôi, bởi vì tôi chưa thấy ai khác giới thiệu nó, và vì tôi không thấy rõ lợi ích của nó:

SA1101: Cuộc gọi tới {method hoặc tên thuộc tính} phải bắt đầu bằng 'this'. tiền tố để chỉ ra rằng mục là thành viên của lớp.

Mặt khác, mã rõ ràng là tiết lộ hơn, vậy lợi ích của việc tuân theo quy tắc đó là gì? Có ai ở đây tuân theo quy tắc đó không?

Answer 1

Nó có thể làm cho mã rõ ràng hơn trong nháy mắt. Khi bạn sử dụng this, việc này dễ dàng hơn:

• Cho các thành viên tĩnh và ví dụ cách nhau. (Và phân biệt các phương pháp ví dụ từ các đại biểu.)
• Phân biệt các thành viên cá thể từ các biến và tham số cục bộ (không sử dụng quy ước đặt tên).

Answer 2

Tôi làm theo nó, bởi vì tôi nghĩ rằng nó thực sự thuận tiện để có thể nói riêng truy cập vào các thành viên tĩnh và dụ ở cái nhìn đầu tiên.

Và tất nhiên tôi phải sử dụng nó trong các nhà xây dựng của tôi, bởi vì tôi thường cung cấp cho các tham số hàm tạo cùng tên với trường mà giá trị của chúng được gán cho. Vì vậy, tôi cần "này" để truy cập vào các lĩnh vực.

Answer 3

Ngoài ra, bạn có thể sao chép tên biến trong một hàm để sử dụng 'this' có thể làm cho nó rõ ràng hơn.

class foo { 
    private string aString; 

    public void SetString(string aString){ 
    //this.aString refers to the class field 
    //aString refers to the method parameter   
    this.aString = aString; 
    } 
} 

Answer 4

tôi không thực sự làm theo hướng dẫn này, trừ khi tôi đang ở trong các tình huống bạn cần nó:

• có một sự nhập nhằng thực tế - chủ yếu này tác động hoặc nhà thầu (this.name = name;) hoặc những thứ như Equals (return this.id == other.id;)
• bạn muốn chuyển tham chiếu đến phiên bản hiện tại
• bạn muốn gọi một phương thức tiện ích mở rộng trên phiên bản hiện tại

Khác với điều tôi xem là sự lộn xộn này. Vì vậy, tôi tắt quy tắc.

Answer 5

Tôi nghĩ rằng bài viết này giải thích nó một chút

http://blogs.msdn.microsoft.com/sourceanalysis/archive/2008/05/25/a-difference-of-style.aspx

... một nhà phát triển trẻ rực rỡ tại Microsoft (ok, đó là tôi) đã quyết định mang nó theo mình để viết một công cụ nhỏ có thể phát hiện chênh lệch từ kiểu C# được sử dụng trong nhóm của anh ấy. StyleCop ra đời. Trong vài năm tới, chúng tôi đã tập hợp tất cả các nguyên tắc về phong cách C# mà chúng tôi có thể tìm thấy từ các nhóm khác nhau trong Microsoft và chọn tất cả các phương pháp hay nhất phổ biến cho các kiểu này. Chúng đã hình thành bộ quy tắc StyleCop đầu tiên.Một trong những quy tắc sớm nhất được đưa ra từ nỗ lực này là sử dụng tiền tố tiền tố này để gọi ra các thành viên của nhóm và loại bỏ bất kỳ tiền tố gạch dưới nào khỏi tên trường. C# phong cách đã chính thức phát triển ngoài bộ tộc C++ cũ của nó.

Answer 6

Lưu ý rằng trình biên dịch không quan tâm cho dù bạn có tiền tố tài liệu tham khảo với this hay không (trừ khi có một vụ va chạm tên với một biến địa phương và một lĩnh vực hoặc bạn muốn gọi một phương pháp mở rộng trên dụ hiện tại.)

Tùy theo phong cách của bạn. Cá nhân tôi loại bỏ this. từ mã như tôi nghĩ rằng nó làm giảm tỷ lệ tín hiệu để tiếng ồn.

Chỉ vì Microsoft sử dụng kiểu này trong nội bộ không có nghĩa là bạn phải làm như vậy. StyleCop dường như là một công cụ MS-internal đã được công khai. Tôi là tất cả đối với tôn trọng những công ước Microsoft xung quanh việc công cộng, chẳng hạn như:

• tên loại là trong PascalCase
• tên tham số là trong camelCase
• giao diện nên được bắt đầu bằng chữ I
• sử dụng tên số ít cho enums, ngoại trừ khi chúng là [Flags]

... nhưng những gì xảy ra trong cõi riêng của mã của bạn là tốt, riêng tư. Làm bất cứ điều gì nhóm của bạn đồng ý.

Tính thống nhất cũng rất quan trọng. Nó làm giảm tải nhận thức khi đọc mã, đặc biệt nếu kiểu mã như bạn mong đợi. Nhưng ngay cả khi đối phó với một phong cách mã hóa nước ngoài, nếu nó phù hợp thì nó sẽ không mất nhiều thời gian để trở thành quen với nó. Sử dụng các công cụ như ReSharper và StyleCop để đảm bảo tính nhất quán mà bạn cho rằng nó quan trọng.

Sử dụng .NET Reflector cho thấy rằng Microsoft không phải là tuyệt vời khi tuân thủ các tiêu chuẩn mã hóa StyleCop trong BCL.

Answer 7

Tôi theo dõi chủ yếu là vì intellisense lý do. Thật thú vị khi gõ this. và nhận danh sách consise về tài sản, phương pháp, v.v.

Answer 8

Một vài lý do cơ bản để sử dụng this (và tôi tình cờ luôn tiền tố giá trị lớp với tên của lớp mà chúng là một phần tốt - ngay cả trong chính lớp).

1) Độ rõ ràng. Bạn biết ngay lập tức mà các biến mà bạn đã khai báo trong định nghĩa lớp và bạn đã khai báo là người dân địa phương, các tham số và không có gì. Trong hai năm, bạn sẽ không biết điều đó và bạn sẽ đi trên một chuyến đi kỳ diệu của khám phá lại đó là hoàn toàn vô nghĩa và không cần thiết nếu bạn đặc biệt nhà nước phụ huynh lên phía trước. Một người nào khác làm việc trên mã của bạn không có ý tưởng từ việc đi và do đó lợi ích ngay lập tức.

2) Intellisense. Nếu bạn gõ 'this.' bạn nhận được tất cả các thành viên và thuộc tính cụ thể trong trợ giúp. Nó giúp việc tìm kiếm mọi thứ trở nên dễ dàng hơn nhiều, đặc biệt nếu bạn đang duy trì mã hoặc mã của người khác mà bạn chưa xem xét trong một vài năm. Nó cũng giúp bạn tránh các lỗi gây ra bởi quan niệm sai lầm về những biến và phương thức nào được khai báo ở đâu và như thế nào. Nó có thể giúp bạn khám phá các lỗi mà nếu không sẽ không hiển thị cho đến khi trình biên dịch bị nghẹn trên mã của bạn.

3) Cấp cho bạn có thể đạt được hiệu quả tương tự bằng cách sử dụng tiền tố và các kỹ thuật khác, nhưng điều này đặt ra câu hỏi lý do tại sao bạn sẽ phát minh ra một cơ chế để xử lý sự cố khi có cơ chế làm như vậy thực sự được hỗ trợ bởi IDE? Nếu bạn chạm vào loại, thậm chí một phần, nó cuối cùng sẽ giảm tỷ lệ lỗi của bạn, quá, bởi không buộc bạn phải đưa ngón tay của bạn ra khỏi vị trí nhà để có được chìa khóa gạch dưới.

Tôi thấy rất nhiều lập trình viên trẻ, những người thực hiện một thỏa thuận lớn trong thời gian họ sẽ tiết kiệm bằng cách không gõ một hoặc hai ký tự. Hầu hết thời gian của bạn sẽ được chi tiêu gỡ lỗi, không phải mã hóa. Đừng lo lắng quá nhiều về tốc độ nhập của bạn. Lo lắng nhiều hơn về việc bạn có thể nhanh chóng như thế nào hiểu được những gì đang xảy ra trong mã. Nếu bạn tiết kiệm tổng cộng 5 phút mã hóa và giành chiến thắng chi tiêu thêm mười phút gỡ lỗi, bạn đã làm chậm bản thân, bất kể bạn nhanh đến mức nào xem như bạn đang đi.

Answer 9

this.This 
this.Does 
this.Not 
this.Add 
this.Clarity 
this.Nor 
this.Does 
this.This 
this.Add 
this.Maintainability 
this.To 
this.Code 

Việc sử dụng "này.", Khi sử dụng quá mức hoặc một yêu cầu phong cách cưỡng bức, không gì khác sau đó một bày ra sử dụng dưới vỏ bọc rằng có < 1% các nhà phát triển rằng thực sự không hiểu mã hoặc những gì họ đang làm, và làm cho nó đau đớn cho 99% người muốn viết mã dễ đọc và dễ bảo trì.

Ngay khi bạn bắt đầu nhập, Intellisence sẽ liệt kê nội dung có sẵn trong phạm vi bạn đang nhập "này". không cần thiết để vạch trần các thành viên của lớp và trừ khi bạn hoàn toàn không biết gì về những gì bạn đang viết mã cho bạn sẽ có thể dễ dàng tìm thấy mục bạn cần.

Thậm chí nếu bạn hoàn toàn không biết gì, hãy sử dụng "cái này". để gợi ý những gì có sẵn, nhưng không để nó trong mã. Ngoài ra còn có một loạt các tiện ích như Resharper giúp mang lại sự rõ ràng cho phạm vi và hiển thị nội dung của các đối tượng hiệu quả hơn. Tốt hơn là học cách sử dụng các công cụ được cung cấp cho bạn sau đó để phát triển một thói quen xấu bị ghét bởi một số lượng lớn các đồng nghiệp của bạn.

Bất kỳ nhà phát triển nào vốn không hiểu phạm vi nội dung tĩnh, cục bộ, lớp hoặc toàn cục không nên dựa vào "gợi ý" để chỉ ra phạm vi. "điều này." là tồi tệ hơn sau đó ký hiệu Hungary như ít nhất là ký hiệu Hungary cung cấp một ý tưởng về loại biến được tham chiếu và phục vụ một số lợi ích. Tôi thà nhìn thấy "_" hoặc "m" được sử dụng để biểu thị các thành viên lớp học sau đó để xem "này". mọi nơi.

Tôi chưa bao giờ gặp sự cố và cũng không gặp sự cố với nhà phát triển đồng loạt liên tục chiến đấu với phạm vi mã hoặc viết mã luôn lỗi vì không sử dụng "điều này". một cách rõ ràng. Đó là một nỗi sợ hãi không chính đáng rằng "điều này". ngăn chặn các lỗi mã trong tương lai và thường là đối số được sử dụng khi không có giá trị.

Các trình phát triển có kinh nghiệm, "điều này". cũng giống như yêu cầu ai đó đặt bánh xe đào tạo lên xe đạp của họ như một người lớn vì đó là những gì họ đầu tiên phải sử dụng để học cách đi xe đạp. Và người lớn có thể rơi khỏi một chiếc xe đạp 1 trong 1000 lần họ nhận được trên nó, nhưng đó là không có lý do để buộc họ phải sử dụng bánh xe đào tạo.

"này". nên bị cấm từ định nghĩa ngôn ngữ cho C#, tiếc là chỉ có một lý do để sử dụng nó, và đó là để giải quyết sự mơ hồ, mà cũng có thể dễ dàng được giải quyết thông qua thực hành mã tốt hơn.