Tại sao (vị trí <kích thước) như vậy là một mô hình phổ biến trong các điều kiện?

Trong một tuyên bố điều kiện (IF) mọi người sử dụng (position < size), nhưng tại sao?
Chỉ quy ước hoặc có một lý do tốt cho điều đó?

Tìm thấy trong tự nhiên:

if (pos < array.length) {
   // do some with array[pos];
}

Hiếm khi tìm thấy:

if (array.length > pos) {
   // do some with array[pos];
}

Mô hình sâu hơn là chúng ta tự nhiên sử dụng "[điều thay đổi] [so sánh] [điều không thay đổi]" làm thứ tự tiêu chuẩn. Nguyên tắc này đúng với ví dụ của bạn vì vị trí có thể thay đổi, trong khi kích thước thì không.

Ngoại lệ phổ biến duy nhất là khi kiểm tra sự bình đẳng, một số lập trình viên tự rèn luyện cách sử dụng thứ tự ngược lại (được gọi là điều kiện Yoda ) để tránh lỗi chung variable = constantthay vì variable == constantlỗi - Tôi không giữ ý tưởng này vì tôi thấy thứ tự tự nhiên được mô tả ở trên dễ đọc hơn nhiều, chủ yếu là vì đó là cách chúng tôi thể hiện ý tưởng bằng tiếng Anh và bởi vì hầu hết các trình biên dịch hiện đại sẽ phát hiện ra điều này và đưa ra cảnh báo.

Lời biện minh duy nhất tôi từng thấy cho nó là nó giống như các dòng số hoặc những thứ tự khác mà chúng ta đã học ở trường. Ví dụ: chúng tôi viết các dòng số như thế này:

<--|--|--|--|--|--|-->
   1  2  3  4  5  6

Những thứ nhỏ hơn xuất hiện bên trái của những thứ lớn hơn. Điều tương tự cũng áp dụng cho những thứ khác như ngày tháng (nghĩ về cách sắp xếp lịch).

Về cơ bản, nó tập trung vào cách chúng ta tự nhiên nghĩ về thứ tự của mọi thứ. Việc đọc mẫu đầu tiên sẽ dễ dàng hơn vì bạn không phải xử lý nhiều về nó.

Mặc dù chủ yếu là vấn đề quy ước, nhưng theo ý kiến ​​của tôi thì điều này phù hợp nhất với cách chúng ta nghĩ - nó cho thấy mục mà chúng ta nhấn mạnh.

Nếu chúng tôi dịch chúng sang tiếng Anh, đó sẽ là cụm từ "Nếu vị trí nhỏ hơn độ dài mảng", trong đó chủ đề của câu là mục tạm thời.

Để diễn đạt nó theo cách khác, "nếu độ dài mảng lớn hơn vị trí" sẽ đặt độ dài mảng (được coi là giá trị cố định) trong đối tượng và vị trí (thoáng qua) trở thành đối tượng trực tiếp.

Ý kiến ​​của tôi, và đây chỉ là ý kiến ​​của tôi, đó là một quy ước cho khả năng đọc. Mặc dù hai người giống hệt nhau, họ cảm thấy khác nhau trong não của tôi. Tôi không muốn biết nếu kích thước mảng lớn hơn pos. Tôi muốn biết nếu pos nhỏ hơn kích thước mảng.

Nó giống như một cuộc thảo luận nửa trống so với nửa đầy đủ. Về mặt toán học giống hệt nhau, nhưng bộ não của tôi sẽ thấy chúng khác nhau tùy thuộc vào ngữ cảnh.

Cá nhân, nếu tôi thấy

if (array.lengh > pos) {
    // do some with array[pos];
}

Tôi sẽ bắt đầu suy nghĩ về việc đó có phải là một lỗi hay không và ý nghĩa của lập trình viên. Có phải anh ta đang cố gắng làm một cái gì đó ngoài kiểm tra giới hạn?

Có lẽ tôi chỉ không sáng sủa, nhưng nếu tôi phải thực hiện loại phân tích đó trên mỗi dòng mã, não tôi sẽ bị tổn thương.

Để thể hiện những gì một số người đã cố gắng đạt được, theo một cách khác ...

Khi thứ tự không tạo ra sự khác biệt đối với hành vi của chương trình, sự khác biệt rõ ràng là vấn đề dễ đọc nhất đối với con người. Đây là một lý do ngôn ngữ tại sao đặt "chủ đề" bên trái có ý nghĩa:

Trong ngôn ngữ học, chủ đề của một câu là những gì đang được nói đến, và bình luận là những gì đang được nói về chủ đề này. Trong ví dụ này, chúng ta có thể cho rằng đó positionlà chủ đề và "nhỏ hơn độ dài mảng" là nhận xét . Trong tiếng Anh, và trong nhiều ngôn ngữ khác, chủ đề thường được thể hiện trước khi bình luận.
" Xu hướng đặt các thành phần cấu thành chủ đề câu-ban đầu (chủ đề chính) là phổ biến. "

Vì vậy, một nguyên tắc nhỏ là nghĩ về dòng mã của bạn như một câu (hoặc mệnh đề, trong trường hợp này), quyết định câu đó nói về điều gì , và đặt nó trước nếu bạn có thể. Thông thường, những gì câu "về" sẽ là một biến chứ không phải là một hằng. Nhưng đôi khi bình luận cũng sẽ liên quan đến một biến, vì vậy bạn không thể đi theo đó.

Đó là sự kết hợp của hai thứ, cả hai đều đến từ trình biên dịch cơ bản mà các ngôn ngữ ban đầu đã được biên dịch thành (và rất nhiều ngôn ngữ hiện tại).

1. Mảng là các độ lệch dựa trên zero trong bộ nhớ (tức là đoạn dữ liệu đầu tiên nằm ở đầu khối bộ nhớ được phân bổ ... chỉ số 0). Do đó, việc sử dụng 0..n-1 cho các mảnh khác nhau.

2. Phân nhánh nếu một giá trị nhỏ hơn một giá trị khác (hoặc đăng ký, v.v.) thường là một lệnh đơn. Do đó việc sử dụng toán tử ít hơn (<) đơn giản.

Vì vậy, mẫu đã chuyển từ trình biên dịch chương trình cũ thành ANSI-C (giống như trình biên dịch macro theo một số cách) và từ đó sang Java và các ngôn ngữ giống C khác.

Như nhiều câu trả lời khác đã nói, nó rất dễ đọc hơn:

[thing that varies] [comparison] [thing that does not vary]

Hầu như tất cả mọi người tôi biết sử dụng phong cách này độc quyền.

Có một ngoại lệ, đối với các ngôn ngữ kiểu C sử dụng =để gán và ==so sánh. Nếu bạn vô tình gõ:

if (variable = 5) ...

thay vì:

if (variable == 5) ...

sau đó bạn sẽ không gặp lỗi vì đây là dòng mã hợp lệ. (Một số trình biên dịch và IDE sẽ cảnh báo bạn về việc này, nhưng vẫn rất dễ để có một lỗi đánh máy đơn giản như vậy.)

Tuy nhiên, nếu bạn viết:

if (5 == variable) ...

trình biên dịch / trình thông dịch sẽ báo lỗi vì đó không phải là cấu trúc hợp lệ (dù sao trong hầu hết các ngôn ngữ).

Chuyển đổi này thường được gọi là Điều kiện Yoda .

CẬP NHẬT : Dưới đây là danh sách các địa điểm mà Điều kiện Yoda hữu ích .

Cá nhân, tôi thích điều này:

bool positionIsWithinBounds = pos < array.length;
if (positionIsWithinBounds) {
   // do some with array[pos];
}

... đó là nhiều mã hơn, nhưng cũng rất dễ đọc.

Đó là vấn đề ưu tiên hoặc quy ước. Nếu bạn muốn nhất quán, có hai cách hợp lý như nhau mà bạn có thể thực hiện:

1. Luôn đặt "chủ đề" lên hàng đầu (nghĩ về nó như một câu) - giá trị mà bài kiểm tra nói về. Vì vậy, ví dụ bạn viếtif (age>5)

2. Hoặc luôn đặt phần tử nhỏ hơn trước (nghĩ về nó như các giá trị được sắp xếp trên màn hình của bạn theo thứ tự tự nhiên). Vì vậy, ví dụ bạn sẽ viết if (a<b)bất kể mã này chủ yếu là về a hay chủ yếu là về b.

Cả hai quy ước sẽ đề xuất đoạn trích đầu tiên bạn hiển thị thay vì đoạn thứ hai, vì vậy tôi đoán trong trường hợp cụ thể này, bạn có câu trả lời của mình. Tôi nói rằng thật khôn ngoan khi tránh viết mã vi phạm cả (1) và (2) ở đây, vì nó sẽ khiến cho hầu hết mọi người khó đọc hơn.