Có bất kỳ nghiên cứu khoa học nghiêm ngặt về các nguyên tắc phong cách mã hóa? [đóng cửa]

Là một nguyên tắc phong cách mã hóa - ví dụ như nguyên tắc thoát đơn - thực sự là một điều tốt? Luôn luôn, hoặc chỉ đôi khi? Nó thực sự tạo ra bao nhiêu sự khác biệt?

Dù ý kiến ​​của bạn là gì, đây rõ ràng là những câu hỏi chủ quan. Hoặc là họ?

Có ai đã cố gắng thực hiện một nghiên cứu khoa học, nghiêm ngặt về các nguyên tắc phong cách mã hóa chưa?

Tôi không thể tưởng tượng làm thế nào bất cứ ai sẽ thực hiện một nghiên cứu mù đôi về khả năng đọc, nhưng có thể không biết gì về hai người - sử dụng những sinh viên không biết về nguyên tắc được nghiên cứu như các môn học và những người không lập trình để quản lý nghiên cứu.

Tôi đang lặp lại bình luận của deadalnix: đọc Code Complete 2 . Tác giả (Steve McConnell) thảo luận về phong cách mã hóa theo chiều sâu và thường xuyên tham khảo các bài báo và dữ liệu.

Tôi rất nghi ngờ về khả năng của một nghiên cứu về chủ đề mang lại kết quả khách quan và tôi sẽ vẫn hoài nghi cho đến khi tôi được hiển thị một số nghiên cứu thuyết phục.

Các lập trình viên đã dành nhiều năm để đọc và viết mã theo phong cách mã hóa nhất định rõ ràng sẽ thấy nó dễ đọc hơn một số phong cách mã hóa hoàn hảo mà họ sẽ thấy lần đầu tiên trong đời.

Nó hoàn toàn giống với cách bố trí gõ QWERTY phổ biến nhất - thật dễ dàng để chứng minh rằng nó khá tối ưu về mặt công thái học (bạn có nghĩ rằng tất cả các ký tự của từ TYPEWRITER đều được đặt ở hàng trên cùng với sự tiện lợi hàng ngày của chúng tôi không?) .

Nhưng các lựa chọn thay thế được cải thiện như Dvorak hoặc Colemak chưa bao giờ bắt kịp và khó có thể xảy ra. Và do đó mọi người không làm việc hiệu quả hơn với họ - thực tế. Ngay cả khi họ vượt trội trong một số ý nghĩa trừu tượng.

Ngoài ra, nó sẽ rất khó để tìm thấy các đối tượng không có tiếp xúc trước khi lập trình (vì điều này sẽ làm ô nhiễm các kết quả nghiên cứu của chúng tôi), NHƯNG một năng khiếu cho lập trình, và có ý muốn tham gia vào một nghiên cứu trong một thời gian đủ lâu để hiển thị cả ngắn lợi ích thời gian và lợi ích lâu dài để chúng có thể được cân đối với nhau ... (Tôi không biết liệu chúng có loại trừ lẫn nhau hay không, nhưng các nhà nghiên cứu không thể đơn giản cho rằng chúng không bao giờ tồn tại).

Câu trả lời là KHÔNG CÓ! Là `break` và` continue` thực hành lập trình xấu? là một tập hợp con của câu hỏi này, vì vậy tôi sẽ bắt đầu với một câu trả lời hầu như không được sửa đổi cho điều đó ...

Bạn có thể [viết lại] các chương trình mà không có câu lệnh break (hoặc trả về từ giữa các vòng lặp, điều này làm điều tương tự). Nhưng khi làm như vậy, bạn có thể phải giới thiệu các biến bổ sung và / hoặc sao chép mã cả hai điều này thường làm cho chương trình khó hiểu hơn. Pascal (ngôn ngữ lập trình cuối thập niên 1960) rất tệ, đặc biệt đối với những lập trình viên mới bắt đầu vì lý do đó.

Có một kết quả khoa học máy tính được gọi là hệ thống cấu trúc điều khiển của Kosaraju, xuất hiện từ năm 1973 và được đề cập trong bài viết nổi tiếng của Knuth (thêm) lập trình với các báo cáo từ năm 1974. Điều mà S. Rao Kosaraju đã chứng minh vào năm 1973 là nó không phải có thể viết lại tất cả các chương trình có độ sâu đa cấp độ sâu n thành các chương trình có độ sâu ngắt nhỏ hơn n mà không cần đưa ra các biến phụ. Nhưng hãy nói rằng đó chỉ là một kết quả lý thuyết đơn thuần. (Chỉ cần thêm một vài biến số?! Chắc chắn bạn có thể làm điều đó để cảm thấy tập hợp với người dùng 3K + trên stackexchange ...)

Điều quan trọng hơn nhiều từ góc độ công nghệ phần mềm là một bài báo gần đây hơn, năm 1995 của Eric S. Roberts có tiêu đề Loop Exits và Structured Program: Mở lại cuộc tranh luận (doi: 10.1145 / 199688.199815). Roberts tóm tắt một số nghiên cứu thực nghiệm được thực hiện bởi những người khác trước ông. Ví dụ, khi một nhóm sinh viên loại CS101 được yêu cầu viết mã cho một hàm thực hiện tìm kiếm tuần tự trong một mảng, tác giả của nghiên cứu đã nói như sau về những sinh viên đã sử dụng dấu ngắt / quay lại để thoát khỏi chuỗi liên tiếp vòng lặp tìm kiếm ngay khi tìm thấy phần tử:

Tôi vẫn chưa tìm thấy một người nào đã thử một chương trình sử dụng [kiểu này], người đã tạo ra một giải pháp không chính xác.

Roberts cũng nói rằng:

Những sinh viên đã cố gắng giải quyết vấn đề mà không sử dụng một kết quả rõ ràng từ vòng lặp for thì kém hơn rất nhiều: chỉ có bảy trong số 42 sinh viên cố gắng chiến lược này quản lý để tạo ra các giải pháp chính xác. Con số đó thể hiện tỷ lệ thành công dưới 20%.

Có, bạn có thể có nhiều kinh nghiệm hơn sinh viên CS101, nhưng không sử dụng câu lệnh break (hoặc trả lại / goto tương đương từ giữa các vòng lặp), cuối cùng bạn sẽ viết mã mà trong khi có cấu trúc độc đáo là đủ lông về mặt logic bổ sung các biến và sao chép mã mà ai đó, có thể là chính bạn, sẽ đặt các lỗi logic trong đó trong khi cố gắng làm theo một số ý tưởng tuyệt vời về phong cách mã hóa "chính xác".

Và có một vấn đề lớn hơn ở đây ngoài các câu lệnh return / break-type, vì vậy câu hỏi này rộng hơn một chút so với câu hỏi về break. Theo một số cơ chế xử lý ngoại lệ cũng vi phạm mô hình điểm thoát đơn

• http://msmvps.com/bloss/peterritchie/archive/2008/03/07/single-entry-single-exit-should-it-still-be-applossible-in-object-oriented-lacular.aspx
• http://pragprog.com/mag Magazine / 2012/04 / the-paticatic-default

Vì vậy, về cơ bản, bất cứ ai tranh luận ở trên rằng nguyên tắc thoát đơn lẻ vẫn còn hữu dụng ngày nay cũng đang tranh luận về mô hình xử lý ngoại lệ, trừ khi được sử dụng theo cách cực kỳ hạn chế được mô tả trong liên kết cuối cùng đó; những hướng dẫn đó về cơ bản hạn chế tất cả các ngoại lệ ra khỏi hàm để ném (), tức là không cho phép truyền ngoại lệ giữa các hàm. Thưởng thức Pascal mới của bạn với cú pháp giống như C ++.

Tôi thấy từ đâu mà khái niệm "chỉ một lần trở lại" đến từ đâu?rằng ý kiến ​​phổ biến trên trang web này trái ngược với những gì tôi đã đăng ở đây, vì vậy tôi hoàn toàn hiểu lý do tại sao tôi đã bỏ phiếu xuống, mặc dù tôi là câu trả lời đầu tiên ở đây để thực sự cung cấp một câu hỏi mà câu hỏi yêu cầu: một số thông tin về các bài kiểm tra khả năng sử dụng thực tế tập trung vào vấn đề thoát đơn. Tôi đoán tôi không nên để kiến ​​thức cản trở những định kiến, đặc biệt là trên một trang web chơi game. Tôi sẽ gắn bó với việc chỉnh sửa Wikipedia từ bây giờ. Ít nhất có thông tin từ các nguồn tốt được đánh giá cao và tuyên bố mơ hồ hoặc không chính xác giả vờ được hỗ trợ bởi các nguồn cuối cùng kiếm được lệnh cấm. Trên trang web này, hoàn toàn ngược lại xảy ra: ý kiến ​​không có căn cứ bởi sự thật chi phối. Tôi hoàn toàn mong đợi một mod sẽ xóa phần cuối cùng này, nhưng ít nhất anh chàng đó sẽ biết lý do tại sao bạn mất tôi mãi mãi với tư cách là người đóng góp ở đây.

http://dl.acm.org/cites.cfm?id=1241526

http://www.springerlink.com/content/n82qpt83n8735l7t/

http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=661092

[Câu hỏi của bạn dường như được trả lời bằng một từ duy nhất, "có". Tuy nhiên, tôi đã được cho biết rằng việc cung cấp các câu trả lời ngắn là "loại bỏ" câu hỏi. Nếu bạn cảm thấy tôi đã từ chối, vui lòng đánh dấu câu trả lời để người điều hành có thể xóa nó.]

Là nguyên tắc kiểu mã hóa - ví dụ: nguyên tắc thoát đơn

Những người vẫn quan tâm đến việc một lối thoát đơn hay nhiều lối thoát vẫn bị mắc kẹt vào cuối những năm 1960. Trước đó, một cuộc thảo luận như vậy rất quan trọng vì chúng ta còn ở giai đoạn sơ khai của lập trình viên có cấu trúc, và có khá nhiều trại tuyên bố rằng những phát hiện đằng sau Chương trình cấu trúc Bohm-Jacopini Định lý không thể áp dụng cho tất cả các cấu trúc lập trình.

Đó là một cái gì đó nên được giải quyết từ lâu. Vâng, nó đã được giải quyết (gần 4 thập kỷ là chính xác, trong cả Học viện và ngành công nghiệp), nhưng mọi người (những người hoàn toàn ủng hộ hoặc chống lại) đã không được chú ý.

Đối với phần còn lại của câu trả lời của tôi, tất cả đều tương đối (những gì không có trong phần mềm?):

• thực sự là một điều tốt?

Vâng. Hầu hết thời gian cho trường hợp chung, với sự cẩn thận cụ thể cho các trường hợp cạnh và cấu trúc lập trình ngôn ngữ cụ thể.

Luôn luôn, hoặc chỉ đôi khi?

Hầu hết thời gian.

Nó thực sự tạo ra bao nhiêu sự khác biệt?

Phụ thuộc.

Mã có thể đọc và mã không thể đọc được. Độ phức tạp tăng (mà chúng ta nên biết bây giờ làm tăng xác suất đưa ra lỗi) so với độ phức tạp đơn giản hơn (và ergo, xác suất lỗi nhỏ hơn.) Các ngôn ngữ có trình biên dịch không thêm trả về ngầm định (giả sử Pascal, Java hoặc C #) và các ngôn ngữ đó mặc định là int (C và C ++).

Cuối cùng, đó là một kỹ năng được mài giũa với người đàn ông / giờ đằng sau bàn phím. Đôi khi, có thể có nhiều câu lệnh trả về, như ở đây (trong một số mã giả Pascal):

function foo() : someType
  begin
  if( test1 == true )
  then
    return x;
  end
  doSomethignElseThatShouldnHappenIfTest1IsTrue();
  return somethingElse();
end;

Mục đích rất rõ ràng và thuật toán đủ nhỏ và không phức tạp đến mức nó không đảm bảo việc tạo ra một biến 'cờ' giữ giá trị trả về cuối cùng được sử dụng trong một điểm trả về duy nhất. Thuật toán có thể bị lỗi, nhưng cấu trúc của nó đủ đơn giản để nỗ lực phát hiện lỗi là (không có khả năng) là không đáng kể.

Đôi khi không phải (ở đây sử dụng mã giả giống như C):

switch(someVal)
{
case v1 : return x1;
case v2 : return x2:
case v3 : doSomething(); // fall-through
case v4: // fall-through
case v5: // fall-through
case v6: return someXthingie;
...
...
default:
   doSomething(); // no return statement yet
}

Ở đây, thuật toán không có cấu trúc đơn giản và câu lệnh chuyển đổi (kiểu C) cho phép các bước rơi qua mà có thể hoặc không được thực hiện một cách có chủ ý như một phần của thuật toán.

Có thể thuật toán là chính xác, nhưng viết kém.

Hoặc có thể, bởi các lực lượng bên ngoài vượt quá khả năng của lập trình viên, đây là đại diện thực tế (và chính xác) của một thuật toán cần thiết hợp pháp.

Có lẽ nó sai.

Để khám phá sự thật của bất kỳ điều này đòi hỏi nỗ lực hơn nhiều so với ví dụ trước. Và đây là điều tôi tin tưởng mạnh mẽ (nhớ rằng tôi không có nghiên cứu chính thức nào để sao lưu điều này):

Giả sử một đoạn mã được coi là chính xác:

1. Nhiều câu lệnh trả về làm tăng tính dễ đọc và đơn giản của đoạn mã như vậy, nếu đoạn mã biểu thị một thuật toán đơn giản với cấu trúc luồng đơn giản vốn có. Nói một cách đơn giản, tôi không có nghĩa là nhỏ bé, nhưng ý tôi là vốn có thể hiểu được hoặc tự chứng minh , điều đó không đòi hỏi nỗ lực đọc không tương xứng (cũng không khiến mọi người nôn mửa, nguyền rủa mẹ ai đó hoặc nuốt một viên đạn khi họ phải đọc nó. )

2. Một câu lệnh trả về duy nhất làm tăng tính dễ đọc và đơn giản của một đoạn mã như vậy nếu giá trị trả về được tính trong suốt quá trình thực thi thuật toán hoặc nếu các bước trong thuật toán chịu trách nhiệm tính toán nó có thể được nhóm lại với nhau tại một vị trí trong cấu trúc của thuật toán .

3. Một câu lệnh trả về duy nhất làm giảm tính dễ đọc và đơn giản của một đoạn mã như vậy nếu nó yêu cầu các phép gán cho một hoặc nhiều biến cờ, với các vị trí của các phép gán đó không được định vị thống nhất trong suốt thuật toán.

4. Nhiều câu lệnh trả về làm giảm tính dễ đọc và đơn giản của một đoạn mã như vậy nếu các câu lệnh trả lại không được phân phối đồng đều trên thuật toán và nếu chúng phân định các khối mã loại trừ lẫn nhau không đồng nhất về kích thước hoặc cấu trúc.

Điều này liên quan chặt chẽ đến sự phức tạp của một đoạn mã được đề cập. Và điều này đến lượt nó có liên quan đến các biện pháp phức tạp chu kỳ và halstead. Từ điều này, người ta có thể quan sát như sau:

Kích thước của chương trình con hoặc hàm càng lớn, cấu trúc luồng điều khiển bên trong của nó càng lớn và phức tạp hơn, và xác suất bạn sẽ phải đối mặt với một câu hỏi về việc nên sử dụng nhiều câu lệnh trả lại hay đơn.

Kết luận của việc này là: giữ cho các chức năng của bạn nhỏ làm một việc và chỉ một việc (và thực hiện tốt). Nếu chúng thể hiện các số liệu độ phức tạp nhỏ và chu kỳ trên danh nghĩa, không chỉ chúng bị ràng buộc là chính xác nhất và được thực hiện các nhiệm vụ có thể hiểu được, cấu trúc bên trong của chúng cũng sẽ tương đối rõ ràng.

Sau đó, và chỉ sau đó bạn có thể khá dễ dàng và không mất nhiều giấc ngủ, bạn có thể quyết định có nên sử dụng một lần trả lại và nhiều lần trả lại mà không gặp nhiều rủi ro khi đưa ra các lỗi với một trong hai lựa chọn hay không.

Người ta cũng có thể xem xét tất cả những điều này và đề nghị rằng khi mọi người đấu tranh với vấn đề trả lại một lần hoặc nhiều lần trả lại, đó là bởi vì - do thiếu kinh nghiệm, ngu ngốc hoặc thiếu đạo đức công việc - họ không viết mã sạch và có xu hướng viết chức năng quái dị với sự coi thường hoàn toàn các biện pháp chu kỳ và halstead.