Có một lý do hợp lệ để thực thi độ rộng tối đa 80 ký tự trong một tệp mã, ngày và tuổi này không? [đóng cửa]

Nghiêm túc. Trên màn hình 22 ", nó chỉ bao gồm một phần tư màn hình. Tôi cần một số đạn để loại bỏ quy tắc này.

Tôi không nói rằng không nên có giới hạn; Tôi chỉ nói rằng, 80 ký tự là rất nhỏ.

Tôi nghĩ rằng việc giữ mã đến 80 (hoặc 79) cột ban đầu được tạo ra để hỗ trợ mọi người chỉnh sửa mã trên các thiết bị đầu cuối câm 80 cột hoặc trên các bản in 80 cột. Những yêu cầu đó hầu hết đã biến mất ngay bây giờ, nhưng vẫn còn những lý do hợp lệ để giữ nguyên tắc cột 80:

• Để tránh gói khi sao chép mã vào email, trang web và sách.
• Để xem nhiều cửa sổ nguồn cạnh nhau hoặc sử dụng trình xem khác biệt cạnh nhau.
• Để cải thiện khả năng đọc. Mã hẹp có thể được đọc nhanh mà không cần phải quét mắt từ bên này sang bên kia.

Tôi nghĩ rằng điểm cuối cùng là quan trọng nhất. Mặc dù màn hình đã tăng kích thước và độ phân giải trong vài năm qua, nhưng đôi mắt thì không .

Nguồn gốc của định dạng văn bản 80 cột sớm hơn các thiết bị đầu cuối 80 cột - thẻ đục lỗ của IBM có từ năm 1928 ! Điều này gợi nhớ đến câu chuyện (ngày tận thế) rằng thước đo đường sắt Hoa Kỳ được xác định bởi chiều rộng của bánh xe ngựa ở Anh.

Đôi khi tôi thấy nó hơi hạn chế, nhưng nó có ý nghĩa để có một số giới hạn tiêu chuẩn, vì vậy nó là 80 cột.

Đây là cùng một chủ đề được bảo hiểm bởi Slashdot .

Và đây là một Tuyên bố Fortran của trường học cũ:

80 ký tự là một giới hạn vô lý những ngày này. Chia dòng mã của bạn ở nơi có ý nghĩa, không theo bất kỳ giới hạn ký tự tùy ý.

Bạn chỉ nên làm điều đó vì lợi ích của tất cả những người không có màn hình rộng 22 inch. Cá nhân, tôi làm việc trên màn hình 17 inch 4: 3 và tôi thấy nó đủ rộng. Tuy nhiên, tôi cũng có 3 màn hình đó, vì vậy tôi vẫn có nhiều không gian màn hình có thể sử dụng được.

Không chỉ vậy, mắt người thực sự có vấn đề khi đọc văn bản nếu các dòng quá dài. Thật quá dễ dàng để bị lạc trong dòng bạn đang đi. Các tờ báo có chiều dài 17 inch (hoặc đôi khi như vậy), nhưng bạn không thấy chúng viết trên khắp trang, tương tự như vậy đối với các tạp chí và các mục in khác. Nó thực sự dễ đọc hơn nếu bạn giữ các cột hẹp.

Khi bạn có một chuỗi các câu lệnh lặp lại với các biến thể nhỏ, có thể dễ dàng thấy các điểm tương đồng và khác biệt nếu chúng được nhóm thành các dòng sao cho sự khác biệt được sắp xếp theo chiều dọc.

Tôi cho rằng những điều sau đây dễ đọc hơn nhiều so với nếu tôi chia nó thành nhiều dòng:

switch(Type) {
case External_BL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_BR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_TR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case External_TL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_TR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case Internal_TL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
}

Cập nhật: Trong nhận xét, có ý kiến ​​cho rằng đây sẽ là cách thực hiện ngắn gọn hơn:

switch(Type) {
  case External_BL: dxDir = - 1; dyDir = - 1; break;
  case External_BR: dxDir = + 1; dyDir = - 1; break;
  case External_TR: dxDir = + 1; dyDir = + 1; break;
  case External_TL: dxDir = - 1; dyDir = + 1; break;
  case Internal_BL: dxDir = + 1; dyDir = + 1; break;
  case Internal_BR: dxDir = - 1; dyDir = + 1; break;
  case Internal_TR: dxDir = - 1; dyDir = - 1; break;
  case Internal_TL: dxDir = + 1; dyDir = - 1; break;
}
mpstrd["X"] = pt1.x + dxDir * RadialClrX;
mpstrd["Y"] = pt1.y + dyDir * RadialClrY; 

mặc dù bây giờ nó phù hợp với 80 cột nhưng tôi nghĩ quan điểm của tôi vẫn đứng vững và tôi chỉ chọn một ví dụ tồi. Nó vẫn chứng minh rằng việc đặt nhiều câu lệnh trên một dòng có thể cải thiện khả năng đọc.

In một phông chữ đơn cách ở kích thước mặc định là (trên giấy A4) 80 cột bằng 66 dòng.

Tôi sử dụng lợi thế của màn hình lớn hơn để có nhiều đoạn mã bên cạnh nhau.

Bạn sẽ không nhận được bất kỳ đạn từ tôi. Trên thực tế, tôi ghét phải thấy nó thay đổi vì trong trường hợp khẩn cấp tôi vẫn thấy những trường hợp hiếm hoi khi tôi cần thay đổi mã từ bảng điều khiển văn bản.

Những dòng siêu dài khó đọc hơn. Chỉ vì bạn có thể nhận được 300 ký tự trên màn hình không có nghĩa là bạn nên tạo các dòng dài. 300 ký tự cũng quá phức tạp đối với một câu lệnh trừ khi bạn không có lựa chọn nào (một cuộc gọi cần cả đống tham số.)

Tôi sử dụng 80 ký tự làm quy tắc chung nhưng tôi sẽ vượt xa điều đó nếu thực thi nó có nghĩa là đặt ngắt dòng ở một vị trí không mong muốn.

Điều duy nhất tôi thi hành để ở trong vòng 80 ký tự là nhận xét của tôi.

Cá nhân ... Tôi dành toàn bộ sức mạnh não bộ của mình (có rất ít) để mã hóa đúng, thật đau đớn khi phải quay lại và phá vỡ mọi thứ ở giới hạn 80 char khi tôi có thể dành thời gian cho chức năng tiếp theo . Vâng, Resharper có thể làm điều đó cho tôi, tôi cho rằng nhưng sau đó nó làm tôi bối rối một chút rằng một sản phẩm của bên thứ 3 đang đưa ra quyết định về bố cục mã của tôi và thay đổi nó ("Làm ơn đừng chia mã của tôi thành hai dòng HAL. HAL?" ).

Điều đó nói rằng, tôi làm việc trong một nhóm khá nhỏ và tất cả các màn hình của chúng tôi đều khá lớn nên đáng lo ngại về những gì làm phiền các lập trình viên đồng nghiệp của tôi không phải là mối quan tâm lớn cho đến nay.

Có vẻ như một số ngôn ngữ khuyến khích các dòng mã dài hơn vì lợi ích lớn hơn cho buck (tay ngắn nếu sau đó tuyên bố).

Tôi có hai màn hình 20 "1600x1200 và tôi dính vào 80 cột vì nó cho phép tôi hiển thị nhiều cửa sổ soạn thảo văn bản cạnh nhau. Sử dụng phông chữ '6x13' (phông chữ xterm) 80 cột chiếm 480 pixel cộng với thanh cuộn và viền cửa sổ. Điều này cho phép một người có ba cửa sổ loại này trên màn hình 1600x1200. Trên cửa sổ, phông chữ Lucida Console sẽ không làm được điều này (kích thước tối thiểu có thể sử dụng là 7 pixel) nhưng màn hình 1280x1024 sẽ hiển thị hai cột và một màn hình 1920x1200 như HP LP2465 sẽ hiển thị 3. Nó cũng sẽ chừa lại một chút chỗ cho các nhà thám hiểm, tài sản và các cửa sổ khác từ Visual Studio.

Ngoài ra các dòng văn bản rất dài rất khó đọc. Đối với văn bản tối ưu là 66 ký tự. Có một điểm mà các định danh quá dài bắt đầu phản tác dụng vì chúng làm cho việc trình bày mã không mạch lạc. Bố cục và thụt lề tốt cung cấp tín hiệu trực quan về cấu trúc mã và một số ngôn ngữ (Python xuất hiện trong tâm trí) sử dụng thụt lề rõ ràng cho việc này.

Tuy nhiên, các thư viện lớp tiêu chuẩn cho Java và .Net có xu hướng ưu tiên các mã định danh rất dài nên người ta không nhất thiết phải đảm bảo có thể làm điều này. Trong trường hợp này, việc đặt mã với ngắt dòng vẫn giúp cấu trúc rõ ràng.

Lưu ý rằng bạn có thể nhận các phiên bản windows của phông chữ '6x13' tại đây .

Mọi người nói dòng mã dài có xu hướng phức tạp. Hãy xem xét một lớp Java đơn giản:

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

Nó dài 94 ký tự và tên lớp khá ngắn (theo tiêu chuẩn GWT). Sẽ rất khó để đọc trên 2 dòng và nó rất dễ đọc trên một dòng. Thực dụng về nó và do đó cho phép "tương thích ngược", tôi muốn nói 100 ký tự là chiều rộng phù hợp.

Các câu trả lời khác đã tóm tắt mọi thứ rất hay, nhưng cũng đáng để xem xét khi bạn có thể muốn sao chép và dán một số mã vào email hoặc nếu không mã thì khác.

Đó là thời gian khi có "chiều rộng tối đa" là hữu ích.

Bạn không phải là người duy nhất sẽ duy trì mã của bạn.

Người tiếp theo có thể có màn hình 17 "hoặc có thể cần phông chữ lớn để đọc văn bản. Giới hạn phải ở đâu đó và 80 ký tự là quy ước do giới hạn màn hình trước đó. Bạn có thể nghĩ về bất kỳ tiêu chuẩn mới nào (120) và Tại sao nên sử dụng cái kia thì "đó là thứ phù hợp với màn hình của tôi ở phông chữ Xpt?"

Hãy nhớ rằng, luôn có ngoại lệ cho mọi quy tắc để bạn có một dòng hoặc khối mã cụ thể có ý nghĩa là hơn 80 ký tự sau đó là một kẻ nổi loạn.

Nhưng hãy dành thời gian đầu tiên để suy nghĩ "mã này có thực sự tệ đến mức nó không thể sống trong vòng 80 ký tự không?"

Trong tiêu chuẩn mã hóa Linux, họ không chỉ giữ giới hạn 80 ký tự mà còn sử dụng 8 ký tự không gian.

Một phần lý do là nếu bạn đạt được lề phải, bạn nên xem xét chuyển mức thụt vào một hàm riêng biệt.

Điều này sẽ làm cho mã rõ ràng hơn bởi vì bất kể độ dài thụt đầu dòng, khó đọc mã hơn với nhiều cấu trúc điều khiển lồng nhau.

Tôi đã mở rộng mã của mình lên 100 ký tự, vừa vặn với chưa đến một nửa màn hình trên Macbook của tôi. 120 ký tự có lẽ là giới hạn trước khi các dòng bắt đầu quá dài và phức tạp. Bạn không muốn quá rộng, bạn khuyến khích các câu lệnh ghép và các cấu trúc điều khiển lồng nhau sâu sắc.

Lề phải là cách tự nhiên để bảo bạn thực hiện tái cấu trúc phương thức bổ sung .

Tôi tự hỏi nếu điều này có thể gây ra nhiều vấn đề trong thời đại ngày nay. Hãy nhớ rằng trong C (và có thể các ngôn ngữ khác) có các quy tắc về thời gian tên hàm có thể kéo dài bao lâu. Do đó, bạn thường thấy những cái tên rất khó hiểu trong mã C. Điều tốt là họ không sử dụng nhiều không gian. Nhưng mỗi khi tôi xem mã bằng một số ngôn ngữ như C # hoặc Java, các tên phương thức thường rất dài, khiến cho mã gần như không thể giữ mã của bạn ở độ dài 80 ký tự. Tôi không nghĩ 80 ký tự là hợp lệ ngày hôm nay, trừ khi bạn cần có thể in mã, v.v.

Là tác giả của hướng dẫn mã hóa cho chủ nhân của tôi, tôi đã tăng chiều dài dòng từ 80 lên 132. Tại sao giá trị này? Vâng, như những người khác đã chỉ ra, 80 là chiều dài của nhiều thiết bị đầu cuối phần cứng cũ. Và 132 cũng vậy! Đó là chiều rộng đường khi các thiết bị đầu cuối ở chế độ rộng . Bất kỳ máy in nào cũng có thể tạo các bản cứng ở chế độ rộng với phông chữ cô đọng.

Lý do không ở lại 80 là tôi

• thích tên dài hơn với ý nghĩa cho định danh
• không bận tâm với typedefs cho structs và enums trong C (chúng là BAD, chúng ẩn thông tin hữu ích! Hãy hỏi Peter van der Linden trong "Deep C Secrets" nếu bạn không tin), vì vậy mã này có nhiều struct FOO func(struct BAR *aWhatever, ...)hơn mã của những kẻ cuồng tín typedef .

và theo các quy tắc này, chỉ 80 ký tự / dòng gây ra các dòng xấu xí thường xuyên hơn mắt tôi cho là chấp nhận được (chủ yếu là trong các nguyên mẫu và định nghĩa hàm).

Như những người khác đã nói, tôi nghĩ tốt nhất là cho (1) in và (2) hiển thị nhiều tệp cạnh nhau theo chiều dọc.

Tôi muốn giới hạn chiều rộng của mình ở mức 100 ký tự hoặc hơn để cho phép hai trình soạn thảo SxS trên màn hình màn hình rộng. Tôi không nghĩ rằng có bất kỳ lý do chính đáng nào cho giới hạn chính xác là 80 ký tự nữa.

Sử dụng phông chữ tỷ lệ.

Tôi nghiêm túc đấy Tôi thường có thể nhận được tương đương 100-120 ký tự trong một dòng mà không làm mất khả năng đọc hoặc in. Trong thực tế, nó thậm chí còn dễ đọc hơn với một phông chữ tốt (ví dụ: Verdana) và tô màu cú pháp. Nó trông hơi lạ trong vài ngày, nhưng bạn nhanh chóng quen với nó.

Tôi cố gắng giữ mọi thứ gần 80 ký tự vì một lý do đơn giản: quá nhiều hơn điều đó có nghĩa là mã của tôi đang trở nên quá phức tạp. Tên thuộc tính / phương thức quá dài, tên lớp, v.v ... gây ra nhiều tác hại như tên terse.

Tôi chủ yếu là một lập trình viên Python, vì vậy điều này tạo ra hai bộ hạn chế:

1. Đừng viết những dòng mã dài
2. Đừng thụt quá nhiều

Khi bạn bắt đầu đạt đến hai hoặc ba cấp độ thụt, logic của bạn sẽ bị lẫn lộn. Nếu bạn không thể giữ một khối duy nhất trên cùng một trang, mã của bạn sẽ trở nên quá phức tạp và khó nhớ. Nếu bạn không thể giữ một dòng trong vòng 80 ký tự, thì dòng của bạn đang trở nên quá phức tạp.

Python dễ dàng viết mã tương đối súc tích (xem codegolf) với chi phí dễ đọc, nhưng viết mã dài dòng thậm chí còn dễ hơn với chi phí dễ đọc. Các phương thức của trình trợ giúp không phải là một điều xấu, cũng không phải là các lớp của trình trợ giúp. Sự trừu tượng quá mức có thể là một vấn đề, nhưng đó là một thách thức khác của lập trình.

Khi nghi ngờ trong một ngôn ngữ như C, hãy viết các hàm trợ giúp và nội tuyến chúng nếu bạn không muốn gọi ra một chức năng khác và nhảy trở lại. Trong hầu hết các trường hợp, trình biên dịch sẽ xử lý mọi thứ một cách thông minh cho bạn.

Đã có rất nhiều câu trả lời hay cho vấn đề này, nhưng điều đáng nói là trong IDE của bạn, bạn có thể có một danh sách các tệp ở bên trái và một danh sách các chức năng ở bên phải (hoặc bất kỳ cấu hình nào khác).

Mã của bạn chỉ là một phần của môi trường.

Tôi không thực thi 80 ký tự có nghĩa là cuối cùng từ gói.
IMO, bất kỳ độ dài nào được chọn cho một dòng có độ rộng tối đa không phải lúc nào cũng phù hợp và gói từ phải là một câu trả lời có thể.
Và điều đó không dễ dàng như âm thanh.

Nó được triển khai trong jedit _{(nguồn: jedit.org )} cung cấp gói từ

Nhưng nó bị bỏ lỡ một cách cay đắng trong nhật thực từ một thời gian ngắn ! (kể từ năm 2003 trên thực tế), chủ yếu là vì một gói từ cho trình soạn thảo văn bản bao gồm:

• Thông tin dòng được gói là dành cho trình xem văn bản, điều hướng mã, thước kẻ dọc.
• Thông tin dòng chưa được yêu cầu là cần thiết cho các chức năng như dòng goto, cột thước kẻ đánh số dòng, tô sáng dòng hiện tại, lưu tệp.

Tôi thực sự tuân theo một quy tắc tương tự cho mã của riêng tôi nhưng chỉ vì in mã sang trang A4 - 80 cột có chiều rộng phù hợp với kích thước phông chữ mong muốn của tôi.

Nhưng đó là sở thích cá nhân và có lẽ không phải là những gì bạn đã theo đuổi (vì bạn muốn đạn đi theo con đường khác).

Bạn không thắc mắc lý do đằng sau giới hạn - nghiêm túc, nếu không ai có thể đưa ra lý do chính đáng tại sao lại như vậy, bạn có một trường hợp tốt để loại bỏ nó khỏi các tiêu chuẩn mã hóa của bạn.

Tôi đứng cạnh nhau cả ngày và tôi không có màn hình 22 inch kỳ dị. Tôi không biết nếu tôi sẽ làm. Điều này, tất nhiên, ít được quan tâm đối với các lập trình viên chỉ viết thích mã hóa mũi tên và dòng 300 ký tự.

Có, bởi vì ngay cả trong thời đại ngày nay, một số người trong chúng ta đang mã hóa trên các thiết bị đầu cuối (ok, chủ yếu là trình giả lập thiết bị đầu cuối), trong đó màn hình chỉ có thể hiển thị 80 ký tự. Vì vậy, ít nhất là đối với mã hóa tôi làm, tôi thực sự đánh giá cao quy tắc 80 char.

Tôi vẫn nghĩ rằng giới hạn không bị giới hạn ở phần hình ảnh. Chắc chắn, màn hình và độ phân giải đủ lớn để hiển thị nhiều ký tự hơn trong một dòng hiện nay, nhưng nó có làm tăng khả năng đọc không?

Nếu giới hạn thực sự được thực thi, đó cũng là một lý do tốt để suy nghĩ lại mã và không đặt mọi thứ vào một dòng. Điều này cũng tương tự với thụt lề - nếu bạn cần nhiều cấp độ, mã của bạn cần phải được suy nghĩ lại.

Phá vỡ ở 80 ký tự là điều bạn làm trong khi mã hóa, không phải sau đó. Tương tự với ý kiến, tất nhiên. Hầu hết các biên tập viên có thể hỗ trợ bạn trong việc xem giới hạn 80 ký tự ở đâu.

(Đây có thể là một chút OT, nhưng trong Eclipse có một tùy chọn định dạng mã khi bạn lưu nó (theo bất kỳ quy tắc nào bạn muốn). Lúc đầu, điều này hơi kỳ cục, nhưng sau một thời gian bạn bắt đầu chấp nhận rằng định dạng không còn trong tay bạn hơn mã được tạo.)

Nếu chúng ta có một trong số này , chúng ta sẽ không có cuộc thảo luận này! ;-)

Nhưng nghiêm túc những vấn đề mà mọi người nêu ra trong câu trả lời của họ là khá chính đáng. Tuy nhiên, áp phích ban đầu không tranh cãi về giới hạn, chỉ có 80 cột là quá ít.

Vấn đề gửi đoạn mã email có một số giá trị. Nhưng xem xét những điều xấu xa mà hầu hết các khách hàng email làm đối với văn bản được định dạng trước tôi nghĩ rằng việc gói dòng chỉ là một trong những vấn đề của bạn.

Đối với in ấn tôi thường thấy rằng 100 dòng ký tự sẽ rất thoải mái phù hợp với một trang in.

Tôi cố gắng và giữ các dòng của tôi dưới 80 cột. Lý do mạnh nhất là tôi thường thấy mình sử dụng grepvà lessduyệt mã khi làm việc tại dòng lệnh. Tôi thực sự không thích cách các thiết bị đầu cuối phá vỡ các dòng nguồn dài (cuối cùng chúng không được tạo ra cho công việc đó). Một lý do khác là tôi thấy nó có vẻ tốt hơn nếu mọi thứ phù hợp với dòng và không bị phá vỡ bởi trình chỉnh sửa. Ví dụ, có các tham số của hàm gọi dài được sắp xếp độc đáo bên dưới nhau và các công cụ tương tự.