- Phương thức hoặc hàm gọi mà không làm gì có giá trị.
Không hẳn là xấu. Các phương thức trong một lớp cơ sở thường gọi các phương thức rỗng có nghĩa là các điểm ghi đè cho các lớp con. Ví dụ: UIView của Cốc Cốc có một -didAddSubview:phương pháp được ghi nhận là không làm gì trong phiên bản mặc định. -addSubview:Phương thức của UIView phải gọi -didAddSubview:ngay cả khi nó không làm gì cả vì các lớp con có thể thực hiện nó để làm một cái gì đó. Các phương pháp không làm gì và lý do cho chúng nên được ghi lại, tất nhiên.
Nếu một chức năng / phương thức trống rỗng hoặc vô dụng rõ ràng là có lý do lịch sử, thì nó nên được loại bỏ. Hãy xem các phiên bản trước của mã trong kho lưu trữ mã nguồn của bạn nếu bạn không chắc chắn.
- Kiểm tra dự phòng được thực hiện trong một tệp lớp, đối tượng hoặc phương thức riêng biệt.
Thật khó để nói nếu điều đó ổn mà không có bối cảnh. Nếu việc kiểm tra được thực hiện rõ ràng vì cùng một lý do, điều đó có nghĩa là không có sự phân tách trách nhiệm rõ ràng và một số tái cấu trúc được yêu cầu, đặc biệt là khi cả hai kiểm tra đều dẫn đến cùng một hành động. Nếu hành động do cả hai kiểm tra không giống nhau, thì hai kiểm tra có thể được thực hiện vì những lý do khác nhau ngay cả khi điều kiện giống nhau và điều đó có thể ổn.
- nếu báo cáo luôn luôn đánh giá là đúng.
Có một sự khác biệt lớn giữa:
if (1) {
// ...
}
và:
if (foo() == true) {
// ...
}
nơi foo()luôn xảy ra để trở về true.
Trường hợp đầu tiên xảy ra rất nhiều khi mọi người đang gỡ lỗi. Thật dễ dàng để sử dụng một if (0) {...để tạm thời loại bỏ một đoạn mã trong khi bạn đang cố gắng để cô lập một lỗi, và sau đó thay đổi 0để 1khôi phục lại mã đó. Tất nhiên, ifnên xóa đi một khi bạn đã hoàn thành, nhưng thật dễ dàng để quên bước đó hoặc bỏ lỡ một hoặc hai nếu bạn đã thực hiện ở một vài nơi. (Đó là một ý tưởng tốt để xác định các điều kiện như vậy với một nhận xét mà sau này bạn có thể tìm kiếm.) Tác hại duy nhất là sự nhầm lẫn mà nó có thể gây ra trong tương lai; nếu trình biên dịch có thể xác định giá trị của điều kiện tại thời điểm biên dịch, nó sẽ loại bỏ hoàn toàn.
Trường hợp thứ hai có thể được chấp nhận. Nếu điều kiện được biểu thị bằng foo()cần phải được kiểm tra từ một số vị trí trong mã, thì việc đưa nó vào một hàm hoặc phương thức riêng biệt thường là điều nên làm ngay cả khi foo()luôn luôn đúng. Nếu nó có thể hiểu được foo()cuối cùng có thể quay trở lại false, thì cách ly điều kiện đó trong một phương thức hoặc hàm là một cách để xác định tất cả các vị trí mà mã dựa vào điều kiện đó. Tuy nhiên , làm điều đó sẽ tạo ra một số rủi ro rằng foo() == falsetình trạng này sẽ không được kiểm chứng và có thể dẫn đến các vấn đề sau này; giải pháp là đảm bảo rằng bạn thêm các bài kiểm tra đơn vị kiểm tra rõ ràng falsetrường hợp.
- Chủ đề mà quay đi và không có gì đáng chú ý.
Điều này nghe có vẻ như là một tạo tác của lịch sử và một cái gì đó có thể được xác định hoặc trong quá trình xem xét mã hoặc thông qua hồ sơ định kỳ của phần mềm. Tôi cho rằng nó có thể được tạo ra một cách có chủ ý, nhưng tôi có một thời gian khó tưởng tượng rằng ai đó thực sự sẽ làm điều đó trên mục đích.
if (false) {...}khối là tuyệt vời để bình luận ra mã! </ mỉa mai>