Các lập trình viên có nên sử dụng các biến boolean để “ghi lại” mã của họ không?

Tôi đang đọc Code Complete của McConell và anh ấy thảo luận về việc sử dụng các biến boolean để ghi lại mã của bạn. Ví dụ, thay vì:

if((elementIndex < 0) || (MAX_ELEMENTS < elementIndex) || 
   (elementIndex == lastElementIndex)){
       ...
}

Anh ấy đề nghị:

finished = ((elementIndex < 0) || (MAX_ELEMENTS < elementIndex));
repeatedEntry = (elementIndex == lastElementIndex);
if(finished || repeatedEntry){
   ...
}

Điều này đánh giá tôi là hợp lý, thực hành tốt và rất tự ghi lại. Tuy nhiên, tôi do dự khi bắt đầu sử dụng kỹ thuật này thường xuyên vì tôi hầu như chưa bao giờ gặp nó; và có lẽ nó sẽ gây nhầm lẫn chỉ vì hiếm có. Tuy nhiên, kinh nghiệm của tôi chưa nhiều lắm, vì vậy tôi muốn nghe ý kiến ​​của các lập trình viên về kỹ thuật này và tôi muốn biết liệu có ai sử dụng kỹ thuật này thường xuyên hoặc đã nhìn thấy nó thường xuyên khi đọc mã không. Đây có phải là một quy ước / phong cách / kỹ thuật đáng giá để áp dụng không? Các lập trình viên khác sẽ hiểu và đánh giá cao nó, hay coi nó là lạ?

Tách một biểu thức quá lồng nhau và phức tạp thành các biểu thức con đơn giản hơn được gán cho các biến cục bộ, sau đó ghép lại với nhau, là một kỹ thuật khá phổ biến và phổ biến - hoàn toàn độc lập với việc liệu các biểu thức con và / hoặc biểu thức tổng thể là boolean hay of chỉ về bất kỳ loại nào khác. Với những cái tên được lựa chọn kỹ càng, kiểu phân tách trang nhã kiểu này có thể tăng khả năng đọc và một trình biên dịch tốt sẽ không gặp khó khăn khi tạo mã tương đương với biểu thức ban đầu, phức tạp.

Một số ngôn ngữ không có khái niệm "gán" cho mỗi ngôn ngữ, chẳng hạn như Haskell, thậm chí còn giới thiệu các cấu trúc chuyên biệt để cho phép bạn sử dụng kỹ thuật "đặt tên cho biểu thức con" ( wheremệnh đề trong Haskell) - dường như nói riêng một số phổ biến cho kỹ thuật được đề cập! -)

Tôi đã sử dụng nó, mặc dù thường gói logic boolean thành một phương thức có thể tái sử dụng (nếu được gọi từ nhiều vị trí).

Nó giúp dễ đọc và khi logic thay đổi, nó chỉ cần thay đổi ở một chỗ.

Những người khác sẽ hiểu nó và sẽ không thấy lạ (trừ những người chỉ viết hàm nghìn dòng, nghĩa là).

Tôi cố gắng làm điều đó bất cứ khi nào có thể. Chắc chắn, bạn đang sử dụng một "dòng bổ sung" của mã, nhưng đồng thời, bạn đang mô tả lý do tại sao bạn thực hiện so sánh hai giá trị.

Trong ví dụ của bạn, tôi nhìn vào mã và tự hỏi bản thân "được rồi tại sao người nhìn thấy giá trị nhỏ hơn 0?" Trong phần thứ hai, bạn đang nói rõ với tôi rằng một số quy trình đã kết thúc khi điều này xảy ra. Không đoán trong phần thứ hai ý định của bạn là gì.

Điều quan trọng đối với tôi là khi tôi thấy một phương thức như: DoSomeMethod(true); Tại sao nó tự động được đặt thành true? Nó dễ đọc hơn như

bool deleteOnCompletion = true;

DoSomeMethod(deleteOnCompletion);

Mẫu được cung cấp:

finished = ((elementIndex < 0) || (MAX_ELEMENTS < elementIndex));
repeatedEntry = (elementIndex == lastElementIndex);
if(finished || repeatedEntry){
   ...
}

Cũng có thể được viết lại để sử dụng các phương pháp, giúp cải thiện khả năng đọc và bảo toàn logic boolean (như Konrad đã chỉ ra):

if (IsFinished(elementIndex) || IsRepeatedEntry(elementIndex, lastElementIndex)){
   ...
}

...

private bool IsFinished(int elementIndex) {
    return ((elementIndex < 0) || (MAX_ELEMENTS < elementIndex));
}

private bool IsRepeatedEntry(int elementIndex, int lastElementIndex) {
    return (elementIndex == lastElementIndex);
}

Tất nhiên, nó đi kèm với một mức giá, đó là hai phương pháp phụ. Nếu bạn làm điều này nhiều, nó có thể làm cho mã của bạn dễ đọc hơn, nhưng các lớp của bạn kém minh bạch hơn. Nhưng một lần nữa, bạn cũng có thể chuyển các phương thức bổ sung vào các lớp trợ giúp.

Cách duy nhất tôi có thể thấy điều này đang xảy ra sai là nếu đoạn boolean không có một cái tên có ý nghĩa và một cái tên được chọn theo cách nào đó.

//No clue what the parts might mean.
if(price>0 && (customer.IsAlive || IsDay(Thursday)))

=>

first_condition = price>0
second_condition =customer.IsAlive || IsDay(Thursday)

//I'm still not enlightened.
if(first_condition && second_condition)

Tôi chỉ ra điều này vì việc đưa ra các quy tắc như "nhận xét tất cả mã của bạn", "sử dụng boolean được đặt tên cho tất cả các tiêu chí if có nhiều hơn 3 phần" là điều phổ biến chỉ để nhận các nhận xét trống về mặt ngữ nghĩa của loại sau

i++; //increment i by adding 1 to i's previous value

Bằng cách làm điều này

finished = ((elementIndex < 0) || (MAX_ELEMENTS < elementIndex));
repeatedEntry = (elementIndex == lastElementIndex);
if(finished || repeatedEntry){
   ...
}

bạn loại bỏ logic khỏi bộ não của bạn và đưa nó vào mã. Bây giờ chương trình biết bạn muốn nói gì.
Bất cứ khi nào bạn đặt tên một cái gì đó, bạn cho nó đại diện vật lý . Nó có tồn tại.
Bạn có thể thao tác và sử dụng lại nó.

Bạn thậm chí có thể xác định toàn bộ khối dưới dạng một vị từ:

bool ElementBlahBlah? (elementIndex, lastElementIndex);

và làm nhiều thứ hơn (sau này) trong chức năng đó.

Nếu biểu thức phức tạp thì tôi hoặc di chuyển nó sang một hàm khác trả về một boolví dụ, isAnEveningInThePubAGoodIdea(dayOfWeek, sizeOfWorkLoad, amountOfSpareCash)hoặc xem xét lại mã để biểu thức phức tạp như vậy không cần thiết.

Hãy nhớ rằng theo cách này bạn tính toán nhiều hơn mức cần thiết. Do các điều kiện từ mã, bạn luôn tính toán cả hai (không đoản mạch).

Vậy nên:

if((elementIndex < 0) || (MAX_ELEMENTS < elementIndex) || 
   (elementIndex == lastElementIndex)){
   ...
}

Sau khi biến đổi trở thành:

if((elementIndex < 0) || (MAX_ELEMENTS < elementIndex) |
   (elementIndex == lastElementIndex)){
   ...
}

Không phải là vấn đề trong hầu hết các trường hợp, nhưng trong một số trường hợp, nó có thể có nghĩa là hiệu suất kém hơn hoặc các vấn đề khác, ví dụ: khi trong biểu thức thứ 2, bạn cho rằng biểu thức thứ nhất không thành công.

Tôi nghĩ tốt hơn nên tạo các hàm / phương thức thay vì các biến tạm thời. Bằng cách này, khả năng đọc cũng được tăng lên vì các phương thức ngắn hơn. Cuốn sách Refactoring của Martin Fowler có lời khuyên hữu ích để cải thiện chất lượng mã. Các cấu trúc lại liên quan đến ví dụ cụ thể của bạn được gọi là "Replace Temp with Query" và "Extract Method".

Cá nhân tôi nghĩ rằng đây là một thực hành tuyệt vời. Tác động của nó đối với việc thực thi mã là rất ít, nhưng sự rõ ràng mà nó có thể cung cấp, nếu được sử dụng đúng cách, là vô giá khi nói đến việc duy trì mã sau này.

nếu phương thức yêu cầu thông báo thành công: (ví dụ trong c #) Tôi muốn sử dụng

bool success = false;

Để bắt đầu. mã này không ổn cho đến khi tôi thay đổi nó thành:

success = true;

sau đó ở cuối:

return success;

Tôi nghĩ, nó phụ thuộc vào phong cách bạn / nhóm của bạn thích. Tái cấu trúc "Giới thiệu biến" có thể hữu ích, nhưng đôi khi không :)

Và tôi không đồng ý với Kevin trong bài viết trước của anh ấy. Ví dụ của anh ấy, tôi cho rằng có thể sử dụng được trong trường hợp khi biến được giới thiệu có thể được thay đổi, nhưng việc giới thiệu nó chỉ cho một boolean tĩnh là vô ích, bởi vì chúng ta có tên tham số trong khai báo phương thức, vậy tại sao lại sao chép nó trong mã?

ví dụ:

void DoSomeMethod(boolean needDelete) { ... }

// useful
boolean deleteOnCompletion = true;
if ( someCondition ) {
    deleteOnCompletion = false;
}
DoSomeMethod(deleteOnCompletion);

// useless
boolean shouldNotDelete = false;
DoSomeMethod(shouldNotDelete);

Theo kinh nghiệm của mình, tôi thường quay lại một số kịch bản cũ và tự hỏi 'hồi đó mình đang nghĩ cái quái gì vậy?'. Ví dụ:

Math.p = function Math_p(a) {
    var r = 1, b = [], m = Math;
    a = m.js.copy(arguments);
    while (a.length) {
        b = b.concat(a.shift());
    }
    while (b.length) {
        r *= b.shift();
    }
    return r;
};

không trực quan như:

/**
 * An extension to the Math object that accepts Arrays or Numbers
 * as an argument and returns the product of all numbers.
 * @param(Array) a A Number or an Array of numbers.
 * @return(Number) Returns the product of all numbers.
 */
Math.product = function Math_product(a) {
    var product = 1, numbers = [];
    a = argumentsToArray(arguments);
    while (a.length) {
        numbers = numbers.concat(a.shift());
    }
    while (numbers.length) {
        product *= numbers.shift();
    }
    return product;
};

Tôi hiếm khi tạo các biến riêng biệt. Điều tôi làm khi các bài kiểm tra trở nên phức tạp là lồng các IF và thêm nhận xét. Giống

boolean processElement=false;
if (elementIndex < 0) // Do we have a valid element?
{
  processElement=true;
}
else if (elementIndex==lastElementIndex) // Is it the one we want?
{
  processElement=true;
}
if (processElement)
...

Lỗ hổng được thừa nhận của kỹ thuật này là lập trình viên tiếp theo có thể thay đổi logic nhưng không bận tâm đến việc cập nhật các nhận xét. Tôi đoán đó là một vấn đề chung, nhưng tôi đã rất nhiều lần nhìn thấy một nhận xét có nội dung "xác thực id khách hàng" và dòng tiếp theo là kiểm tra số bộ phận hoặc một số như vậy và tôi còn lại để tự hỏi khách hàng ở đâu id đến.