Viết mã chết có hữu ích không?

Bạn có thấy viết mã chết hữu ích không?

Một số người nói "Nếu bạn có 2 logic để thực hiện một số thao tác thì thay vì làm cho mã logic khác được nhận xét hoặc xóa mã làm cho mã chết vì nó sẽ không ảnh hưởng đến hoạt động."

Thí dụ:-

if(true){
    // logic - 1
} else {
    // logic - 2  // dead code
}

Có thật không?

Tôi thường không viết mã chết thay vào đó tôi chỉ xóa logic thứ hai.

IMO, nó tệ hơn vô nghĩa.

Ngoài việc lãng phí thời gian, nó còn mang lại cho bạn (hoặc anh chàng tiếp theo) ảo tưởng rằng bạn đã có một số mã sẽ hoạt động nếu bạn đổi truesang false. Nó chỉ là ảo ảnh ... trừ khi bạn kiểm tra nó.

Và nếu tất nhiên, chính sự lộn xộn làm cho mã khó đọc hơn.

Nếu bạn sử dụng bất kỳ loại mã chết SCM nào hiếm khi hữu ích. Bạn nên xóa nó thay vào đó và nếu bạn cần xem mã cho logic 2, bạn lấy nó từ kho SCM.

Biên tập:

Nếu bạn có mã chết và đang duy trì các phần khác của mã, bạn có thể thử và sử dụng một số mã có thể bật mã chết. Nếu ai đó đang thực hiện bảo trì, họ có thể không biết mã thực sự đã chết và ngay cả khi họ làm, họ chắc chắn sẽ không biết tại sao nó vẫn ở đó.

Sau đó, nếu bạn nghĩ rằng một phương thức có thể bị xóa vì nó không được sử dụng bởi mã "sống" mà chỉ bởi mã chết, bạn phải thay đổi (và rất có thể phá vỡ) mã chết của bạn hoặc tự tạo mã chết cho phương thức đó.

Cuối cùng, bạn chắc chắn sẽ kết thúc ở một dạng địa ngục bảo trì.

Do đó, mã tốt nhất là mã bị xóa, vì nó không thể tạo ra kết quả sai hoặc làm mất tập trung người bảo trì. :)

Không, đó là xấu, bởi vì nó làm tắc mã của bạn và giảm khả năng bảo trì.

Thông thường, có một lý do rõ ràng để thích một trong những "logic" thay thế. Lý do này (và sự tồn tại của một thay thế bị từ chối) nên được ghi lại trong một nhận xét mã. Trong trường hợp tương đối khó xảy ra là lý do trở nên không hợp lệ, mã thay thế có thể được truy xuất từ ​​lịch sử kho lưu trữ (nếu đó là giải pháp được triển khai, ưu tiên trước đó) hoặc được bổ sung và thực hiện bằng cách sử dụng toàn bộ kiến ​​thức và yêu cầu hiện tại (nếu đó chỉ là mơ hồ ý tưởng).

Nó không ảnh hưởng đến hoạt động nhưng nó ảnh hưởng đến bảo trì. Bạn muốn giữ mã gọn gàng nhất có thể để dễ bảo trì hơn.

Tôi thực sự bối rối bởi những gì bạn đang làm.

Theo thứ tự ưu tiên giảm dần:

1. Bạn nên giữ một bản ghi các thay đổi mã ở đâu đó để nếu mã mới không hoạt động, bạn có thể so sánh chúng. Điều này phải luôn luôn được kiểm soát nguồn. Tôi giả sử bạn đã làm điều này. Nếu không, hãy làm mọi thứ bạn có thể để có MỘT SỐ hình thức kiểm soát nguồn. Nếu bạn hoàn toàn phải làm mà không có (và tôi chưa bao giờ nghe thấy trong một dịp nào đó khi đây là một ý tưởng hay), thì ít nhất hãy thực hiện sao lưu thường xuyên trạng thái của nguồn dễ dàng truy cập.

2. Giả sử bạn đang làm số 1, vì vậy bạn có thể khôi phục mã chết nếu bạn cần, KHÔNG giữ mã đó trong mã trực tiếp lâu dài. Nó sẽ chỉ gây nhầm lẫn, thêm phức tạp không có giá trị, yêu cầu bảo trì, không đồng bộ với mã trực tiếp và đánh lừa mọi người trong tương lai, v.v., v.v.

3. Điều đó nói rằng, có những tình huống cụ thể trong đó một chuyển đổi thời gian biên dịch giữa hai đường dẫn mã là hợp lý. Trong khi bạn đang phát triển mã mới và ngay lập tức sau đó, nó có thể được triệu tập để có cả hai, vì vậy bạn có thể dễ dàng chuyển đổi giữa. Nếu bạn có khả năng phải quay lại hoặc thêm tùy chọn cấu hình bên ngoài, nếu dựa trên hằng số sẽ cung cấp cho những đường dẫn nâng cấp hợp lý. Vì vậy, giống như nhiều thứ - nếu nó giải quyết một vấn đề cụ thể, hãy làm nó. Nếu không, hãy tránh nó.

Lý do tôi cho rằng poeple làm điều đó quá nhiều là: từ việc nghi ngờ (thường là chính xác) rằng mọi người sẽ thực sự đọc lịch sử kiểm soát nguồn nếu họ gặp vấn đề; khỏi sợ mã mới sẽ không hoạt động và muốn một tùy chọn đảo ngược dễ dàng. Một sự thỏa hiệp để cố gắng hoàn thành cả hai bạn có thể là đưa ra một nhận xét "Thay đổi để tính toán ... vào (Ngày). Nếu có bất kỳ vấn đề nào, hãy xem phiên bản cũ trong kiểm soát nguồn" hoặc tương tự.

Không, nó không hữu ích. Đó là elsekhối không đáp ứng mục đích nào. Nếu bạn không chắc nên sử dụng triển khai nào, hãy nhận xét nó, tạo các lớp riêng biệt hoặc lưu nó ở nơi khác. Ngoài ra, chủ yếu là bạn có - hoặc ít nhất nên có - lịch sử cục bộ hoặc từ xa của các tệp nguồn của bạn.

Mã chết sẽ bị xóa bởi trình biên dịch nếu điều kiện phụ thuộc vào hằng số thời gian biên dịch, vì vậy về mặt kỹ thuật sẽ không gây hại gì cho việc giữ nó. Tuy nhiên, tôi thích nhận xét hơn vì điều này giúp cải thiện khả năng đọc của mã.

Nếu bạn muốn có thể nhanh chóng chuyển đổi giữa hai lựa chọn thay thế mã, bạn có thể sử dụng cấu trúc nhận xét thuận tiện sau đây:

//*
alternative 1 is active
/*/
alternative 2 is commented out
//*/

nếu bạn chỉ xóa đầu tiên /trong dòng nhận xét đầu tiên, nó sẽ trở thành:

/*
alternative 1 is commented out
/*/
alternative 2 is active
//*/

Với điều này, bạn có thể chuyển đổi giữa các lựa chọn thay thế bằng cách chỉ cần thêm hoặc xóa một /trong mã.

Điều này thoạt nhìn có vẻ hơi lạ nhưng một khi bạn đã quen với nó, bạn sẽ dễ dàng nhận ra đó là một kiểu mẫu nào đó.

Bạn thậm chí có thể xâu chuỗi chuỗi này và do đó chuyển đổi nhiều khối cùng một lúc với một char:

//*
first block of code for alternative 1
/*/
first block of code for alternative 2
/*/
second block of code for alternative 1
/*/
second block of code for alternative 2
//*/

Tôi sẽ không sử dụng nó theo cách này nhưng nó hoạt động.

Có một số trường hợp rất hiếm khi mã cũ và thực tế là nó đã được thay thế, thực sự nên ở trong mã nguồn để các lập trình viên trong tương lai được cảnh báo về một cái gì đó phản trực giác. Trong trường hợp đó, cũng cần một số loại bình luận giải thích tại sao nó vẫn ở đó và những gì đã xảy ra.

Như mọi khi, viết các chương trình dễ bảo trì là làm cho mọi thứ rõ ràng hơn, không chỉ tuân theo các quy tắc khó và nhanh. Nếu để lại mã chết để dễ hiểu những gì đang diễn ra, thì hãy để nó vào. Nếu không, hãy lấy nó ra.

Nó sẽ bị bỏ qua bởi trình biên dịch. Tuy nhiên tôi đồng ý với bạn và sẽ chỉ xóa các tuyên bố khác. Giả sử bạn đang sử dụng kiểm soát phiên bản, bạn vẫn có thể xem mã cũ bằng cách xem lịch sử của tệp.

Đây có lẽ là một ý kiến ​​cá nhân, nhưng tôi thấy mã chết mất tập trung khi duy trì một đoạn mã. Đối với bất kỳ nhiệm vụ nhất định, bạn luôn có nhiều hơn một cách để hoàn thành nó, vì vậy bạn phải chọn một cách. Thực hiện nghiên cứu của bạn, đánh giá các thuật toán và chọn một thuật toán. Sau này, mã không cần chứa bất kỳ phương thức thay thế nào bên trong nó.

Nếu có hai ứng cử viên rất mạnh, hãy viết một ghi chú nhỏ về giải pháp thay thế và dán nó vào wiki dự án hoặc một nơi nào khác có chứa tài liệu dự án. Nếu bạn muốn, bạn có thể đặt một nhận xét một dòng đề cập đến tài liệu này và nêu ra lý do tại sao bạn có thể muốn đọc nó.

Tôi không thể nghĩ ngay đến một tình huống mà tôi thấy việc viết mã chết là hữu ích. Nếu có các thuật toán thay thế, thì:

• hoặc bạn giữ cái hữu ích nhất và loại bỏ cái kia,
• hoặc các thuật toán được áp dụng cho các trường hợp khác nhau, và sau đó bạn giữ cả hai và điều kiện xác định các trường hợp khi bạn sử dụng thuật toán đầu tiên.

Trong cả hai trường hợp, bạn sẽ không có mã chết.

Nếu bạn không xóa hoặc nhận xét mã chết của mình, bạn sẽ phải duy trì nó để tránh lỗi trình biên dịch. Thật lãng phí thời gian. Chỉ cần xóa nó nếu bạn có SCM.

KHÔNG

Một số lập trình viên sử dụng phong cách này như là một thay thế cho ý kiến ​​và thấy nó thanh lịch.

if (1 == 0) 
{
    std::cout <<"I am a dead code capable of resurrection, once a programmer changes the condition!";
}

Câu trả lời đơn giản là không đơn giản. Mã chết thu hút sự nhầm lẫn và cơ hội cho lỗi xảy ra. Ngay khi bạn nhập một ký tự vào mã, có một rủi ro. Vì vậy, đừng thêm nhiều hơn bạn phải.

Một lần tôi phải viết một cái gì đó tương tự là một lỗi xung quanh trình biên dịch, nó thậm chí còn được nhà cung cấp trình biên dịch khuyên dùng để sử dụng công việc này.

Bạn có kiểm tra mã chết bạn viết không? Làm bất cứ điều gì để xác nhận rằng nó có thể tốt? Nếu không, hãy thoát khỏi nó.

Để thay đổi mã trong tương lai, bạn có xác minh rằng mã chết vẫn hoạt động không? Nếu không, hãy thoát khỏi nó.

Bạn không muốn mã xấu trong các chương trình của mình, ngay cả khi nó không được sử dụng. Có nó ở đó cho thấy rằng nó có thể được sử dụng. Bạn thường không muốn duy trì hai phiên bản mã nếu bạn không sử dụng cả hai phiên bản, vì đó là công việc bổ sung và vì cảm thấy vô nghĩa, hầu hết mọi người sẽ không làm tốt công việc mã chết.

Có thể có lý do để giữ mã nhận xét (hoặc, trong C hoặc C ++, #ifdefmã ed out), nhưng điều này nên đi kèm với các nhận xét về lý do tại sao nó vẫn ở đó và mục đích của nó là gì.

Lưu ý rằng trong Java, các phần sau sẽ không được biên dịch, do mã không thể truy cập:

int someFunc() {
    return 10;
    int x = 12;
    return x;
}

Lý tưởng nhất là nếu có gì đó không đúng với mã của bạn, bạn muốn tìm nó càng sớm càng tốt, thay vì để nó đi vào sản xuất và được tìm thấy bởi người dùng của bạn.

Nếu trình biên dịch của bạn có thể tìm thấy một lớp lỗi, thì hãy để trình biên dịch tìm thấy nó. IMHO, những gì ai đó đang làm bằng cách viết mã chết theo cách bạn mô tả, đang cố gắng khắc phục lỗi trình biên dịch đó, cho phép mọi vấn đề mà nó có thể gây ra khi chạy.

Bạn có thể lập luận rằng mã chết không thể đạt được, vì vậy không thể gây ra vấn đề, nhưng điều gì đó có thể trở nên tồi tệ trong việc bình luận, giằng và thụt có thể làm cho nó xảy ra.

Lý do tại sao mọi người nhận xét một số logic cũ là vì họ sợ thực hiện các thay đổi lớn đối với mã. Và thực sự, nhận ra một tuần sau đó, mã cũ thực sự chính xác và bây giờ bạn phải viết nó từ đầu là một con chó cái. Nhưng đó là những gì kiểm soát nguồn là cho. Nếu bạn quyết định thay đổi một số logic, đừng sợ mất mã hiện tại đang hoạt động. Xóa nó và để SVN / Git / TFS của bạn chăm sóc phiên bản cho bạn.

Nếu không phải như vậy và bạn chỉ tạo ra hai phần logic khác nhau để làm điều gì đó vì bạn không quan tâm đến YAGNI hoặc DRY, thì hãy đảm bảo rằng bạn đặt nó ở một nơi mà mọi người có thể sử dụng nó. Có thể ném một mô hình chiến lược ở đó nếu bạn cảm thấy thích nó. Đừng làm những việc "nếu .. khác", đó là thiết kế tồi và là một nỗi đau để duy trì. Nếu bạn thực sự nghĩ rằng một số mã có quyền tồn tại, hãy chắc chắn rằng bạn làm cho nó có thể sử dụng nó.

Một cái nhìn khác về cơ bản là hầu hết các lập trình viên chuyên nghiệp đều đồng ý rằng kích thước của mã là kẻ thù. Hãy xem các bài đăng trên blog này: Mã tốt nhất hoàn toàn không có mã của Jeff Atwood, kẻ thù tồi tệ nhất của Code của Steve Yegge, bạn có thể tìm thấy nhiều hơn nữa.

Mọi người đang làm rất nhiều việc để giữ cho mã của họ ngắn gọn và ngăn chặn codebase trở nên quá lớn, thậm chí bằng cách hy sinh hiệu năng (nơi nó không quan trọng lắm). Vì vậy, bạn có thực sự nghĩ rằng 100 dòng mã chết có thể là một điều tốt?

Nơi duy nhất tôi thấy điều này hữu ích là trong trường hợp bạn muốn nhanh chóng vô hiệu hóa một cái gì đó và kiểm tra / chèn lấp (Nói chương trình thực hiện các bước A, B, C - tất cả đều mất nhiều thời gian. Trong quá trình che lấp, bạn có thể chọn tắt B và C cho thời gian để tăng tốc nó nếu bạn biết họ không cần thiết).
Nhưng sự thật là trong tất cả các trường hợp, điều này rất hack. Và nếu bạn thấy việc sử dụng lâu dài cho mã chèn lấp của mình, bạn nên viết mã theo cách mà nó sử dụng cấu hình để chọn một lựa chọn thay vì sử dụng các bản hack như vậy.
Quy tắc nhanh chóng của tôi là không bao giờ kiểm tra loại mã này. Nếu bạn cần kiểm soát đăng ký / phiên bản, điều đó có nghĩa là bạn sẽ có thể sớm quay lại vấn đề này và đó luôn là một điều tồi tệ trong việc thay đổi các yêu cầu.

Trên thực tế, có một cách hữu ích để có mã "chết": khi bạn muốn chương trình của mình đưa ra một ngoại lệ lớn vì nó đạt được điều gì đó không bao giờ nên xảy ra. Đây có thể là lỗi trình biên dịch hoặc nếu ai đó lên dòng đã thay đổi logic trong bài kiểm tra bạn đang sử dụng và làm hỏng nó. Dù bằng cách nào, "người khác" của bạn sẽ gửi pháo hoa lên. Trong trường hợp này, bạn muốn ifdef nó ra để phát hành.

Điều cực kỳ quan trọng là thông báo lỗi nêu lên một cái gì đó như "Hoảng loạn: chúng ta không bao giờ phải ở đây tại dòng% d trong tệp% s" ...