Nhận xét của Google về cuối khối mã sau} - tốt hay xấu? [đóng cửa]

Tôi thường thấy những bình luận như vậy được sử dụng:

function foo() {
   ...
} // foo

while (...) {
   ...
} // while

if (...) {
   ...
} // if

và đôi khi thậm chí xa như

if (condition) {
   ...
} // if (condition)

Tôi chưa bao giờ hiểu thực hành này và do đó không bao giờ áp dụng nó. Nếu mã của bạn quá dài đến mức bạn cần biết kết thúc }này là gì thì có lẽ bạn nên xem xét tách nó thành các chức năng riêng biệt. Ngoài ra, hầu hết các công cụ dành cho nhà phát triển đều có thể chuyển sang khung phù hợp. Và cuối cùng, cuối cùng, đối với tôi, một sự vi phạm rõ ràng đối với nguyên tắc DRY; nếu bạn thay đổi điều kiện, bạn cũng sẽ phải nhớ thay đổi nhận xét (nếu không nó có thể gây rắc rối cho người bảo trì, hoặc thậm chí cho bạn).

Vậy tại sao mọi người sử dụng điều này? Chúng ta nên sử dụng nó, hoặc nó là thực hành xấu?

Tôi sẽ nói nếu mã của bạn dài đến mức bạn không thể dễ dàng theo dõi niềng răng của mình, mã của bạn cần tái cấu trúc, đối với hầu hết các ngôn ngữ.

Tuy nhiên, trong các ngôn ngữ tạo khuôn mẫu (như PHP), nó có thể hợp lệ, bởi vì bạn có thể có một khối HTML lớn ngăn cách phần đầu và phần cuối của điều kiện hoặc cấu trúc vòng lặp.

Đó là một mùi mã và thường là nôn nao từ phong cách mã lỗi thời. Trước khi việc tái cấu trúc IDE tốt trở nên khó khăn hơn và không phổ biến như bây giờ, do đó các phương pháp đã dài hơn và những bình luận này đã có để giúp điều hướng chúng tốt hơn.

Đây là một thực tế khủng khiếp làm cho lỗi thời bởi nhiều yếu tố.

• Hầu hết các IDE hiện đại làm nổi bật nẹp tương ứng khi dấu mũ nằm trên một trong hai biểu tượng.
• Nếu bạn đang viết mã sạch, bạn sẽ hiếm khi tìm thấy một nơi mà phương thức của bạn dài hơn 10 dòng.

Tôi nhận thấy rất nhiều lập trình viên Java có suy nghĩ này và nó làm cho mã Java trông thực sự bẩn và lấy sự tập trung ra khỏi mã và hướng tới các bình luận.

Rất đề nghị chống lại việc sử dụng này.

Mã được đọc nhiều hơn 10 lần so với mã được viết.

Nếu nó làm cho nó dễ đọc hơn, hãy làm nó.

Tôi cũng đề nghị với bất cứ ai làm điều này rằng họ nên xem xét một số cách khác để làm cho mọi thứ dễ đọc hơn. Các kỹ thuật tái cấu trúc, dấu ngoặc trên các dòng khác nhau, vv mà những người khác đã đề cập đều tốt. Chia mọi thứ thành các hàm, phương thức hoặc lớp khác nhau để mã tự nhận xét cũng tốt. Cũng có những cách để loại bỏ hầu hết các vòng lặp "ifs" và đặt "for" vào những nơi rõ ràng, do đó loại bỏ sự cần thiết của bất kỳ thứ gì trong số này.

Nhưng, đôi khi mọi người đang học. Nếu đây là điều họ đang làm thực sự làm cho mã dễ đọc hơn, hãy khuyến khích nó và sau đó khuyến khích một số thực tiễn khác. Những người đang học tập xứng đáng và sẽ được hưởng lợi từ sự khuyến khích, bất kể họ bắt đầu như thế nào. Nói "Điều này là xấu" không hữu ích như nói "Điều này khác tốt hơn".

Tôi đã có một cơ sở mã lớn (C ++) với đầy đủ các loại điều này:

int Class::AccessorMethod(void)
{
    return privateValue;
}//end AccessorMethod

Đối với một cái gì đó nhỏ, tôi muốn nói điều này vượt xa "mùi mã" thành "mùi hôi thối mã". Đặc biệt là trong một IDE nơi tôi có thể kết hợp nẹp đóng với một tổ hợp phím để tìm nẹp mở. Đưa ra một phương pháp dài hơn, tôi vẫn sẽ kết hợp niềng răng trên bình luận cuối cùng. Những bình luận như vậy làm tôi mất tập trung và tôi có xu hướng nghĩ về chúng như tiếng ồn.

Trong C ++, có hai cách giữ mà điều này vẫn hữu ích và lời khuyên "tách mã của bạn" không cần giữ:

1. Đối với không gian tên. Một không gian tên có thể bao gồm toàn bộ tệp và dấu ngoặc cuối cùng đôi khi có thể khiến mọi người bỏ qua, vì vậy việc thêm một nhận xét để chỉ ra dấu ngoặc là việc đóng một không gian tên là hữu ích. Đối với phong cách mã hóa cụ thể tại công ty của tôi, điều này rất quan trọng vì chúng tôi không thụt lề không gian tên vì đã quyết định rằng việc thụt lề như vậy sẽ chỉ lãng phí không gian trong một tệp.

2. Đối với các cặp #ifdef / #endif. Đôi khi có rất nhiều mã trong đó để biên dịch có điều kiện, nó có thể gây khó chịu khi lồng và trình soạn thảo chúng tôi thường sử dụng một cách "trợ giúp" một cách nặng nề để loại bỏ thụt lề, vì vậy các bình luận rất hữu ích trong quá trình tổng quan nhanh.

Đối với tôi mã phải khó hiểu để thêm một bình luận như bạn đã chỉ định.

Nếu nó chỉ nói // IF Statement. Sau đó, bạn phải tự hỏi tại sao nó ở đó ngay từ đầu.

Thay thế để xem những gì niềng răng của bạn đang đóng là có một cái mở trên cùng một cột với cái đóng. Tôi thấy rằng rõ ràng hơn và dễ đọc hơn.

Nhận xét này rất hữu ích khi thông thường sẽ khó theo dõi vì việc mở đã xảy ra từ lâu. Điều này thường chỉ xảy ra đối với một không gian tên (đặc biệt là không gian ẩn danh trong C ++, được sử dụng cho chi tiết triển khai trong đơn vị biên dịch). Trong hầu hết các trường hợp khác, rõ ràng những gì bạn đang đóng.

Điều này phần lớn là sự nắm giữ từ những ngày xưa làm việc trong các cửa sổ đầu cuối 80x24 ký tự, đặc biệt nếu bạn đang sử dụng một trình soạn thảo có cửa sổ như EVE. Ngay cả bây giờ, tôi thực hiện hầu hết công việc của mình trong phiên cuối bằng cách sử dụng vim và tôi có thể chia phiên thành ba hoặc bốn luồng, vì vậy tôi chỉ có thể thực sự xem một vài dòng bất kỳ lúc nào.

Điều đó nói rằng, tôi không bao giờ thực sự ấm áp với hội nghị, mặc dù nó sẽ cứu thịt xông khói của tôi nhiều hơn một lần. Tôi chỉ xem đó là tiếng ồn. Nếu các vòng lặp hoặc điều kiện của bạn đang trở nên lớn như vậy, yeah, bạn có thể muốn xem xét tái cấu trúc.

về cơ bản bạn đưa ra tất cả các lý do hợp lệ tại sao không sử dụng điều này. Mỗi lập trình viên tốt nên áp dụng những. Vậy tại sao làm người sử dụng nó? Bởi vì họ đang làm sai và không biết tốt hơn.