Quy tắc kiểm tra để ngăn chặn gọi một số phương thức và hàm tạo

Question

Có thể sử dụng Checkstyle để cấm sử dụng một số hàm tạo hoặc phương thức sử dụng mặc định hệ thống (ngôn ngữ, bộ ký tự, v.v.). Tôi thích thực thi một chính sách mà lập trình viên phải rõ ràng về các giá trị phụ thuộc vào hệ thống. Vì vậy, tôi xem xét các mục sau đây là nguy hiểm:

• tất cả các nhà thầu của java.io.FielWriter
  • sử dụng mã hóa hệ thống phụ thuộc vào
• các OutputStreamWriter(OutputStream os) constructor của java.io.OutputStreamWriter
  • sử dụng mã hóa hệ thống phụ thuộc vào
• các java.lang.String.toLowerCase() phương pháp
  • sử dụng mặc định hệ thống locale
• Các java.util.Calendar.getInstance() phương pháp
  • sử dụng locale mặc định hệ thống và múi giờ mặc định

(danh sách đi về, bạn sẽ có được hình ảnh).

Có thể thực thi việc này bằng Checkstyle 5.5 không?

Answer 1

Bạn không thể thực hiện việc này theo mặc định. Tuy nhiên, bạn có thể thực hiện trình kiểm tra của riêng bạn để kiểm tra các phương thức này.

Tùy chọn đầu tiên là sử dụng Miscellaneous-> Regexp. Điều này rõ ràng là chỉ có thể nếu bạn có thể tìm thấy vi phạm với một regexp. Bạn sẽ cần đặt truePattern = true. Đây sẽ là một nơi tốt để bắt đầu, tôi nghĩ vậy.

Tùy chọn thứ hai là tạo séc của riêng bạn. Xem Writing Checks.

Có giới hạn cho việc viết cờ. Điều đầu tiên và quan trọng nhất là bạn không thể thấy các tệp khác. Không có bất kỳ kiểm tra chéo nào. Từ trang web:

1. Bạn không thể xác định loại biểu thức.
2. Bạn không thể xem nội dung của các tệp khác. (mặc dù bạn có thể lưu các tệp đã xử lý để sử dụng sau)

Điều này có nghĩa là bạn không thể thực hiện một số kiểm tra mã các tính năng có sẵn trong các IDE nâng cao như IntelliJ IDEA. Ví dụ: ví dụ, bạn sẽ không thể triển khai Kiểm tra tìm thấy phôi giả loại dư thừa hoặc các phương pháp công khai không được sử dụng.

Vì vậy, bạn không thể kiểm tra ví dụ rằng java đang gọi một phương pháp thay thế bằng ngôn ngữ địa phương. Bạn có thể sử dụng danh sách đen các phương pháp mà bạn không được phép gọi. Vì vậy, ví dụ các cuộc gọi đến FileWriter mới() sẽ kiểm tra số lượng các thông số được thông qua, hoặc như thế.

Answer 2

Tôi nghĩ Bộ xử lý chú thích sẽ phù hợp hơn với tác vụ này. Từ Matthew Farwell's answer "Bạn không thể xác định loại biểu thức."

Giả sử bạn sử dụng lọ bên thứ ba chứa lớp FancyWriter mở rộng FileWriter. Bạn đặt bất hợp pháp một mã số x = new FancyWriter () ; vào mã của mình. CheckStyle sẽ không tìm thấy nó bởi vì nó đang sử dụng các biểu thức thông thường và nó không đủ thông minh để biết rằng FancyWriter là một FileWriter. Tôi nghĩ rằng bạn có thể viết một bộ xử lý chú thích mà con số FancyWriter thực sự là một FileWriter và là bất hợp pháp.

OTH, một người nào đó - về mặt lý thuyết - có thể viết phần mở rộng của một lớp bất hợp pháp để loại bỏ sự phụ thuộc của hệ thống. Ví dụ, giả sử rằng FileWriter có một phương thức mà nó nhận được mã hóa hệ thống. Nếu LegalWriter mở rộng FileWriter và ghi đè lên phương thức thì chúng ta không nên từ chối LegalWriter chỉ b/c nó mở rộng một lớp bất hợp pháp.

Nếu bạn đang sử dụng lọ bên thứ ba, các lớp học của họ sẽ hợp pháp như thế nào. Chỉ vì họ không mở rộng một lớp học bất hợp pháp, không có nghĩa là họ không sử dụng nó. Sau đó, nếu bạn sử dụng một trong các lớp học của họ, mã của bạn là hệ thống phụ thuộc.

Answer 3

Vì Matthew và emory đã nêu, không có giải pháp hoàn hảo nào với kiểu séc. Đây là gợi ý của tôi:

• Đừng cấm chỉ một số nhà thầu, mà cấm tất cả các nhà xây dựng của các lớp bị ảnh hưởng. Sau đó tạo phân lớp của riêng bạn, ẩn các nhà thầu bị cấm. Ví dụ: tạo một mẫu kiểu kiểm tra "FileWriter\(" và một phân lớp SystemIndependentFileWriter chỉ với một số hàm tạo của lớp siêu.
• Tạo mẫu "toLowerCase()" và hy vọng rằng không ai tạo phương thức có cùng tên. Or use FindBugs to catch this one.
• Tạo mẫu kiểu kiểm tra "Calendar.getInstance()". Tôi không thấy vấn đề gì với cái đó.

Hy vọng rằng nó sẽ chỉ ném một vài mặt tích cực sai, có thể được đưa vào danh sách bỏ qua. Cuối cùng, bạn cần phải tinh chỉnh nó để bắt ngắt dòng hoặc các khoảng trắng bị thất lạc khác.