Độ dài và độ rộng dòng 'đề xuất' [đã đóng]

Tôi tò mò liệu có ai biết về một khuyến nghị từ một nguồn có uy tín về số lượng dòng mã tối đa cho một tệp nhất định không. Ví dụ: Công cụ đóng cửa của Google khuyến nghị rằng mỗi dòng không được vượt quá 80 ký tự.

Một tệp phải đủ ngắn để bạn có thể tìm thấy bất kỳ chức năng hoặc phương thức nào mà không cần cuộn qua lại nhiều lần để tìm kiếm nó hoặc phải nhớ một chuỗi tìm kiếm. Số liệu tôi sử dụng là lượng thời gian tôi dành để tìm mã trong một tệp so với đọc nó. Nếu điều đó trở nên đáng chú ý, đã đến lúc phân vùng lại tệp hoặc lớp.

Một kích thước tốt cho một khối mã cơ bản là đủ ngắn, cả về chiều rộng và chiều cao, mà bạn có thể chiếu sự can đảm của nó trong quá trình đánh giá mã nhóm và có tất cả phù hợp mà không cần phông chữ quá nhỏ mà anh chàng ở phía sau phòng hội thảo không thể đọc nó. Kích thước này cũng hữu ích nếu bạn được gọi để giải thích một số mã khi tất cả những gì bạn có với bạn là một thiết bị di động hoặc máy tính bảng.

Không có điều đó, và nếu có, nó sẽ phụ thuộc rất nhiều vào ngôn ngữ bạn đang sử dụng (làm điều tương tự trong trình biên dịch so với C # hoặc Java chẳng hạn).

Đối với các ngôn ngữ cấp cao hơn, bạn có thể xem cuộc thảo luận SO này . Đối với Java / C #, 10-20 dòng trên mỗi phương thức là những gì Bob Martin khuyến nghị ở mức tối đa. Không có thảo luận liên quan đến các tập tin, vì nó không liên quan và phụ thuộc vào những gì lớp học phải làm.

Liên quan đến giới hạn 80 ký tự trên mỗi dòng - đây là một sự trở lại với thời của thẻ đục lỗ. Phải nói rằng, khi các dòng phát triển quá dài, khả năng đọc bị ảnh hưởng.

Độ dài tệp và dòng là các phép đo tác động thứ cấp của độ phức tạp và do đó rất khác nhau. Những gì bạn nên nhắm đến là mã mà không phức tạp không cần thiết, không phải là số lượng dòng tối đa nhất định.

Các tệp dài có xu hướng chỉ ra rằng các phương thức, chương trình con hoặc các lớp quá phức tạp (làm quá nhiều thứ, không đủ yếu tố, v.v.)

Các dòng dài có xu hướng chỉ ra rằng các biểu thức quá phức tạp.

Chúng là những mùi chỉ ra một vấn đề mã tiềm năng, không được xác định rõ số liệu mục tiêu.

Độ dài của dòng phải sao cho bạn không phải cuộn màn hình để xem toàn bộ dòng. Điều đó phụ thuộc vào kích thước màn hình và độ phân giải.

Phương pháp và chức năng là tốt nhất nếu có thể vừa với một màn hình.

Các tập tin không nên quá dài. Tốt nhất là các tệp ngắn, nơi dễ hiểu lớp và thực hiện.
Khi tôi làm việc trong một dự án có tệp 10 klines. Nó giống như đọc một cuốn sách rất phức tạp. Tôi có cần cho biết có bao nhiêu vấn đề mà việc thực hiện gây ra không?

80 ký tự!

Tôi nhớ rằng tôi đã từng xem các tệp mã nguồn cho các chương trình thanh toán khoảng 80 trang trở lên khi tôi thực hiện COBOL. Tất nhiên, tôi không thể thấy rằng đây là thực tế phổ biến nhưng 80 ký tự cũng vô lý như nhau.

Từ chế độ xem kích thước lớp, nếu bạn cố gắng áp dụng đề xuất này trên một lớp Khách hàng điển hình có khoảng 80 thuộc tính và 20 phương thức hoặc hơn, bạn sẽ phải chia lớp thành nhiều lớp khác và thực sự làm cho mã rất lộn xộn.

Tôi cố gắng giữ các lớp và phương thức ngắn, nhưng đừng quá lo lắng về độ dài dòng. Trong những ngày của màn hình rộng và số nhận dạng dài, tôi nghĩ rằng tám mươi nhân vật là quá ít. Phải mất một số công việc để phá vỡ các câu lệnh để chúng dễ đọc và với giới hạn tám mươi ký tự, nó xảy ra khá thường xuyên. Tôi nghĩ khoảng 120 hoặc 130 cột trên mỗi dòng là hợp lý hơn.