2011-10-27 21 views
15

Nghiên cứu thực nghiệm nói gì về khoảng trắng trong mã? Hãy để tôi cụ thể: Tôi đang nói về các nghiên cứu nhận thức so sánh cách mọi người nhanh chóng và hiệu quả có thể đọc và nắm bắt thông tin thị giác đi qua ở các định dạng khác nhau.Kết quả nghiên cứu thực nghiệm về không gian màu trắng (cho thiết kế ngôn ngữ và hướng dẫn về phong cách)?

Giả sử bạn đang thiết kế một ngôn ngữ máy tính mới và phải đưa ra một số quyết định ảnh hưởng đến cách mã nguồn trông. Hoặc bạn chỉ đơn giản là viết một hướng dẫn phong cách cho một ngôn ngữ mới và muốn đưa ra các khuyến nghị. Các chủ đề có liên quan có thể là kiểu định danh (snake_cased_identifiers so với camelCaseIdentifiers/PascalCaseIdentifiers), thụt lề ngang, kiểu tài liệu hoặc khoảng cách dọc.

Tôi cố tình hỏi câu hỏi này theo cách này để tránh các khuyến nghị như:

  • "nó không quan trọng (không biện minh cho yêu cầu bồi thường)"
  • "làm những gì cộng đồng đã khuyến cáo cho ngôn ngữ X. "

Tôi không muốn cuộc chiến tranh giữa những người hỗ trợ các cách tiếp cận khác nhau; thay vào đó, tôi muốn biết những gì nghiên cứu thử nghiệm phải nói về vấn đề này. (Và tôi không mong đợi bất kỳ nghiên cứu cụ thể nào cần phải hoàn toàn 'khách quan' hoặc 'trung lập'.)

Để tạo động lực 'squishier' cho câu hỏi này: Mọi người đánh giá cao khoảng trắng trong mã, khi đọc tài liệu và trong nghệ thuật (như nghe nhạc). Những lĩnh vực này đều đặt trọng tâm lớn vào tầm quan trọng của không gian.

Vì vậy, cảm ơn, tôi rất muốn nghe những gì các nghiên cứu phải nói. Để rõ ràng, tôi không loại trừ tầm quan trọng của phong cách và nghệ thuật - tôi thực sự hy vọng rằng sự khôn ngoan từ những thế giới này sẽ xuất hiện trong các nghiên cứu thực nghiệm.

Nói tóm lại, nếu bạn có thể, xin vui lòng liên lạc trên một hoặc nhiều điều sau đây:

  • ước biến đặt tên
  • thụt đầu dòng ngang
  • sự liên kết ngang (? Align dấu bằng trên nhiều dòng)
  • khoảng cách dọc
+0

WRT camelTheo vs snake_case, nó phụ thuộc vào độ nhạy của ngôn ngữ. Trong C bạn có thể 'thi hành' aCamelCasedFunction trong PHP acamelcasedfunction cũng sẽ hoạt động. Vì vậy, đối với các ngôn ngữ không phân biệt dạng chữ, việc sử dụng dấu gạch dưới có lẽ dễ đọc hơn trong thực tế. – Bink

Trả lời

8

Có hội nghị IEEE hàng năm có tiêu đề International Conference on Program Comprehension (ICPC) thường có các nghiên cứu thực nghiệm về hiểu chương trình. Thích hợp nhất mà tôi tìm thấy từ ba năm qua là:

  • An Eye Tracking Study on camelCase and under_score Identifier Styles "Trong khi kết quả cho thấy không có sự khác biệt về độ chính xác giữa hai phong cách, đối tượng nhận định danh theo kiểu gạch nhanh hơn."

  • To camelcase or under_score "Kết quả chỉ ra rằng vỏ lạc đà dẫn đến độ chính xác cao hơn trong tất cả các đối tượng bất kể đào tạo và những người được đào tạo về vỏ lạc đà có thể nhận dạng số nhận dạng trong kiểu vỏ lạc đà nhanh hơn số nhận dạng theo kiểu gạch dưới."

Ngoài các tài liệu nhận thức khoa học máy tính cụ thể, có những nghiên cứu về trực tuyến và siêu văn bản đọc:

  • [Chaparro, 2005] Đọc trực tuyến Văn bản với một diện nghèo: Liệu Hiệu suất Tệ hơn? Bởi Barbara S. Chaparro, A. Dawn Shaikh, & J. Ryan Baker, Bản tin khả dụng, Tập 7, Số phát hành 1, tháng 2 năm 2005.

  • [Lin, 2004] Đánh giá sự duy trì của người lớn tuổi trong siêu văn bản: tác động của phương tiện thuyết trình như một chức năng của cấu trúc liên kết văn bản của Dyi-Yih Michael Lin trong "Máy tính trong hành vi của con người", Tập 20, Số 4, tháng 7 năm 2004, Trang 491-503. Có sẵn từ ScienceDirect

  • Cognitive load in hypertext reading: A review bởi Diana DeStefano và Jo-Anne LeFevre.

Những giấy tờ này ít trực tiếp giải quyết câu hỏi, nhưng tôi đề cập đến chúng với hy vọng rằng chúng cung cấp một số ngữ cảnh. Hai tài liệu tham khảo đầu tiên được tìm thấy nhờ bài đăng trên blog của Michael Suodenjoki có tên là White space matters in program source code.

+1

Tốt cho ya để tìm một số tài liệu tham khảo. Bạn có thể có một đâm vào tóm tắt kết luận của họ? – blahdiblah

+0

Tôi đã thêm hai nghiên cứu nữa và trích dẫn kết quả của chúng ở trên. Từ những gì tôi có thể nói kết quả là hỗn hợp. –

7

Đây là một chủ đề rất chủ quan, nhưng bạn có thể lấy một số tín hiệu từ 1000 năm lịch sử typographic.

Nghiên cứu đã được thực hiện trên khoảng trắng trong kiểu chữ, nhưng ít hơn trên mã. Nhưng bạn có thể giả định nhiều phát hiện cơ bản về tính dễ đọc và hiểu cũng áp dụng cho mã. Nghiên cứu này, Reading Online Text: A Comparison of Four White Space Layouts, cho thấy khoảng cách dọc thích hợp với biên độ lớn tăng hiểu, nhưng làm chậm tốc độ. Đối với mã, nó có thể được giả định một cách an toàn rằng hiểu là quan trọng hơn tốc độ. Vì vậy, bạn có thể khách quan nói, không gian nhiều hơn là tốt hơn cho mã. Nhưng khi bạn nhận được vào chi tiết cụ thể của kích thước tab và định vị cú đúp nó được đánh giá cao chủ quan. Trong mã, lề là thụt đầu dòng, các đoạn là các hàm và khối mã, và dấu chấm là dấu ngắt dòng, dấu ngoặc ôm, dấu ngoặc đơn, v.v.

Khi bạn bắt đầu yêu cầu lập trình viên định dạng khoảng trắng nào dễ đọc hơn, phổ. Điều tốt nhất bạn có thể làm là tìm kiếm những điểm chung có vẻ là phổ quát.

Chẳng hạn như:

  • đặt khoảng trắng trước và sau khi khối mã, như chức năng và các lớp
  • đặt khoảng trắng trước và sau khi nhóm logic của mã trong khối
  • khối dài mã không có dọc khoảng trắng khó đọc hơn
  • các khối mã dài không có thụt đầu dòng khó đọc hơn
  • các dòng mã dài không có dấu cách ngang khó đọc

Tôi nghĩ hầu hết các lập trình viên sẽ đồng ý với những tuyên bố đó.

Ví dụ (pseudo-code):

thisismore(difficult<toread)because,itsall-smushed{together} 
this-is-less (difficult < to-read) because, it's-not-all - smushed { together } 

Để chạm vào bốn bạn điểm cuối cùng:

đặt tên biến:

Đây là tính chủ quan như khoảng trắng, nhưng một lần nữa, bạn có thể tìm đến typography cho manh mối. Typography có phông chữ serif, chữ in hoa bắt đầu câu, dấu chấm câu và dấu cách sau dấu chấm. Tất cả những điều này là để cho phép đôi mắt của bạn chuyển đổi giữa các từ và câu. Với các biến, sự rõ ràng là quan trọng, vì vậy chúng thường là các tên nhiều từ. Để đôi mắt của bạn dễ dàng đọc chúng, một cái gì đó cần phải cảnh báo họ rằng một từ mới đã bắt đầu.

Đây là khó khăn hơn để đọc (đối với hầu hết mọi người):

  • mylongvariablename

Thân này:

  • my-dài-biến-tên
  • myLongVariableName
  • my_long_variable_name
  • MY_LONG_VARIABLE_NAME

Bây giờ mà trong số đó là tốt nhất hoặc nhất có thể đọc được là chủ quan, và có thể lúc nào cũng được. Nhưng điều quan trọng là cái gì đó tách biệt các từ.

Thụt lề ngang:

Mã không thụt lề chút nào khó đọc hơn mã. Chấm lõm quá nhỏ và đôi mắt của bạn gặp khó khăn trong việc phân biệt các khối. Quá lớn và bạn lãng phí không gian và thêm không rõ ràng hơn. Một nơi nào đó giữa bốn và tám có vẻ là đúng dựa trên các dòng mã cao 70 bazillion được viết bằng các kích thước đó.

Căn chỉnh ngang:

Một lần nữa, kiểu chữ để giải cứu. Danh sách các thứ được căn chỉnh trong các cột dễ đọc hơn. Đối với dữ liệu mục danh sách dài hơn một hoặc hai từ hoặc số (như câu), danh sách dấu đầu dòng được sử dụng. Đối với dữ liệu văn bản, cột được căn trái được sử dụng. Đối với dữ liệu số, cột được căn phải được sử dụng. Bạn có thể áp dụng các hiệu trưởng này cho mã. Danh sách có dấu đầu dòng có thể được xem là các khối mã, tất cả đều được căn chỉnh với cùng một mức thụt đầu dòng. Các biến là dữ liệu văn bản, do đó việc căn trái sẽ dễ đọc nhất. Nếu các giá trị bạn chỉ định là số, căn chỉnh phải là tốt nhất.

Đây là khó khăn hơn để đọc (đối với hầu hết mọi người):

var oneVariable = 10023, a = 370, 
p = 4, 
answerToLife = 42, 
openThePodBayDoorHal = false; 

Thân này:

var oneVariable = 10023, 
    a = 370, 
    p = 4, 
    answerToLife = 42, 
    openThePodBayDoorHal = false; 

Và đây có lẽ là dễ nhất:

var oneVariable   = 10023, 
    a     = 370, 
    p     =  4, 
    answerToLife   = 42, 
    openThePodBayDoorHal = false; 

Vertical Spacing:

Im agine toàn bộ bài viết này không có khoảng cách giữa các đoạn văn. Hầu hết mọi người đều có thể đồng ý rằng sẽ khó đọc và dễ hiểu hơn. Bây giờ, nhiều người có thể lập luận rằng không gian nhiều hơn giữa các phần sẽ còn tốt hơn nữa. Trong kiểu chữ, các phần được mô tả với các tiêu đề có kích thước phông chữ lớn hơn và không gian dọc hơn (như bạn thấy trong HTML với H1, v.v.). Trong mã, chúng tôi có một cỡ chữ, vì vậy chúng tôi phải làm việc với khoảng trắng và bất kỳ khái niệm giằng nào mà ngôn ngữ sử dụng (nếu có). Giống như khoảng cách ngang, nhiều hơn là tốt hơn ít hơn. Cụ thể về chính xác những gì có nghĩa là chủ quan, nhưng với hầu hết các ngôn ngữ, lập trình viên giải quyết thành một quy ước cho ngôn ngữ mà hầu hết mọi người sử dụng. Nếu bạn định nghĩa ngôn ngữ của mình (hoặc chuẩn mã hóa), thì bạn có thể đặt quy ước.

Điều quan trọng nhất, không quan trọng tiêu chuẩn là gì, là nó được sử dụng nhất quán trong tất cả mã của bạn. Đây là cách quan trọng hơn các chi tiết cụ thể của tiêu chuẩn. Mã được định dạng nhất quán dễ dàng hơn nhiều bất kể tiêu chuẩn là gì.

Tìm kiếm typography readability studies để biết thêm thông tin.

+0

ThinkingStiff, cảm ơn câu trả lời chu đáo. Nó nói rất nhiều điều mà tôi nghĩ là khôn ngoan (và nhiều điều tôi đồng ý). Tuy nhiên, tôi không nghĩ rằng nó đang đào sâu vào nghiên cứu thực nghiệm - một khía cạnh quan trọng của câu hỏi của tôi. Tham chiếu đến nghiên cứu kiểu chữ rất hữu ích, tôi nghĩ rằng có nhiều nghiên cứu hơn dọc theo các dòng đó. –

Các vấn đề liên quan