Đúng hay sai, hiện tại tôi tin rằng tôi nên luôn cố gắng làm cho mã của mình mạnh nhất có thể, ngay cả khi điều này có nghĩa là thêm mã / kiểm tra dự phòng mà tôi biết sẽ không được sử dụng ngay bây giờ, nhưng chúng có thể là x số năm xuống dòng.
Ví dụ: tôi hiện đang làm việc trên một ứng dụng di động có đoạn mã này:
public static CalendarRow AssignAppointmentToRow(Appointment app, List<CalendarRow> rows)
{
//1. Is rows equal to null? - This will be the case if this is the first appointment.
if (rows == null) {
rows = new List<CalendarRow> ();
}
//2. Is rows empty? - This will be the case if this is the first appointment / some other unknown reason.
if(rows.Count == 0)
{
rows.Add (new CalendarRow (0));
rows [0].Appointments.Add (app);
}
//blah...
}
Nhìn cụ thể vào phần hai, tôi biết rằng nếu phần một là đúng, thì phần hai cũng sẽ đúng. Tôi không thể nghĩ ra bất kỳ lý do nào là tại sao phần một sẽ sai và phần hai đánh giá đúng, điều này làm cho iftuyên bố thứ hai trở nên dư thừa.
Tuy nhiên, có thể có một trường hợp trong tương lai nơi iftuyên bố thứ hai này thực sự cần thiết, và vì một lý do đã biết.
Một số người có thể nhìn vào điều này ban đầu và nghĩ rằng tôi đang lập trình với suy nghĩ trong tương lai, đó rõ ràng là một điều tốt. Nhưng tôi biết một vài trường hợp loại mã này có lỗi "ẩn" đối với tôi. Có nghĩa là nó khiến tôi mất nhiều thời gian hơn để tìm hiểu tại sao chức năng lại hoạt xyzđộng abckhi nó thực sự nên làm def.
Mặt khác, cũng có nhiều trường hợp loại mã này đã giúp việc cải thiện mã với các hành vi mới dễ dàng hơn nhiều, vì tôi không phải quay lại và đảm bảo rằng tất cả các kiểm tra có liên quan đều được thực hiện.
Có bất kỳ hướng dẫn quy tắc chung nào cho loại mã này không? (Tôi cũng muốn biết liệu điều này sẽ được coi là thực hành tốt hay xấu?)
Lưu ý: Điều này có thể được coi là tương tự với câu hỏi này, tuy nhiên không giống như câu hỏi đó, tôi muốn có một câu trả lời giả sử không có thời hạn.
TLDR: Tôi có nên đi xa hơn để thêm mã dự phòng để làm cho nó có tiềm năng mạnh mẽ hơn trong tương lai không?
if(rows.Count == 0)sẽ không bao giờ xảy ra, thì bạn có thể đưa ra một ngoại lệ khi nó xảy ra - và kiểm tra xem tại sao giả định của bạn trở nên sai.
rowslà null? Không bao giờ có một lý do chính đáng, ít nhất là trong .NET, cho một bộ sưu tập là null. Trống rỗng , chắc chắn, nhưng không null . Tôi sẽ ném một ngoại lệ nếu rowslà null, bởi vì nó có nghĩa là có một lỗi trong logic của người gọi.