Có một phương pháp để phân biệt các ý kiến ​​thông tin từ mã nhận xét?

Trong suốt quá trình lập trình, bạn sẽ kết thúc với một số bình luận giải thích mã và một số bình luận đang xóa mã:

// A concise description 
const a = Boolean(obj);
//b = false;

Có một phương pháp tốt để nhanh chóng phân tích đó là cái nào?

Tôi đã chơi xung quanh với việc sử dụng 3 /và /** */để nhận xét mô tả.

Tôi cũng đã sử dụng plugin VSCode để làm nổi bật //TODO:và//FIXME:

Có một giải pháp rất đơn giản cho việc này: xóa mã nhận xét.

Thực sự, chỉ có hai lý do tốt để nhận xét mã: để kiểm tra một cái gì đó / thực hiện sửa lỗi hoặc để lưu mã bạn có thể sử dụng sau này. Nếu bạn đang kiểm tra hoặc sửa lỗi gì đó, hãy xóa mã nhận xét ngay khi bạn hoàn thành kiểm tra hoặc sửa lỗi. Nếu bạn đang lưu mã bạn có thể sử dụng sau này, hãy tạo mã hạng nhất và đặt mã ở đâu đó như thư viện nơi có thể sử dụng mã này.

Thêm vào câu trả lời tuyệt vời của @ RobertHarvey Tôi tin rằng chỉ có một lý do chính đáng mà tôi từng gặp để lưu mã nhận xét vào kiểm soát nguồn, thậm chí tạm thời: trong trường hợp mã thay thế không rõ ràng không nên hoặc không thể sử dụng ngay bây giờ vì một số lý do . Thậm chí sau đó hầu hết các bình luận nên là lời giải thích, không phải là mã thay thế. Đây có thể là một lỗi hoặc một tính năng của ngôn ngữ chưa được coi là ổn định. Nó có thể trông giống như thế này:

# TODO: Replace with `foo = frobnicate(bar)` once <link.to/bug> is fixed
foo = [some complex workaround]

Trong trường hợp này, công việc đã được thực hiện, nhưng bạn chưa thể tận dụng nó, vì vậy xóa nó có nghĩa là ai đó sẽ phải khám phá lại nó sau. Điều tương tự cũng xảy ra đối với các giải pháp tối ưu có vẻ vượt trội khi đối mặt với nó hoặc đánh đổi có ý thức đối với các giải pháp tương tự .

Thận trọng: Không xả rác mã của bạn với các giải pháp thay thế. Mọi nhiệm vụ có thể được thực hiện theo vô số cách khác nhau và không hiệu quả về chi phí khi khám phá không gian này trong một thời gian dài cho mỗi thay đổi. Đánh giá mã có thể là một nơi tốt để khám phá những bình luận bị thiếu như vậy, khi đồng nghiệp của bạn đề xuất một cải tiến mà bạn đã phát hiện ra là tối ưu.

Hmm, tôi đọc câu hỏi này hơi khác với Robert, người khẳng định chính xác rằng mã nhận xét nên được loại bỏ.

Tuy nhiên, nếu bạn đang tìm kiếm một quy ước để đánh dấu mã để loại bỏ sau này, một mục yêu thích cũ của tôi là:

//b = false; //TODO: remove

Một số //TODO:ý kiến cờ của IDE hoặc có thể được dạy. Nếu không, nó thường là một chuỗi có thể tìm kiếm. Tốt nhất là tuân theo bất kỳ quy ước nào mà cửa hàng của bạn đã thiết lập vì điều này có thể được thực hiện theo nhiều cách. Mỗi cơ sở mã nên làm theo cách này. Giữ cho nó có thể tìm kiếm.

nhanh chóng phân tích cái nào?

Không có đánh dấu, cách tự động để làm điều này là với trình biên dịch. Nếu tước nhận xét tắt sẽ tạo ra mã biên dịch, nó phải là mã nhận xét. Viết một plugin IDE kiểm tra sẽ không khó. Nhưng nó sẽ để lại lỗi nhận xét mã phía sau.

Đây là lý do tại sao tốt hơn là chỉ cần đánh dấu mã nhận xét là mã ngay khi bạn nhận xét. Điều này cho phép bạn làm việc không phá hủy trong khi bạn quyết định nếu bạn thực sự muốn nó đi. Vì tất cả chúng ta đều bị gián đoạn và có phần hay quên, đừng ngạc nhiên nếu một số dòng được kiểm tra khi ở trạng thái đó. Nếu họ làm tốt thì ít nhất họ cũng được đánh dấu rõ ràng và có thể tìm kiếm. Các macro bàn phím đã giúp tôi với điều này trong quá khứ. Thật khó để bị gián đoạn ở giữa điều này nếu bạn có thể làm điều đó với một lần nhấn phím.

Bạn có thể đạt được điều này khi ghi dấu trong các bài kiểm tra tích hợp liên tục của bạn. Rất tiếc, tôi đang cố gắng đăng ký lại với TODO xuất sắc.

Tôi sử dụng các chỉ thị tiền xử lý để loại bỏ mã, không bình luận gì cả:

//comment
active_code();
#if FALSE
inactive_code();
#endif

Điều này làm cho một điều rất dễ tìm kiếm, và cú pháp của tôi highlighter coi nó như một bình luận. Tôi thậm chí có thể thu gọn nó thành một dòng duy nhất:#if FALSE(...)

Bạn có thể mở rộng ý tưởng đó để có một số tùy chọn:

#if OPTION == 0
code_for_option_0();
#elif OPTION == 1
code_for_option_1();
#else
code_for_all_other_options();
#endif

Và kiểm tra lỗi thời gian biên dịch:

#if FOO >= 5
#error FOO should be less than 5!
#endif

Tất nhiên, bạn không muốn quá nhiệt tình với điều này, hoặc trở nên khó khăn để nói những gì thực sự được biên dịch và những gì không. Nhưng bạn hiểu ý tưởng và đó cũng là vấn đề tương tự như đối với mã nhận xét ... miễn là bạn chỉ sử dụng nó một cách tĩnh. Nếu điều kiện của bạn là năng động, nó tồi tệ hơn.

Để xác định cái nào trong một cơ sở mã hiện tại không xem xét vấn đề này, tôi không nghĩ có một giải pháp phổ quát. Bạn sẽ phải tự tìm mẫu và có thể viết mã regex để tìm chúng.

Tôi đồng ý với câu trả lời nói rằng nên xóa mã cũ thay vì nhận xét nếu có thể, tuy nhiên tôi đã quan sát một quy ước cho một vài lần khi cần mã nhận xét.

(Cơ sở của tôi là C # nhưng điều này có thể được áp dụng cho bất kỳ ngôn ngữ cú pháp C nào, ví dụ java)

// An explanatory comment has a space between the comment marker and the content.

// The following lines are commented out code so do not have the space (except where indented).
//var a = something();
//if(a==2) {
//   doSomethingElse();
//}

Tôi đang giải thích câu hỏi khác nhau, nghĩ rằng bạn muốn tìm mã nhận xét.

Mã kiểu C buộc phải có dấu chấm phẩy trong đó trong khi nhận xét không có khả năng có dấu chấm phẩy trong đó. Vì vậy, đối với mã nhận xét dòng đơn, bạn có thể sử dụng biểu thức chính quy này:

\s*\/\/[\s\S]*;

Đối với mã nhận xét nhiều dòng, nó có thể là

\/\*[^\;]*;[^\;]*\*\/

Lưu ý Visual Studio là một chút đặc biệt về ngắt dòng trong các biểu thức thông thường, chúng không được tính là khoảng trắng, bạn cần chỉ định một \ n rõ ràng.

Nếu bạn sử dụng trình chỉnh sửa với trình biên dịch chạy trong nền (như Xcode và Clang), bạn chỉ có thể cố gắng biên dịch văn bản của nhận xét. Ví dụ, một mô tả ngắn gọn, đưa ra các lỗi, lỗi b = false; không có. Sau đó bạn có thể sử dụng tô sáng cú pháp khác nhau.

Một phương pháp đơn giản hơn sẽ là một plugin IDE sử dụng một số phương pháp phỏng đoán, như nhiều từ trong một hàng khác với từ khóa trỏ đến nhận xét, khớp điểm được uốn cong với mã, v.v.

Các câu trả lời khác có các biến thể về chủ đề "không bình luận ra mã". Nhưng đôi khi bạn vẫn muốn nó xung quanh để tham khảo.

Nếu bạn thực sự cần mã để ở xung quanh, một giải pháp tốt hơn là bao quanh mã với "#if 0 ... #endif", lý tưởng là có một nhận xét để nói lý do tại sao. Đây là chiến lược được đề xuất từ ​​các tiêu chuẩn mã hóa khác nhau, bao gồm MISRA.

Đơn giản, ít nhất là đối với tôi - và trong C / C ++. Nhận xét kèm theo trong / * * / là thông tin. Mã kiểm tra tạm thời bị xóa được nhận xét với hàng đầu //.

Và có lý do chính đáng để để lại mã kiểm tra trong tệp nhưng nhận xét, ít nhất là trong loại công việc tôi làm. Sớm hay muộn ai đó sẽ muốn một thay đổi được thực hiện, sẽ cần mã đó. Bỏ ghi chú một khối sẽ có một lệnh biên tập, cũng như nhận xét lại nó khi bạn hoàn thành.