Khái niệm Entropy có thể được sử dụng để phân tích mã nguồn một cách hữu ích không?

Nó có vẻ hợp lý với tôi rằng người ta có thể định nghĩa một bối cảnh để phân tích mã nguồn tĩnh bao gồm các quy tắc để tạo ra một giá trị tương đối phức tạp. Tôi biết nó không giống như theo nghĩa vật lý bởi vì mã souce không có "Năng lượng" nhưng tôi cá là đã có những nỗ lực, trong học thuật, để vẽ song song. Có ai có kiến ​​thức về điều này và nếu vậy, đến cuối cùng nó đã tạo ra kết quả hữu ích?

Đã có một số biện pháp về độ phức tạp của mã:

• Phức tạp cyclomatic
• Độ dài lớp học
• Chiều dài phương pháp
• Số lượng các lĩnh vực
• Số lượng tham số phương thức
• Độ phức tạp của đường dẫn N
• Fan-in và fan-out
• Phân tích luồng dữ liệu (chuỗi DU / DD)

Công việc đã được thực hiện để tương quan những điều này với khiếm khuyết mật độ, nỗ lực để duy trì và dễ hiểu. Một số có ý nghĩa hơn những cái khác, tùy thuộc vào những gì bạn đang cố gắng học hỏi từ phân tích của bạn. Tôi không quen thuộc với khái niệm entropy từ khoa học vật lý, nhưng tôi tự hỏi liệu việc theo dõi các phép đo và số liệu như số liệu tôi đặt tên theo thời gian và liên quan đến các khuyết tật theo thời gian, có giống với những gì bạn đang tìm kiếm không.

Bạn cũng có thể quan tâm đến định nghĩa của Ivar Jacobson về entropy phần mềm và thối phần mềm . Ý tưởng chung của các chủ đề này là theo thời gian, khi mã cũng như môi trường thực thi thay đổi, hệ thống phần mềm bắt đầu xuống cấp. Tái cấu trúc được coi là một phương pháp giảm thiểu entropy hoặc rot, và, ít nhất theo kinh nghiệm của tôi, các số liệu và phép đo mà tôi đã đề cập ở trên sẽ là các chỉ số có thể cần tái cấu trúc trong hệ thống hoặc hệ thống con.

Tôi nghĩ rằng bạn đang cố gắng vẽ song song giữa entropy nhiệt động và "độ phức tạp". Có điều, entropy là thước đo rối loạn không phức tạp . Tôi không tin rằng hai cái này tương đương và có thể hoán đổi cho nhau.

Tương tự gần nhất với entropy nhiệt động là entropy Shannon đo lượng rối loạn trong một biến ngẫu nhiên. Khái niệm này chủ yếu liên quan đến lượng "thông tin" trong một tin nhắn.

Về vấn đề đó, một đoạn mã có thể có nhiều thông tin (entropy cao) nhưng độ phức tạp rất thấp. Hãy nghĩ về một chương trình chỉ đơn giản là in ra một chuỗi các ký tự tùy ý. Nó có rất nhiều thông tin, nhưng độ phức tạp thấp.

Entropy là một "biện pháp rối loạn [hoặc] không thể đoán trước." Một phạm vi rộng hơn của các mẫu duy nhất trong thông tin (nghĩa là "nhiều ý nghĩa hơn") cho thấy mức độ entropy cao hơn.

Áp dụng cho mã nguồn máy tính, tôi nghĩ rằng nguyên tắc này có thể hữu ích. Tuy nhiên, cần phải thiết kế một mô hình xác suất cho mã nguồn để tính toán entropy. (Cấu trúc dữ liệu dễ hiểu là một biểu đồ với các loại cạnh khác nhau: cuộc gọi, kế thừa lớp, v.v.)

Khi mô hình được thiết kế và sau đó được điền với mã nguồn của ứng dụng phần mềm (tức là tần số cho các nút / cạnh), entropy có thể được tính toán.

Tôi không biết về bất kỳ nghiên cứu nào về vấn đề này, nhưng trực giác của tôi là mức độ entropy thấp sẽ có nghĩa là mã nguồn sử dụng lại các mẫu phổ biến trong toàn bộ ứng dụng (ví dụ DRY ). Ngược lại, một mức độ cao của entropy có nghĩa là mã nguồn có độ phức tạp cao và chưa được thực hiện tốt.

Một cách để nghĩ về entropy là "thông tin trung bình sẽ đạt được", vì vậy tôi nghĩ tốt hơn là quay lại mô hình hóa thông tin. Tôi biết hai cách tiếp cận cơ bản để mô hình hóa thông tin. (Xin thứ lỗi cho tôi vì đã đưa ra các tài liệu tham khảo Wikipedia, nhưng IMHO chúng không tệ.)

• Thông tin Shannon , xem xét các bộ ký hiệu, phân phối xác suất trên các mã đó, các mã có thể chuyển thông tin giữa các bộ ký hiệu và độ dài của các mã đó. Các khái niệm chung về hiệu quả mã, tiếng ồn, phát hiện lỗi và sửa lỗi thông qua dự phòng, v.v. được đề cập trong lý thuyết thông tin của Shannon. Một cách để thể hiện thông tin là nói nó là độ dài của mã nhị phân ngắn nhất có thể đại diện cho một biểu tượng. Điều này dựa trên xác suất, là một giá trị số được gán cho một biểu tượng hoặc sự kiện bởi một người quan sát.

• Thông tin của Solomonoff (hoặc Kolmogorov ). Đây là một lời giải thích khác. Trong công thức này, nội dung thông tin của một biểu tượng hoặc sự kiện được thể hiện bằng độ dài của chương trình ngắn nhất có thể tính toán nó. Ở đây một lần nữa, nó là tương đối, không phải là một người quan sát gán xác suất, mà là một cỗ máy vạn năng có thể thực thi chương trình. Vì mọi máy vạn năng đều có thể được mô phỏng bằng máy Turing phổ dụng, điều đó có nghĩa, theo một cách nào đó, nội dung thông tin của biểu tượng hoặc sự kiện không phải là tương đối, nhưng tuyệt đối.

Nếu tôi có thể tự do nói những gì tôi nghĩ điều này có nghĩa trong các điều khoản hàng ngày, về việc tôi đã viết một cuốn sách , điều đó đơn giản có nghĩa là sự phức tạp của một chương trình là độ dài của nó, khi những thứ như thông số chức năng và ngôn ngữ không đổi, phù hợp phụ cấp cho những thứ như ý kiến ​​và độ dài tên. Nhưng có một vấn đề với điều này - "bạt APL", trong đó tính đồng nhất tương đương với sự không thể hiểu được.

Sẽ tốt hơn nhiều khi xem xét (như tôi đã làm khi nghiên cứu về AI) rằng thông số chức năng của chương trình bao gồm một mô hình tinh thần, không chỉ có thật mà còn được mã hóa hiệu quả, nghĩa là với sự dư thừa đủ nhỏ để thay đổi suy nghĩ của mọi người về các yêu cầu có thể được thực hiện mà không có quá nhiều nguy hiểm khiến nó không nhất quán trong nội bộ - tức là có "lỗi". Sau đó, quá trình lập trình là một kênh thông tin lấy đầu vào là mô hình tinh thần và đầu ra của nó là mã nguồn làm việc. Sau đó, khi một thay đổi được thực hiện trong mô hình tinh thần, đồng bằng đó phải được cung cấp thông qua quá trình lập trình và biến thành một delta tương ứng trong mã nguồn. Đồng bằng đó dễ dàng được đo. Khác biệt nguồn giữa trước khi áp dụng delta đó và sau khi áp dụng nó (hoàn toàn, với tất cả các lỗi đã được giải quyết), và đếm số khối mã được chèn, xóa và thay thế. Càng nhỏ, ngôn ngữ mã nguồn đại diện cho ngôn ngữ mà mô hình tinh thần được thể hiện càng tốt (về danh từ, động từ và cấu trúc). Nếu biện pháp đó bằng cách nào đó được tính trung bình trong không gian của các thay đổi chức năng có khả năng, thì đó là một khái niệm về entropy của ngôn ngữ nguồn, và ít hơn là tốt hơn. Có một thuật ngữ cho việc này -Ngôn ngữ cụ thể miền (DSL)

Tôi xin lỗi nếu các tài liệu tham khảo là yếu / cá nhân, nhưng tôi nghĩ rằng câu hỏi tổng thể này là một câu hỏi rất quan trọng.

Jon Jagger và Olve Maudal có một cái nhìn hơi khác về Code Entropy, như có thể thấy trong phiên hội nghị Accu 2011 của họ về Entropy và Vật lý của Phần mềm .

Họ nói về sự ổn định của mã có liên quan đến việc các nhà phát triển / bảo trì trong tương lai có khả năng thay đổi mã đó hay không.

Để chứng minh điều này, họ đã thực hiện một cuộc khảo sát với một số đoạn mã và kết quả khá thú vị.

• Dường như có một sự thiên vị mạnh mẽ chống lại phong cách một chân thực .
• Nhưng thiên vị mạnh mẽ cho việc chấp nhận tuyên bố duy nhất nếu là.
• Có một sự thiên vị mạnh mẽ chống lại việc sử dụng các biến tạm thời.
• Có một sự thiên vị mạnh mẽ cho việc thêm dấu ngoặc đơn để làm cho ưu tiên toán tử rõ ràng.

cộng với 16 người khác.

Xu hướng chung dường như là hướng tới việc làm cho mã dễ hiểu hơn và khó hiểu hơn.

Họ cũng xem xét một số thay đổi được thực hiện đối với một cơ sở mã lớn trong những năm qua.

Mặc dù các slide tự chịu đựng vì không phải là bản sao của phiên, nhưng vẫn có một số điểm thú vị trong đó.

Tôi đã học theo một giáo sư đã sử dụng entropy như một thước đo cho sự phức tạp của các chương trình (sách giáo khoa của chúng tôi là một phiên bản cũ hơn của cái này , một số quán rượu của anh ta ở đây ). Có một số luận văn tại FAU nơi đây là một trong những biện pháp chính, nhưng trang web của trường đã thay đổi kể từ lần cuối tôi xem, và tôi không thể xác định được vị trí của luận án / luận án sinh viên.

Một luận án như vậy là Lý thuyết thông tin và Đo lường phần mềm .

Nếu bạn muốn một định nghĩa là "toán học" theo cách entropy, bạn có thể muốn xem xét độ phức tạp Kolmogorov, đo lường độ phức tạp bằng số lượng mã tối thiểu có thể được thực hiện. Tuy nhiên, đây không phải là độ phức tạp của mã, nhưng về những gì bạn đang cố gắng làm với mã. Nhưng bạn có thể nghĩ rằng nó có liên quan vì về mặt lý thuyết bạn có thể so sánh một đoạn mã cụ thể với mã tối thiểu. Tuy nhiên, đây không phải là một kỹ thuật hữu ích để đo độ phức tạp của mã thế giới thực.

Tôi nghĩ rằng điều này là không khả thi, người ta có thể lập luận rằng một cơ sở mã được viết tốt nên có entropy (rối loạn) cao hơn. Hãy suy nghĩ về một cơ sở mã nơi đoạn mã được lặp đi lặp lại, nó có thể được nén với tỷ lệ nén cao do phần lặp lại (kích thước tệp / kích thước tệp thấp hơn), tuy nhiên nếu bạn di chuyển mã sang một chức năng riêng biệt thì tỷ lệ nén sẽ thấp hơn (kích thước entropy / tệp cao hơn).

Vì vậy, người ta có thể nghĩ, sau đó tôi có thể tính toán một cái gì đó như Entropy / CodeLines bằng cách sử dụng tỷ số nén làm hệ số, để đo chất lượng mã, tuy nhiên điều này có vấn đề là tổng đầu vào ngẫu nhiên trông giống như mã tốt nhất trên thế giới rõ ràng là không.

Thật vậy, tỷ lệ nén là một thước đo tốt để đo entropy của mã, tuy nhiên cả hai đều không phải là mét tốt cho chất lượng mã.

Vâng, thuật ngữ entropy không chỉ xuất hiện trong nhiệt động lực học và lý thuyết thông tin, nó còn xuất hiện trong thế giới thực của việc nén dữ liệu. Trong bối cảnh đó, entropy mà máy nén nhìn thấy bằng với số bit mà nó tạo ra. (Lưu ý rằng tôi đã nói "entropy mà máy nén nhìn thấy ", bởi vì những gì được coi là entropy phụ thuộc vào kiểu máy nén sử dụng để mô tả dữ liệu đầu vào. Đây là lý do tại sao các máy nén khác nhau tạo ra các tệp có kích thước khác nhau: entropy là gì cái này là cấu trúc có thể khai thác cho cái kia.)

Về nguyên tắc, điều này có thể được áp dụng tuyệt vời cho độ phức tạp của mã nguồn: "Chỉ" viết một máy nén chỉ hoạt động trên mã nguồn tuân thủ tiêu chuẩn hoàn toàn và nén nó thực sự phân tích cú pháp như trình biên dịch, tạo ra cây cú pháp tương ứng. Sau đó, nó có thể đi theo cây cú pháp này và quyết định tại mỗi nút mà các nút có thể có ở mỗi điểm, mã hóa nút đó với kiến ​​thức đó.

Vì vậy, ví dụ, nếu ngôn ngữ cho phép một số nhận dạng hiện có hoặc một cái gì đó được đặt trong ngoặc đơn hoặc một sản phẩm tại một điểm cụ thể, máy nén sẽ tính các số nhận dạng hiện có có thể, đưa thông tin loại vào tài khoản (giả sử bạn có 3 số nhận dạng như vậy ) và thêm 2 cho hai biểu thức con có thể, đưa ra 5 khả năng. Vì vậy, nút sẽ được mã hóa bằng lb 5 = 2.32bit. Trong trường hợp có hai biểu hiện con có thể, sẽ cần nhiều bit hơn để mã hóa nội dung của chúng.

Điều này thực sự sẽ đưa ra một thước đo rất chính xác cho sự phức tạp của mã như nó là. Tuy nhiên, biện pháp này vẫn vô dụng! Thật vô ích vì cùng một lý do là tất cả các phép đo độ phức tạp của mã đều vô dụng: Chúng thất bại trong việc kết nối giữa độ phức tạp của mã được đo (bất cứ điều gì có thể) và độ phức tạp của vấn đề mà mã giải quyết. Bạn luôn có thể tìm thấy các giải pháp phức tạp một cách lố bịch cho các vấn đề lập trình của mình để gây ấn tượng với nhà tuyển dụng về số lượng LỘC của bạn, nhưng không có biện pháp phức tạp mã nào sẽ cho bạn biết rằng nhiệm vụ có thể đã được giải quyết với một phần nỗ lực.

Mã có chính xác nhiều entropy như số π.

Bảo trì và thay đổi mã có thể giới thiệu entropy (vì có thể có thay đổi trạng thái liên quan).

Nhưng mã chỉ là một con số lớn. Với một đại diện nhị phân.