Là số lỗi trung bình trên mỗi loc giống nhau cho các ngôn ngữ lập trình khác nhau? [đóng cửa]

Tôi đã được thông báo rằng số lỗi / lỗi trung bình trên mỗi dòng mã là "không đổi" đối với các ngôn ngữ lập trình khác nhau. 10 KLOC của Ruby sẽ có cùng số lỗi với 10 KLOC của c ++. Đối số thường được sử dụng để thúc đẩy việc sử dụng các ngôn ngữ biểu cảm (nghĩ python / ruby ​​trên c ++ / assembly) vì số lượng dòng để mô tả cùng chức năng sẽ nhỏ hơn.

Có ai biết yêu cầu này đến từ đâu không? Liệu các ngôn ngữ cấp cao hơn dẫn đến ít lỗi hơn?

Trái ngược với trực giác, số lượng lỗi trên 1000 dòng dường như tương đối ổn định, bất chấp ngôn ngữ cụ thể liên quan. Steve McConnell , tác giả của Code Complete và Ước tính phần mềm: Làm sáng tỏ nghệ thuật đen đi qua khu vực này một cách chi tiết.

Tôi không có sẵn các bản sao của mình - chúng đang ngồi trên giá sách của tôi tại nơi làm việc - nhưng Google nhanh chóng tìm thấy một trích dẫn có liên quan:

Trung bình ngành: "khoảng 15 - 50 lỗi trên 1000 dòng mã được gửi."
(Steve) tiếp tục nói rằng đây thường là đại diện của mã có một số cấp độ lập trình có cấu trúc đằng sau nó, nhưng có lẽ bao gồm một hỗn hợp các kỹ thuật mã hóa.

Trích dẫn từ Code Complete , được tìm thấy tại đây: http://mayerdan.com/ruby/2012/11/11/bugs-per-line-of-code-ratio/

Nếu bộ nhớ phục vụ chính xác, Steve sẽ thảo luận kỹ về điều này, cho thấy rằng các số liệu là không đổi giữa các ngôn ngữ (C, C ++, Java, hội, v.v.) và mặc dù gặp khó khăn (chẳng hạn như xác định "dòng mã" nghĩa là gì).

Quan trọng nhất là anh ta có rất nhiều trích dẫn cho các nguồn của mình - anh ta không đưa ra ý kiến ​​không có căn cứ, nhưng có các tài liệu tham khảo để sao lưu chúng.

Dường như hiểu rõ điều này: Số lượng khiếm khuyết trung bình trên mỗi kloc dường như là một đặc tính của thực tế là các nhà phát triển là con người dễ sai lầm hơn là những lợi thế hoặc bất lợi đặc biệt của một ngôn ngữ hoặc nền tảng cụ thể.

(Ngoài ra: Nếu bạn chưa có Code Complete, hãy mua cho mình một bản sao và đọc kỹ - thật đáng để đầu tư.)

Cập nhật : Có một yếu tố khác với một số câu trả lời ở đây - thống kê quy mô lớn rất hữu ích để đưa ra dự đoán chung nhưng không phải là cụ thể. Hãy xem xét, các bảng tỷ lệ tử vong dân số có thể dự đoán về số người sẽ thiệt mạng trong các vụ tai nạn giao thông trong năm nay nhưng không thể cho bạn biết người nào sẽ chết. Tương tự, các số liệu thống kê ngành cho thấy số lượng khuyết tật tương đối không đổi trên mỗi kloc không thể được sử dụng để dự đoán mức độ tốt - hoặc mức độ kém - một nhà phát triển cụ thể sẽ thực hiện hoặc điều gì sẽ xảy ra trên một dự án nhất định.

Yêu cầu là - tốt nhất - ngây thơ.

SLOC không chính xác là một số liệu đáng tin cậy cho bất cứ điều gì hữu ích, ngoại trừ có thể so sánh quy mô của hai hoặc nhiều dự án. Hơn nữa, có hai loại SLOC riêng biệt, LỘC vật lý và LỘC logic và những loại này có thể khác nhau đáng kể. Hãy xem xét ví dụ này, từ Wikipedia :

for (i = 0; i < 100; i += 1) printf("hello"); 

Ở đây chúng ta có một LỘC vật lý, nhưng hai LỘC logic ( forvà printfcâu lệnh). Nhưng tất nhiên chúng ta có thể viết ví dụ như:

for (i = 0; i < 100; i += 1) 
  printf("hello"); 

Điều này sẽ cho chúng ta hai LỘC và hai LỘC logic. Tôi nghĩ rõ ràng rằng bất kỳ phép đo "lỗi trên mỗi địa phương" nào phụ thuộc vào các LỘC vật lý sẽ bị phá hỏng bởi phong cách lập trình, do đó, phép đo của chúng tôi sẽ vô dụng.

Mặt khác, nếu chúng ta đã đi với các LỘC logic thì phép đo của chúng ta sẽ phụ thuộc rất nhiều vào các đặc điểm cú pháp của ngôn ngữ. Mặc dù số liệu kết quả có thể hơi hữu ích khi so sánh các dự án được viết bằng cùng một ngôn ngữ, nhưng nó sẽ khá vô dụng đối với các dự án được viết bằng các ngôn ngữ khác nhau.

Một nguồn có thể cho khiếu nại là thất bại Phần mềm của Les Hatton - những kẻ theo dõi và ngụy biện :

Chúng ta có thể kết luận rằng sự lựa chọn ngôn ngữ lập trình ít nhất liên quan đến độ tin cậy.

Sau đó, bài báo đề cập đến mật độ khiếm khuyết tương tự cho C và C ++:

Trong một nghiên cứu gần đây so sánh hai hệ thống tương tự có kích thước tương tự nhau, (khoảng 50.000 dòng mỗi dòng), một trong C và một trong C ++ được thiết kế đối tượng, mật độ khiếm khuyết kết quả được hiển thị tương tự nhau ở mức 2,4 và 2,9 trên 1000 dòng.

Tuy nhiên, điều này không có nghĩa là "lỗi trên mỗi LỘC" là không đổi trên các ngôn ngữ lập trình, hoặc nó sẽ có ý nghĩa nếu có.

Quan sát này rất lâu đời và đến từ một nguồn rất đáng kính, cụ thể là Fred Brooks trong cuốn sách "Tháng huyền thoại của người đàn ông". Ông là một người quản lý hàng đầu tại IBM và quản lý nhiều dự án lập trình bao gồm hệ điều hành hàng triệu hệ điều hành OS / 360. Trong thực tế, ông đã báo cáo rằng số lượng lỗi trong một chương trình không tỷ lệ thuận với độ dài của mã, nhưng là bậc hai ! Theo nghiên cứu của ông, số lượng lỗi tỷ lệ thuận với độ dài của chương trình với sức mạnh 1.5. Nói cách khác, một chương trình dài hơn mười lần có lỗi gấp 30 lần. Và ông đã báo cáo rằng điều này nắm giữ tất cả các ngôn ngữ lập trình và cấp độ ngôn ngữ lập trình.

Tôi không thấy lỗi trên mỗi LỘC là không đổi đối với một ngôn ngữ nhất định. Lỗi trên LỘC dường như là một số liệu mà một số Nhà quản lý sử dụng để xác định chất lượng của nhà phát triển khi nói đến thời gian xem xét.

Bây giờ bên ngoài đó, một số ngôn ngữ dễ bị lỗi hoặc khiếm khuyết hơn những ngôn ngữ khác. Thông thường, nhưng không phải lúc nào đây cũng là ngôn ngữ cấp thấp hơn ngôn ngữ cao hơn. Ví dụ, mã hóa bằng C so với C # (hoặc Java.) Tôi thường nói vì thực tế của nó và mấu chốt của câu trả lời mà bạn đang tìm kiếm liên quan đến chất lượng của nhà phát triển và thực tiễn mã hóa. Tôi đã thấy các nhà phát triển C rất giỏi với chất lượng mã cao hơn và số lượng lỗi thấp hơn so với các nhà phát triển Java / C # trung bình. Đây là một mục tách biệt một nhà phát triển cao cấp với một cơ sở. Không phải có bao nhiêu LỘC họ viết trong một khung thời gian nhất định, mà là chất lượng của mã ghi bất kể ngôn ngữ, LỘC hay khung thời gian.

Câu trả lời duy nhất tôi có thể đưa ra có thể liên quan là càng nhiều LỘC thì càng có nhiều khả năng tồn tại khuyết điểm và càng có nhiều khuyết điểm tồn tại.

Lỗi trên mỗi dòng mã

Lỗi / LỘC chỉ liên quan đến một cá nhân. Đối với các doanh nghiệp triển khai các công cụ theo dõi lỗi liên kết với kho lưu trữ mã nguồn của họ. Người quản lý có thể tổ chức các vấn đề theo nhà phát triển, được sắp xếp theo các vấn đề trong quá khứ và thay đổi mã.

Lỗi có liên quan đến công việc của bạn

Một nhà phát triển phần mềm cao cấp, người có nhiều kinh nghiệm, có tay nghề cao, rất thông minh và có thể đảm nhận các công việc độc lập có nhiều khả năng có nhiều lỗi đăng nhập vào hệ thống theo dõi, sau đó là một nhà phát triển cơ sở có ít kinh nghiệm.

Làm thế nào là có thể?

Các nhà phát triển cao cấp thường tham gia vào các nhiệm vụ phát triển rủi ro cao hơn. Tái cấu trúc mã và xây dựng các hệ thống mới làm ví dụ. Các nhà phát triển trẻ thường được chỉ định để khắc phục các sự cố đã biết không xứng đáng với thời gian của nhà phát triển cấp cao.

Do đó, bằng cách phân công nhiệm vụ, một thiếu niên không giới thiệu các lỗi mà chỉ sửa chúng và một nhà phát triển cấp cao được phép mạo hiểm giới thiệu chúng, bởi vì lợi ích của những gì họ đang cố gắng lưu trữ là quan trọng hơn sau đó các vấn đề nhỏ được nêu ra hoàn thành những vấn đề đó nhiệm vụ.

Cú pháp ngôn ngữ là quan trọng

Lập luận rằng một ngôn ngữ giới thiệu ít lỗi hơn, bởi vì nó có thể đạt được nhiều hơn trong ít dòng mã hơn là một huyền thoại hoàn chỉnh. Các ngôn ngữ có cấu trúc cao như C ++ / C # / Java buộc nhà phát triển phải thể hiện rõ ràng bằng văn bản hướng dẫn mong muốn là gì, trong khi các ngôn ngữ như Python / PHP rất không có cấu trúc. Những ngôn ngữ này cho phép các biểu thức bằng văn bản không chỉ gây nhầm lẫn cho nhà phát triển mà còn cả trình phân tích ngôn ngữ.

Trình biên dịch làm giảm lỗi

Có bao nhiêu lỗi trong Python / PHP đã đưa nó vào các máy chủ sản xuất, vì không có trình biên dịch để cảnh báo nhà phát triển rằng có gì đó không đúng. Khi bạn đo lỗi trên mỗi LỘC là trước hoặc sau khi trình biên dịch đã xử lý mã nguồn?

Cập nhật 2019:

Trình biên dịch không tạo ra sự khác biệt về bản chất hoặc số lượng lỗi. Lỗi hoàn toàn liên quan đến người đã viết mã nguồn và bản thân các lỗi có thể rất chủ quan.

FWIW, theo kinh nghiệm của tôi

1. Có hai loại lỗi: a) trong đó chương trình không đáp ứng được kỳ vọng và b) khi chương trình không thể đáp ứng bất kỳ kỳ vọng hợp lý nào, vì nó gặp sự cố / treo / không biên dịch.

2. Bất kể ngôn ngữ nào, lỗi loại (b) là do sự dư thừa trong cấu trúc dữ liệu / lớp, trong đó việc thay đổi thứ gì đó trong một phần của cấu trúc dữ liệu sẽ đặt cấu trúc ở trạng thái không nhất quán / bị hỏng cho đến khi một hoặc nhiều thay đổi tương ứng được thực hiện ở các phần khác . Đóng góp cho điều này là sự dư thừa của mã nguồn, trong đó việc chỉnh sửa một dòng mã làm cho mã không chính xác cho đến khi một hoặc nhiều thay đổi được thực hiện ở các phần khác. Tất nhiên, hai loại dự phòng này có liên quan chặt chẽ với nhau, và vì các lập trình viên không phải là siêu nhân nên họ bị phân tâm, quên đồ và mắc lỗi, từ đó mắc lỗi.

Những điều này (một lần nữa, theo kinh nghiệm của tôi) không thực sự là một chức năng của ngôn ngữ, mà là về kỹ năng / sự trưởng thành của lập trình viên. Các chương trình ít bị lỗi hơn cũng có xu hướng nhỏ hơn nhiều, về mặt LỘC, cho một bộ chức năng nhất định.

Tôi đã thấy các hệ thống trong đó một số người viết chương trình, trong khi những người khác viết thư mục và trước đây có xu hướng "chỉ hoạt động" so với hệ thống sau.

Tôi hy vọng rằng một yếu tố chính trong lỗi mã hóa liên quan đến cái mà tôi gọi là "khoảng cách ngữ nghĩa" giữa một loại định nghĩa giải pháp cụ thể và mã để giải quyết nó - trong đó đây là những lỗi cải cách chặt chẽ sẽ rõ ràng hơn, trong đó mã rất rõ ràng khác nhau, nhiều lỗi có thể được dự kiến. Mô hình của một số ngôn ngữ nhất định phù hợp chặt chẽ với các miền vấn đề nhất định - bảng tính rất phù hợp với các tính toán kinh doanh hàng ngày, dẫn đến cả rất ít "mã" và "mã" rất gần với miền vấn đề. Mã dự kiến ​​là rất ngắn gọn (ít KLOC) và một vài lỗi. Ngược lại, sử dụng trình biên dịch sẽ yêu cầu nhiều KLOC và có khả năng tạo ra vô số lỗi.

Thay vì nói về các dòng mã - thực sự là một số liệu vô dụng - tôi muốn giải quyết phần này trong câu hỏi của bạn:

Liệu các ngôn ngữ cấp cao hơn dẫn đến ít lỗi hơn?

Điều này khác với lỗi / LỘC, vì các ngôn ngữ cấp cao làm được nhiều hơn với ít mã hơn. Việc thực hiện một số yêu cầu tính năng có thể mất 500 dòng LISP so với 15000 dòng lắp ráp x86.

Vì vậy, ngay cả khi lỗi / LỘC không đổi giữa tất cả các ngôn ngữ, ngôn ngữ cấp cao hơn vẫn sẽ mang lại ít lỗi hơn.