Đây là một ví dụ rất đơn giản . Đây không nhất thiết là một câu hỏi dành riêng cho ngôn ngữ và tôi yêu cầu bạn bỏ qua nhiều cách khác để chức năng có thể được viết và những thay đổi có thể được thực hiện đối với nó. . Màu sắc là một loại duy nhất
string CanLeaveWithoutUmbrella()
{
if(sky.Color.Equals(Color.Blue))
{
return "Yes you can";
}
else
{
return "No you can't";
}
}
Rất nhiều người tôi đã gặp, ReSharper và anh chàng này (có bình luận nhắc nhở tôi rằng tôi đã tìm cách hỏi điều này một thời gian) sẽ khuyên bạn nên cấu trúc lại mã để loại bỏ elsekhối này:
(Tôi không thể nhớ lại những gì đa số đã nói, tôi có thể không hỏi điều này nếu không)
string CanLeaveWithoutUmbrella()
{
if(sky.Color.Equals(Color.Blue))
{
return "Yes you can";
}
return "No you can't";
}
Câu hỏi: Có sự gia tăng độ phức tạp được giới thiệu bằng cách không bao gồm elsekhối?
Tôi có ấn tượng về elseý định trực tiếp hơn, bằng cách nêu thực tế rằng mã trong cả hai khối có liên quan trực tiếp.
Ngoài ra, tôi thấy rằng tôi có thể ngăn ngừa các lỗi tinh vi trong logic, đặc biệt là sau khi sửa đổi mã vào một ngày sau đó.
Lấy biến thể này của ví dụ đơn giản hóa của tôi (Bỏ qua thực tế ortoán tử vì đây là ví dụ đơn giản hóa có chủ đích):
bool CanLeaveWithoutUmbrella()
{
if(sky.Color != Color.Blue)
{
return false;
}
return true;
}
Bây giờ ai đó có thể thêm một ifkhối mới dựa trên một điều kiện sau ví dụ đầu tiên mà không nhận ra ngay điều kiện đầu tiên là đặt một ràng buộc cho điều kiện của chính họ.
Nếu một elsekhối có mặt, bất cứ ai thêm điều kiện mới sẽ bị buộc phải di chuyển nội dung của elsekhối (và nếu bằng cách nào đó, chúng che phủ nó, heuristic sẽ hiển thị mã không thể truy cập được, trong trường hợp không ifràng buộc mã này) .
Tất nhiên, có những cách khác mà ví dụ cụ thể nên được xác định bằng mọi cách, tất cả đều ngăn chặn tình huống đó, nhưng đó chỉ là một ví dụ.
Độ dài của ví dụ tôi đưa ra có thể làm lệch khía cạnh trực quan của điều này, vì vậy giả sử rằng không gian được đưa lên dấu ngoặc tương đối không đáng kể so với phần còn lại của phương thức.
Tôi đã quên đề cập đến một trường hợp tôi đồng ý với sự thiếu sót của một khối khác và khi sử dụng một ifkhối để áp dụng một ràng buộc phải được thỏa mãn một cách hợp lý cho tất cả các mã sau, chẳng hạn như kiểm tra null (hoặc bất kỳ bộ bảo vệ nào khác) .
elsemệnh đề (theo sở thích của tôi, nó sẽ còn dễ đọc hơn khi bỏ dấu ngoặc không cần thiết. Nhưng tôi nghĩ ví dụ này không được chọn tốt, vì trong trường hợp trên tôi sẽ viết return sky.Color == Color.Blue(không có if / other). Một ví dụ với kiểu trả về khác với bool có thể sẽ làm cho điều này rõ ràng hơn.
