Vâng, phải không? Có được coi là thực hành xấu?

IMO, nó ít đọc hơn. Tôi ghét phải di chuyển sang phải, sau đó quay lại trái, phải, trái, và như vậy. Nó làm cho mã hóa đau đớn hơn và đôi khi làm tôi bối rối.

Ví dụ, bất cứ khi nào tôi mã hóa một chuỗi dài, tôi sẽ làm như sau ...

bigLongSqlStatement = "select * from sometable st inner join anothertable at" +
"on st.id = at.id" +
"and so on..." +
"and so on..." +
"and so on..."

Vâng, thực sự nó làm, theo nghĩa đen cũng như ý nghĩa chung.

Tôi thích làm khác biệt mã bên cạnh, và các dòng quá rộng làm cho điều đó khó hơn:

Các ngôn ngữ như Scala với chuỗi ba trích dẫn cho phép bạn xây dựng một chuỗi từ nhiều dòng mà không phải trả chi phí thời gian chạy, trích dẫn khó coi và dấu cộng (như trong ví dụ của bạn) về việc nối các phần của chuỗi.

Có, tôi nghĩ 80 ký tự trên mỗi dòng là hợp lý và thường được sử dụng.

Đó là một câu hỏi thực sự quan trọng với tôi! Tôi đã làm việc 7 tháng trên máy tính xách tay 13 "với các đồng nghiệp có màn hình máy tính để bàn 24" và tôi thấy mình đã dành nhiều thời gian để rút ngắn thời gian để kết thúc với thứ gì đó có thể đọc được.

80 cột hơi nhỏ trong nhiều trường hợp (trừ khi bạn đang làm việc trên một thiết bị đầu cuối với vi tùy chọn duy nhất;)), nhưng hơn ~ 150 là quá nhiều (xem bên dưới).

Đó là câu hỏi 'dễ đọc' thuần túy.

Bây giờ, đối với phần 'thực hành tốt', tôi rất thường thấy các dòng dài như vậy là thiếu sót, tức là có một phần nên được trích xuất trong một biến tạm thời, hoặc được sao chép, ví dụ (ObjectiveC, đoạn trích phổ biến trong lập trình iPhone) :

CGPoint point = CGPointMake(someOtherView.frame.origin.x + someOtherView.frame.size.width, someOtherView.frame.origin.x + someOtherView.frame.size.height);

Xin lưu ý rằng điều này có thể trở nên thậm chí còn khó khăn hơn khi làm việc với các vectơ 3 chiều hoặc ma trận.

Ví dụ viết lại:

CGRect frame = someOtherView.frame;
CGPoint origin = frame.origin;
CGSize size = frame.size;
CGPoint point = CGPointMake(origin.x + size.width, origin.x + size.height);

Điều này hiện đang phù hợp trên một màn hình nhỏ hơn, dễ dàng gỡ lỗi hơn bằng cách sử dụng IDE hoặc một số ghi vào đầu ra tiêu chuẩn và thậm chí có thể nhanh hơn, tùy thuộc vào chi phí của yêu cầu phương thức / thuộc tính. Tất nhiên đây là một chút gượng ép, hầu hết các ví dụ trong thế giới thực phức tạp hơn nhiều ...

Không phải lúc nào.

Chỉ cần thêm một chế độ xem khác, khi tôi đọc mã, tôi thường có thể nhận được ý chính về dòng mã đang làm mà không phải đọc toàn bộ dòng. Nếu tôi có thể đọc tên phương thức nhưng các tham số phương thức tràn ra khỏi màn hình, thông thường tôi không bị làm phiền vì tôi chỉ có thể nói từ tên phương thức đó là ý định của dòng mã đó là gì. Nếu một vài dòng mã tràn ra khỏi màn hình thì tôi nghĩ việc đánh đổi việc thỉnh thoảng (từ quan trọng ở đó) cuộn theo chiều ngang là đáng giá cho mã nhỏ gọn hơn. Đôi khi tôi thấy mã đơn dòng nhiều dòng gây mất tập trung khi tôi phải ghép lại một cách tinh thần mã nào đi với câu lệnh nào.

Thông thường, các dòng mã tràn theo chiều ngang có các bit quan trọng của chúng ở bên trái (hiển thị) và các bit ít quan trọng hơn ở bên phải (ngoài màn hình), do đó, đối với tôi, điều này giúp tăng cường khả năng đọc khi tôi có thể quét mã xuống các bit quan trọng trên mỗi dòng trái ngược với cách thay thế là có các bit mã ít quan trọng hơn từ một dòng quá dài chiếm không gian bên trái quan trọng trực quan trên (các) dòng sau.

Đã nói tất cả những điều đó, tôi chắc chắn sẽ không muốn cuộn theo chiều ngang rất thường xuyên, nhưng tôi thấy vấn đề này ít xảy ra hơn trong những ngày theo dõi màn hình rộng này.

Vâng, nó làm.

Ngẫu nhiên là một mẹo. Nếu bạn đang sử dụng một ngôn ngữ có chuỗi nhiều dòng (hầu như tất cả các ngôn ngữ tập lệnh đều có chúng) và bao gồm cả SQL dài, thì việc đặt SQL vào một chuỗi nhiều dòng có thể sử dụng các quy tắc định dạng nhất quán cho SQL. Xem http://bentilly.blogspot.com/2011/02/sql-formatted-style.html để biết phong cách định dạng mà tôi sử dụng.

Không, nó không.

Tôi có một biên tập viên. Nó không chỉ có đường bao bọc, nó còn thụt dòng bọc , mà (nếu màn hình nói rộng 100 ký tự) sẽ gây ra

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

xuất hiện như

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut 
    labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco 
    laboris nisi ut aliquip ex ea commodo consequat.

hoặc với bất kỳ mức độ thụt đầu dòng nào được đặt làm mặc định cho ngôn ngữ hiện tại.

Các dòng rộng hơn màn hình của tôi không bao giờ làm cho mã ít dễ đọc hơn so với mã được thụt dòng theo cách thủ công.

chỉnh sửa: ooooh, tôi biết câu trả lời này sẽ không phổ biến :)

Chắc chắn là có. Có một lý do báo và tạp chí sử dụng cột. Khả năng đọc là một yếu tố quan trọng. Khi đọc mắt chúng ta quét xuống với chuyển động tương đối ít. Hiệu quả là cho phép mắt chúng ta quét những gì chúng ta đang đọc một cách nhanh chóng.

Ngay cả khi nhìn thấy trên các cột rộng màn hình buộc mắt chúng ta phải quét qua lại nhanh chóng. Trong khi quét lại, chúng tôi không thực sự hiểu bất cứ điều gì. Điều này sẽ làm chậm đáng kể việc đọc và hiểu. Hiệu quả tương tự như máy in cơ cũ. Những điều này thường yêu cầu một số ký tự null được chèn sau khi quay trở lại vận chuyển để cho phép thời gian vận chuyển hoặc đầu in để định vị lại cho dòng tiếp theo.

Ngoài ra, bố cục dọc thường được thực hiện theo cách để làm rõ việc nhóm các nội dung trên dòng. Điều này thường chỉ nên áp dụng cho các điều kiện logic ghép. Các công thức dài có thể được cấu trúc tốt hơn như một chuỗi các câu lệnh. (Trình tối ưu hóa sẽ khắc phục mọi chi phí phụ và một số trình tối ưu hóa sẽ từ bỏ hoặc hoạt động kém trên các công thức phức tạp.)

Các định danh có nhiều dấu chấm yêu cầu các dòng lớn biểu thị các kỹ thuật mã hóa cần được chỉnh sửa.

Bánh xe giúp dễ dàng di chuyển nhanh theo chiều dọc ... cuộn theo chiều ngang là quá đắt so với.

Tránh cuộn ngang.

~ Nguyên tắc tương tác với trải nghiệm người dùng Windows PG 112

Đúng.

Người Anh đọc từ trái sang phải dẫn đến cuộn liên tục = Không sinh sản

Vì lý do này, tôi luôn kích hoạt tính năng ngắt từ với glyphs dòng trực quan trong IDE của mình.