Các biến số có nên sống trong phạm vi nhỏ nhất có thể có bao gồm các trường hợp các biến số không nên tồn tại nếu các biến có thể có không?

Theo câu trả lời được chấp nhận về "Cơ sở lý luận để thích các biến cục bộ hơn các biến thể hiện? ", Các biến nên sống trong phạm vi nhỏ nhất có thể.
Đơn giản hóa vấn đề theo cách hiểu của tôi, điều đó có nghĩa là chúng ta nên cấu trúc lại loại mã này:

public class Main {
    private A a;
    private B b;

    public ABResult getResult() {
        getA();
        getB();
        return ABFactory.mix(a, b);
    }

    private getA() {
      a = SomeFactory.getA();
    }

    private getB() {
      b = SomeFactory.getB();
    }
}

vào một cái gì đó như thế này:

public class Main {
    public ABResult getResult() {
        A a = getA();
        B b = getB();
        return ABFactory.mix(a, b);
    }

    private getA() {
      return SomeFactory.getA();
    }

    private getB() {
      return SomeFactory.getB();
    }
}

nhưng theo "tinh thần" của "các biến nên sống trong phạm vi nhỏ nhất có thể", "không bao giờ có biến" có phạm vi nhỏ hơn "có biến" không? Vì vậy, tôi nghĩ rằng phiên bản trên nên được cấu trúc lại:

public class Main {
    public ABResult getResult() {
        return ABFactory.mix(getA(), getB());
    }

    private getA() {
      return SomeFactory.getA();
    }

    private getB() {
      return SomeFactory.getB();
    }
}

do đó getResult()không có bất kỳ biến cục bộ nào cả. Điều đó có đúng không?

Không. Có một số lý do tại sao:

1. Các biến có tên có ý nghĩa có thể làm cho mã dễ hiểu hơn.
2. Việc chia các công thức phức tạp thành các bước nhỏ hơn có thể giúp mã dễ đọc hơn.
3. Bộ nhớ đệm.
4. Giữ các tham chiếu đến các đối tượng để chúng có thể được sử dụng nhiều lần.

Và như vậy.

Đồng ý, nên tránh các biến không cần thiết và không cải thiện khả năng đọc của mã. Càng nhiều biến trong phạm vi tại một điểm nhất định trong mã, mã đó càng phức tạp để hiểu.

Tôi thực sự không thấy lợi ích của các biến avà btrong ví dụ của bạn, vì vậy tôi sẽ viết phiên bản không có biến. Mặt khác, chức năng rất đơn giản ở nơi đầu tiên tôi không nghĩ nó quan trọng lắm.

Nó trở thành một vấn đề nhiều hơn khi hàm nhận được càng lâu và càng có nhiều biến trong phạm vi.

Ví dụ nếu bạn có

    a=getA();
    b=getB();
    m = ABFactory.mix(a,b);

Ở đầu một hàm lớn hơn, bạn tăng gánh nặng tinh thần trong việc hiểu phần còn lại của mã bằng cách đưa ra ba biến chứ không phải một biến. Bạn có phải đọc qua phần còn lại của mã để xem nếu ahay bđược sử dụng một lần nữa. Các địa phương trong phạm vi dài hơn họ cần có hại cho khả năng đọc tổng thể.

Tất nhiên trong trường hợp một biến là cần thiết (ví dụ để lưu trữ một kết quả tạm thời) hoặc khi một biến không cải thiện khả năng đọc của mã, thì nó nên được giữ lại.

Ngoài các câu trả lời khác, tôi muốn chỉ ra một điều khác. Lợi ích của việc giữ phạm vi của một biến nhỏ không chỉ là giảm bao nhiêu mã về mặt cú pháp có quyền truy cập vào biến mà còn giảm số lượng đường dẫn luồng điều khiển có thể có khả năng sửa đổi một biến (bằng cách gán cho nó một giá trị mới hoặc gọi một phương thức đột biến trên đối tượng hiện có được giữ trong biến).

Các biến trong phạm vi lớp (thể hiện hoặc tĩnh) có các đường dẫn luồng điều khiển có thể nhiều hơn đáng kể so với các biến trong phạm vi cục bộ bởi vì chúng có thể được thay đổi bằng các phương thức, có thể được gọi theo bất kỳ thứ tự nào, bất kỳ số lần nào và thường bằng mã bên ngoài lớp .

Hãy xem getResultphương pháp ban đầu của bạn :

public ABResult getResult() {
    getA();
    getB();
    return ABFactory.mix(this.a, this.b);
}

Bây giờ, tên getAvà getBcó thể gợi ý rằng họ sẽ gán cho this.avà this.b, chúng tôi không thể biết chắc chắn chỉ từ việc nhìn vào getResult. Do đó, có thể các giá trị this.avà this.bđược truyền vào mixphương thức thay vì xuất phát từ trạng thái của thisđối tượng từ trước getResultđược gọi, điều này là không thể dự đoán được vì các máy khách kiểm soát cách thức và thời điểm được gọi.

Trong mã sửa đổi với các biến cục bộ avà bbiến, rõ ràng có chính xác một luồng điều khiển (không có ngoại lệ) từ việc gán từng biến cho việc sử dụng nó, bởi vì các biến được khai báo ngay trước khi chúng được sử dụng.

Do đó, có một lợi ích đáng kể khi di chuyển các biến (có thể sửa đổi) từ phạm vi lớp sang phạm vi cục bộ (cũng như di chuyển (có thể sửa đổi) từ bên ngoài vòng lặp sang bên trong) để đơn giản hóa lý do dòng điều khiển.

Mặt khác, việc loại bỏ các biến như trong ví dụ trước của bạn có ít lợi ích hơn, bởi vì nó không thực sự ảnh hưởng đến lý luận dòng điều khiển. Bạn cũng mất các tên được đặt cho các giá trị, điều này không xảy ra khi chỉ cần di chuyển một biến sang phạm vi bên trong. Đây là một sự đánh đổi mà bạn phải xem xét, vì vậy việc loại bỏ các biến có thể tốt hơn trong một số trường hợp và tồi tệ hơn ở những trường hợp khác.

Nếu bạn không muốn mất tên biến, nhưng vẫn muốn giảm phạm vi của các biến (trong trường hợp chúng được sử dụng bên trong hàm lớn hơn), bạn có thể xem xét gói các biến và cách sử dụng chúng trong câu lệnh khối ( hoặc di chuyển chúng đến chức năng riêng của chúng ).

Điều này hơi phụ thuộc vào ngôn ngữ, nhưng tôi muốn nói rằng một trong những lợi ích ít rõ ràng hơn của lập trình chức năng là nó khuyến khích người lập trình và người đọc mã không cần những thứ này. Xem xét:

(reduce (fn [map string] (assoc map string (inc (map string 0))) 

Hoặc một số LINQ:

var query2 = mydb.MyEntity.Select(x => x.SomeProp).AsEnumerable().Where(x => x == "Prop");

Hoặc Node.js:

 return visionFetchLabels(storageUri)
    .then(any(isCat))
    .then(notifySlack(secrets.slackWebhook, `A cat was posted: ${storageUri}`))
    .then(logSuccess, logError)
    .then(callback)

Cuối cùng là một chuỗi gọi một hàm trên kết quả của hàm trước đó, không có bất kỳ biến trung gian nào. Giới thiệu chúng sẽ làm cho nó ít rõ ràng hơn nhiều.

Tuy nhiên, sự khác biệt giữa ví dụ đầu tiên và hai ví dụ còn lại là thứ tự hoạt động ngụ ý . Điều này có thể không giống với thứ tự nó thực sự được tính toán, nhưng đó là thứ tự mà người đọc nên nghĩ về nó. Đối với hai thứ hai, điều này là trái sang phải. Đối với ví dụ Lisp / Clojure, nó giống từ phải sang trái hơn. Bạn nên cảnh giác một chút về việc viết mã không theo "hướng mặc định" cho ngôn ngữ của bạn và chắc chắn nên tránh các biểu thức "trung gian" kết hợp cả hai.

Toán tử đường ống của F # |>là hữu ích một phần vì nó cho phép bạn viết những thứ từ trái sang phải mà nếu không phải từ phải sang trái.

Tôi sẽ nói không, bởi vì bạn nên đọc "phạm vi nhỏ nhất có thể" là "trong số các phạm vi hiện có hoặc phạm vi hợp lý để thêm". Mặt khác, điều đó có nghĩa là bạn nên tạo phạm vi nhân tạo (ví dụ: {}các khối vô cớ trong các ngôn ngữ giống như C) chỉ để đảm bảo rằng phạm vi của một biến không vượt quá mục đích sử dụng cuối cùng, và điều đó thường sẽ được tán thành như là sự xáo trộn / lộn xộn trừ khi đã có một lý do tốt cho phạm vi tồn tại độc lập.

Xem xét các hàm ( phương thức ). Ở đó, nó không tách mã trong các nhóm con nhỏ nhất có thể, cũng không phải là đoạn mã đơn lẻ lớn nhất.

Đó là một giới hạn thay đổi, với việc phân định các nhiệm vụ logic, thành các phần tiêu hao.

Các biến tương tự giữ cho các biến . Chỉ ra các cấu trúc dữ liệu logic, thành các phần dễ hiểu. Hoặc cũng chỉ đơn giản là đặt tên (nêu) các tham số:

boolean automatic = true;
importFile(file, automatic);

Nhưng tất nhiên có một tuyên bố ở đầu, và hai trăm dòng tiếp theo, việc sử dụng đầu tiên ngày nay được chấp nhận là phong cách xấu. Đây rõ ràng là những gì "các biến nên sống trong phạm vi nhỏ nhất có thể" dự định nói. Giống như rất gần "không sử dụng lại các biến."

Điều hơi thiếu vì lý do cho NO là gỡ lỗi / sẵn sàng. Mã phải được tối ưu hóa cho điều đó, và tên rõ ràng và súc tích giúp ích rất nhiều, ví dụ như tưởng tượng 3 cách nếu

if (frobnicate(x) && (get_age(x) > 2000 || calculate_duration(x) < 100 )

dòng này ngắn, nhưng đã khó đọc. Thêm một vài tham số, và nếu kéo dài nhiều dòng.

can_be_frobnicated = frobnicate(x)
is_short_lived_or_ancient = get_age(x) > 2000 || calculate_duration(x) < 100
if (can_be_frobnicated || is_short_lived_or_ancient )

Tôi thấy cách này dễ đọc hơn và để truyền đạt ý nghĩa - vì vậy tôi không có vấn đề gì với các biến trung gian.

Một ví dụ khác là các ngôn ngữ như R, trong đó dòng cuối cùng tự động là giá trị trả về:

some_func <- function(x) {
    compute(x)
}

Điều này là nguy hiểm, sự trở lại được giải thích hay cần thiết? Điều này rõ ràng hơn:

some_func <- function(x) {
   rv <- compute(x)
   return(rv)
}

Như mọi khi, đây là một cuộc gọi phán xét - loại bỏ các biến trung gian nếu chúng không cải thiện việc đọc, nếu không thì giữ hoặc giới thiệu chúng.

Một điểm khác có thể là khả năng sửa lỗi: Nếu kết quả trung gian được quan tâm, tốt nhất có thể đơn giản là giới thiệu một trung gian, như trong ví dụ R ở trên. Mức độ thường xuyên được gọi là khó tưởng tượng và cẩn thận những gì bạn đăng ký - quá nhiều biến gỡ lỗi gây nhầm lẫn - một lần nữa, một cuộc gọi phán xét.

Đề cập đến chỉ tiêu đề của bạn: hoàn toàn, nếu một biến là không cần thiết, nó sẽ bị xóa.

Nhưng không cần thiết, không có nghĩa là một chương trình tương đương có thể được viết mà không sử dụng biến, nếu không chúng ta sẽ được bảo rằng chúng ta nên viết mọi thứ trong hệ nhị phân.

Loại biến không cần thiết phổ biến nhất là biến không sử dụng, phạm vi của biến càng nhỏ thì càng dễ xác định rằng nó không cần thiết. Cho dù một biến trung gian là không cần thiết thì khó xác định hơn, bởi vì đó không phải là tình huống nhị phân, đó là theo ngữ cảnh. Trong thực tế, mã nguồn giống hệt nhau theo hai phương pháp khác nhau có thể tạo ra một câu trả lời khác nhau bởi cùng một người dùng tùy thuộc vào kinh nghiệm sửa chữa các vấn đề trong mã xung quanh trong quá khứ.

Nếu mã ví dụ của bạn chính xác như được trình bày, tôi sẽ khuyên bạn nên loại bỏ hai phương thức riêng tư, nhưng sẽ không có chút lo ngại nào về việc bạn đã lưu kết quả của các cuộc gọi của nhà máy vào một biến cục bộ hay chỉ sử dụng chúng làm đối số cho hỗn hợp phương pháp.

Khả năng đọc mã vượt qua mọi thứ trừ khi hoạt động chính xác (bao gồm chính xác các tiêu chí hiệu suất có thể chấp nhận được, điều này hiếm khi có thể nhanh nhất có thể).