Có phải thực tế xấu để tạo các khối mã?


12

Trong C ++, có phải thực tế xấu là tạo các khối mã bên trong một số chức năng, chẳng hạn như sau:

    bool f()
    {
       {
           double test = 0;

           test = // some other variable outside this function, for example.

           if (test == // some value)
             return true;
       }

       {
           double test = 0;

           test = // some variable outside this function, different from the last one.

           if (test == // some value)
             return true;
       }

       return false;

    }

Điểm của việc này sẽ là sử dụng cùng một tên biến "kiểm tra" nhiều lần, cho cùng một loại thủ tục. Trong thực tế dự án của tôi, tôi có nhiều biến và đang thực hiện nhiều thử nghiệm. Tôi thực sự không muốn tiếp tục tạo các biến mới với các tên khác nhau cho mỗi bài kiểm tra, xem xét cách các bài kiểm tra rất giống nhau.

Có phải là thực tế xấu khi chèn các khối mã để các biến đi ra khỏi phạm vi sau mỗi thử nghiệm, và sau đó tôi có thể sử dụng lại tên của chúng không? Hay tôi nên tìm kiếm một giải pháp khác? Cần lưu ý rằng tôi đã cân nhắc sử dụng cùng một bộ biến cho tất cả các thử nghiệm của mình (và chỉ đặt tất cả chúng thành 0 sau khi mỗi thử nghiệm kết thúc), nhưng tôi cảm thấy điều này có thể là một thực tiễn tồi.


19
Nếu tôi đang báo cáo mã này, tôi sẽ bảo bạn tách từng thử nghiệm này thành các phương thức riêng lẻ ... Do đó, bạn sẽ không cần phải sử dụng các khối mã để phạm vi chúng một cách riêng biệt.
Có lẽ là

1
@Maybe_Factor - Tôi đồng ý. Lợi ích của các phương thức riêng biệt là bạn có thể đặt tên cho mỗi khối, cung cấp một mã dễ đọc hơn.
mouviciel

@mouviciel Không chỉ là mã dễ đọc hơn, mà là các báo cáo thử nghiệm dễ đọc hơn!
Có lẽ là

@Maybe_Factor Tôi không đồng ý. Di chuyển mọi thứ vào các chức năng riêng biệt có tác động tiêu cực làm cho chúng có vẻ giống như các bit chức năng có thể tái sử dụng. Giữ tất cả logic cho một chức năng ở một nơi là tốt.
Miles Rout

1
@MilesRout Đây không phải là một hàm logic, đây là nhiều bài kiểm tra đơn vị cho một hàm tất cả được nhồi nhét vào một hàm kiểm tra duy nhất. Khối mã so với các hàm trong mã thông thường là một cuộc thảo luận hoàn toàn khác.
Có thể là

Câu trả lời:


22

Các khối là hoàn toàn hợp lý nếu bạn đang sử dụng chúng để phạm vi một số tài nguyên. Tập tin, kết nối mạng, phân bổ bộ nhớ, giao dịch cơ sở dữ liệu, bất cứ điều gì. Trong những trường hợp đó, khối thực sự là một phần của cấu trúc logic của mã: bạn sinh ra một tài nguyên, nó tồn tại trong một khoảng thời gian và sau đó nó biến mất vào một thời điểm được chỉ định.

Nhưng nếu tất cả những gì bạn đang làm là tìm kiếm một cái tên , thì tôi sẽ nói rằng chúng là thực tiễn tồi. Nói chung, tất nhiên; trường hợp đặc biệt có thể áp dụng.

Ví dụ: nếu chức năng này được tạo bởi một số hệ thống tạo mã, khung thử nghiệm hoặc tương tự, thì các khối vì mục đích của phạm vi tên là một điều hợp lý. Nhưng bạn sẽ nói về mã được viết cho mục đích của một cỗ máy chứ không phải con người.

Nếu một người đang viết mã trong đó họ cần sử dụng lại các tên trong cùng một hàm, tôi sẽ nói rằng các khối đó có thể cần phải là các hàm riêng biệt. Đặc biệt là nếu những tên đó đang được sử dụng với các loại và / hoặc ý nghĩa khác nhau trong các khối đó.


10

Nó không phải là thực hành xấu để tạo ra các khối như thế này. Đó là cách phạm vi hoạt động.

Thông thường, điều này được thực hiện khi sử dụng RAII (Thu nhận tài nguyên là khởi tạo) và bạn muốn kiểm soát khi các hàm hủy được gọi.

Nếu nó dài ra, tôi sẽ xem xét chuyển mã đó sang chức năng riêng của nó.

Theo tôi chỉ sử dụng nó để tái chế các tên biến không phải là một ý tưởng tốt. Nhưng tôi có thể thấy nó hữu ích trong trường hợp bộ nhớ thấp


Tái sử dụng tên biến cục bộ không ảnh hưởng đến việc sử dụng bộ nhớ.
kevin cline

1
Bạn không nghĩ rằng trình tối ưu hóa thông minh có thể sử dụng 1 vị trí bộ nhớ cho 2 biến?
Robert Andrzejuk

3
Đúng. Nhưng nó cũng có thể làm điều đó nếu chúng ở cùng phạm vi, nếu chúng không có hàm hủy.
Sebastian Redl
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.