2009-11-09 22 views
6

Một trong các kiểm tra Checkstyle tích hợp là RequireThis, sẽ tắt bất cứ khi nào bạn không thêm this. vào trường địa phương hoặc lời gọi phương thức. Ví dụ:Nếu yêu cầu kiểm tra này trong Checkstyle được kích hoạt?

public final class ExampleClass { 
    public String getMeSomething() { 
     return "Something"; 
    } 

    public String getMeSomethingElse() { 
     //will violate Checkstyle; should be this.getMeSomething() 
     return getMeSomething() + " else"; 
    } 
} 

Tôi đang vật lộn với việc kiểm tra này có được biện minh hay không. Trong ví dụ trên, số ExampleClass là số cuối cùng, cần bảo đảm rằng phiên bản "phải" của getMeSomething sẽ được gọi. Ngoài ra, có vẻ như là trường hợp bạn có thể muốn các lớp con ghi đè hành vi mặc định, trong trường hợp này yêu cầu "này" là hành vi sai.

Cuối cùng, có vẻ như hành vi mã hóa quá phòng thủ chỉ làm lộn xộn nguồn và làm cho việc xem thực sự là gì đang diễn ra trở nên khó khăn hơn.

Vì vậy, trước khi tôi đề nghị kiến ​​trúc sư của tôi rằng đây là một kiểm tra xấu để kích hoạt, tôi tự hỏi nếu bất cứ ai khác đã kích hoạt kiểm tra này? Bạn có gặp phải lỗi nghiêm trọng do thiếu this không?

+0

Câu hỏi liên quan cho C#: http://stackoverflow.com/questions/1562540/why-does-stylecop-recommend-prefixing-method-or-property-calls-with-this –

Trả lời

4

Quy tắc RequireThis không có giá trị sử dụng ở chỗ nó có thể ngăn chặn lỗi có thể xảy ra khi phương pháp và nhà thầu áp dụng cho trường. Mã bên dưới gần như chắc chắn là một lỗi:

void setSomething(String something) { 
    something = something; 
} 

Mã như thế này sẽ biên dịch nhưng sẽ không làm gì ngoại trừ gán lại giá trị của tham số phương pháp cho chính nó. Nó có nhiều khả năng rằng tác giả có ý định làm điều này:

void setSomething(String something) { 
    this.something = something; 
} 

Đây là một lỗi đánh máy có thể xảy ra và có giá trị kiểm tra vì nó có thể giúp ngăn ngừa khó để gỡ lỗi nếu mã không thành công vì this.something không được thiết lập sau này trong chương trình.

Các thiết lập checkstyle cho phép bạn để giữ cho việc kiểm tra này hữu ích cho các lĩnh vực trong khi bỏ qua việc kiểm tra chủ yếu là không cần thiết cho các phương pháp bằng cách cấu hình quy tắc như vậy:

<module name="RequireThis"> 
     <property name="checkMethods" value="false"/> 
    </module> 

Khi nói đến phương pháp quy tắc này không có tác dụng thực vì gọi số this.getMeSomething() hoặc chỉ getMeSomething() không ảnh hưởng đến độ phân giải phương thức của Java. Gọi số this.getSomethingStatic() vẫn hoạt động khi phương thức tĩnh không phải là lỗi, nó chỉ là cảnh báo trong các IDE và công cụ phân tích tĩnh khác nhau.

+0

Không nên mã như "something = something" bị bắt bởi quy tắc khác? Tôi không biết tất cả các quy tắc, nhưng tôi khá chắc chắn rằng có một quy tắc "chuyển nhượng không có hiệu lực". –

+1

Bạn đang có một quy tắc http://checkstyle.sourceforge.net/config_coding.html#ParameterAssignment sẽ bắt được quy tắc này thậm chí ít hữu ích hơn! –

+0

Dường như việc sử dụng kiểm tra ParameterAssignment sẽ bắt gặp bất kỳ vấn đề nào ngăn chặn RequireThis sẽ che dấu. Với sức mạnh của chúng tôi kết hợp ... – matthewsteele

3

Gọi bằng "này". không dừng lời gọi bằng cách gọi một phương thức ghi đè trong một lớp con, vì điều này đề cập đến "đối tượng này" không phải là "lớp này". Nó sẽ ngăn cản bạn nhầm một phương pháp tĩnh cho một phương thức mặc dù.

Thành thật mà nói, điều đó không giống như một vấn đề đặc biệt phổ biến, cá nhân tôi sẽ không nghĩ rằng nó đáng để đánh đổi.

+1

Rất tiếc. ... quên một phần của câu hỏi ngụ ý rằng họ không cư xử giống nhau ... tất nhiên đó là một phần quan trọng để làm rõ. –

3

Cá nhân tôi sẽ không bật tính năng này. Chủ yếu là bởi vì bất cứ khi nào tôi đọc mã tôi đọc nó trong một IDE (hoặc cái gì khác mà không thông minh định dạng mã). Điều này có nghĩa rằng các loại khác nhau của các cuộc gọi phương thức và truy cập trường được định dạng dựa trên ý nghĩa ngữ nghĩa thực tế của chúng và không dựa trên một số dấu hiệu (có thể sai).

this. không cần thiết cho trình biên dịch và khi IDE có định dạng thông minh thì không cần thiết cho người dùng. Và viết mã không cần thiết chỉ là một nguồn lỗi trong mã này (trong ví dụ này: sử dụng this. ở một số nơi và không sử dụng nó ở những nơi khác).

3

Tôi chắc chắn sẽ tắt nó đi. Sử dụng this.foo() là Java không phải là thành ngữ và do đó chỉ nên được sử dụng khi cần thiết, để báo hiệu rằng có điều gì đó đặc biệt đang diễn ra trong mã. Ví dụ: trong một setter:

 
void setFoo(int foo) {this.foo = foo;} 

Khi tôi đọc mã sử dụng vô cớ, tôi thường đánh dấu nó lên lập trình viên mà không nắm vững lập trình hướng đối tượng. Phần lớn là vì tôi thường thấy rằng kiểu mã từ các lập trình viên không hiểu rằng này không phải là yêu cầu ở mọi nơi.

Tôi thực sự ngạc nhiên khi thấy điều này như một quy tắc trong thư viện của CheckStyle.

1

Tôi chỉ bật kiểm tra này cho các trường, vì tôi thích thông tin bổ sung được thêm bởi 'this.' ở phía trước một trường.
Xem câu hỏi (cũ) của tôi: Do you prefix your instance variable with ‘this’ in java ?.

Nhưng đối với bất kỳ dự án khác, đặc biệt là những di sản, tôi sẽ không kích hoạt nó:

  • rất có thể là, từ khóa 'this.' gần như bao giờ sử dụng, có nghĩa là việc kiểm tra này sẽ tạo ra tấn cảnh báo.
  • ghi đè đặt tên (như trường và phương thức có tên tương tự) rất hiếm do IDE hiện tại gắn cờ theo mặc định là mã có cảnh báo riêng.
Các vấn đề liên quan