Entropy의 개념을 유용한 방법으로 소스 코드를 분석하는 데 사용할 수 있습니까?

상대적으로 복잡한 값을 생성하는 규칙을 포함하는 정적 소스 코드 분석에 대한 컨텍스트를 정의 할 수 있다는 것이 논리적으로 보입니다. souce 코드에는 "에너지"가 없기 때문에 물리적 의미와 다르다는 것을 알고 있습니다. 누구든지 이것에 대해 알고 있습니까? 그렇다면 어떤 결과로 유용한 결과를 얻었습니까?

코드 복잡성에 대한 여러 측정 방법이 이미 있습니다.

• 순환 복잡성
• 수업 시간
• 방법 길이
• 필드 수
• 메소드 매개 변수 수
• N 경로 복잡성
• 팬인 및 팬 아웃
• 데이터 흐름 분석 (DU / DD 체인)

이들을 결함 밀도, 유지 노력 및 이해의 용이성과 연관시키기위한 작업이 수행되었다. 분석에서 배우려는 내용에 따라 일부는 다른 것보다 더 의미가 있습니다. 나는 물리 과학의 엔트로피 개념에 익숙하지 않지만 시간이 지남에 따라 명명 한 것과 같은 측정 및 메트릭을 추적하고 시간이 지남에 따라 결함과 관련시키는 것이 당신이 찾고있는 것과 유사할지 궁금합니다.

Ivar Jacobson의 소프트웨어 엔트로피 및 소프트웨어 rot 정의에 관심이있을 수도 있습니다 . 이러한 주제의 일반적인 아이디어는 코드와 실행 환경이 변경됨에 따라 소프트웨어 시스템이 저하되기 시작한다는 것입니다. 리팩토링은 엔트로피 또는 부패를 최소화하는 방법으로 볼 수 있으며 적어도 경험상 위에서 언급 한 메트릭 및 측정은 시스템 또는 하위 시스템에서 리팩토링이 필요할 수 있음을 나타내는 지표입니다.

열역학 엔트로피와 "복잡성"사이에 평행을 그리려고한다고 생각합니다. 엔트로피는 복잡성이 아니라 장애 의 척도입니다 . 나는 둘이 동등하고 상호 교환 가능하다고 믿지 않습니다.

열역학 엔트로피에 가장 가까운 아날로그 는 임의 변수에서 장애의 양을 측정하는 Shannon 엔트로피 입니다. 이 개념은 주로 메시지의 "정보"양과 관련이 있습니다.

이와 관련하여, 코드 조각은 많은 정보 (높은 엔트로피)를 갖지만 복잡성이 매우 낮을 수 있습니다. 아주 긴 문자열을 임의의 문자로 출력하는 프로그램을 생각해보십시오. 정보는 많지만 복잡성은 낮습니다.

엔트로피 는 "장애 [또는] 예측 불가능의 척도"입니다. 정보에서 더 넓은 범위의 고유 한 패턴 (즉, 대략 "더 많은 의미")은 더 높은 엔트로피를 나타냅니다.

컴퓨터 소스 코드에 적용하면이 원칙이 유용 할 수 있다고 생각합니다. 그러나 엔트로피를 계산할 소스 코드에 대한 확률 모델을 설계해야합니다 . (쉽게 떠오르는 데이터 구조는 호출, 클래스 상속 등 다양한 엣지 유형을 가진 그래프입니다.)

모델이 설계되고 소프트웨어 응용 프로그램의 소스 코드 (즉, 노드 / 에지의 주파수)로 채워지면 엔트로피를 계산할 수 있습니다.

나는 이것에 대한 연구를 모른다. 그러나 내 직관은 엔트로피가 적다는 것은 소스 코드가 응용 프로그램 전체에서 공통 패턴을 재사용한다는 것을 의미한다는 것입니다 (즉 DRY ). 반대로 엔트로피가 높으면 소스 코드가 복잡하고 잘 고려되지 않았 음을 의미합니다.

엔트로피를 생각하는 한 가지 방법은 "평균 정보를 얻는 것"이므로 모델링 정보로 돌아가는 것이 좋습니다. 정보를 수학적으로 모델링하는 두 가지 기본 접근법을 알고 있습니다. (위키 백과 참조를 제공 한 것을 용서해주세요. 그러나 IMHO는 나쁘지 않습니다.)

• Shannon Information- 심볼 세트, 그에 대한 확률 분포, 심볼 세트간에 정보를 전송할 수있는 코드 및 해당 코드의 길이를 살펴 봅니다. 코드 효율성, 노이즈, 오류 감지 및 리던던시를 통한 수정 등의 일반적인 개념은 Shannon 정보 이론 측면에서 중요합니다. 정보를 표현하는 한 가지 방법은 심볼을 나타낼 수있는 가장 짧은 이진 코드의 길이라고 말하는 것입니다. 이것은 확률에 기초하며, 이는 일부 관찰자에 의해 심볼 또는 이벤트에 할당 된 숫자 값입니다.

• 솔로몬 오프 (또는 콜 로모 로프 ) 정보. 다른 설명이 있습니다. 이 공식에서 기호 또는 이벤트의 정보 내용은이를 계산할 수있는 가장 짧은 프로그램의 길이로 표시됩니다. 여기서 다시 한 번, 확률을 할당하는 관찰자가 아니라 프로그램을 실행할 수있는 범용 머신에 상대적입니다. 모든 유니버설 머신은 유니버설 튜링 머신으로 시뮬레이션 할 수 있기 때문에 어떤 의미에서는 심볼 또는 이벤트의 정보 내용이 상대적이 아니라 절대적임을 의미합니다.

제가 생각하는 바를 일상적인 용어로, 제가 책을 쓴 것에 대해 자유롭게 말할 수 있다면 , 그것은 기능 사양 및 언어와 같은 것들이 적절하고 일정하게 유지 될 때 프로그램의 복잡성이 그 길이라는 것을 의미합니다. 주석 및 이름 길이와 같은 것들에 대한 수당. 그러나이 문제에는 간결함이 이해할 수없는 "APL 타르 핏"이라는 문제가 있습니다.

(AI를 공부하는 동안했던 것처럼) 프로그램의 기능 사양은 실제 모델 일뿐 아니라 효율적으로 인코딩되는, 즉 요구 사항에 대한 생각을 바꿀만큼 충분히 작은 중복성을 갖는 정신 모델로 구성된다는 것을 고려하는 것이 훨씬 낫습니다. 내부적으로 일관성이 없어 질 위험이없이, 즉 "버그"가 발생할 수 있습니다. 그런 다음 프로그래밍 프로세스는 정보 모델로서 정신 모델을 입력으로 사용하고 출력은 작업 소스 코드입니다. 그런 다음 멘탈 모델이 변경되면 해당 델타가 프로그래밍 프로세스를 통해 공급되고 소스 코드에서 해당 델타로 변환되어야합니다. 그 델타는 쉽게 측정됩니다. 델타를 적용하기 전과 적용한 후 (완전히 모든 버그가 해결 된 상태) 소스를 구분합니다. 삽입, 삭제 및 교체 된 코드 블록 수를 계산합니다. 즉, 소스 코드 언어가 작을수록 정신 모델이 표현하는 언어 (명사, 동사 및 구조 측면에서)를 더 잘 나타냅니다. 이 측정 값이 기능 변경 가능성이있는 공간에 대해 평균화되는 경우 이는 소스 언어의 엔트로피 개념이며, 더 적은 것이 좋습니다. 이것에 대한 용어가 있습니다-DSL (도메인 특정 언어)

참고 문헌이 약하거나 개인적 인 경우 미안하지만이 전반적인 질문은 매우 중요하다고 생각합니다.

Jon Jagger 와 Olve Maudal 은 2011 년 Accu 컨퍼런스 세션 코드 엔트로피 및 소프트웨어 물리학 에서 볼 수 있듯이 약간 다른 코드 엔트로피 관점을 가지고 있습니다 .

그들은 미래 개발자 / 유지 업체가 해당 코드를 변경할 가능성과 관련이있는 코드 의 안정성 에 대해 이야기 합니다.

이를 입증하기 위해 여러 코드 스 니펫으로 설문 조사를 수행했으며 결과는 매우 흥미 롭습니다.

• 하나의 괄호 스타일 에 대한 강한 편견이있는 것처럼 보였습니다 .
• 그러나 단일 진술 을 받아들이 는 것에 대한 강한 편견 .
• 임시 변수 사용에 대한 강한 편견이있었습니다.
• 연산자 우선 순위를 명확하게하기 위해 괄호를 추가 할 수있는 강력한 편견이있었습니다.

그 외 16 명

일반적인 추세는 코드를 이해하기 쉽고 잘못 이해하기 어렵게 만드는 것 같습니다.

또한 수년에 걸쳐 큰 코드베이스에 적용된 일부 변경 사항도 살펴 봅니다.

슬라이드 자체가 세션의 대본이 아니어도 여전히 흥미로운 점이 있습니다.

나는 프로그램의 복잡성을 측정하기 위해 엔트로피를 사용했던 교수 하에서 공부했다. (우리의 교과서는 이 책의 오래된 판이며 , 그의 술집 중 일부는 여기에 있다.) FAU에는 이것이 주요한 조치 중 하나 인 많은 논문이 있었지만, 마지막으로 본 이후 학교 웹 사이트가 바뀌었고, 학생 논문 / 논문이 어디에 있는지 찾을 수 없습니다.

그러한 논문 중 하나는 정보 이론 및 소프트웨어 측정 입니다.

엔트로피와 같은 방식으로 "수학적"인 정의를 원한다면 최소한의 코드로 복잡성을 측정하는 Kolmogorov 복잡도를 살펴볼 수 있습니다. 그러나 이것은 코드의 복잡성이 아닙니다. 그러나 코드로 수행하려는 작업. 그러나 이론적으로 특정 코드를 최소한의 코드와 비교할 수 있기 때문에 관련성이 있다고 생각할 수 있습니다. 그러나 이것은 현재 실제 코드의 복잡성을 측정하는 데 유용한 기술이 아닙니다.

나는 이것이 가능하지 않다고 생각합니다. 잘 작성된 코드베이스는 더 높은 엔트로피 (장애)를 가져야한다고 주장 할 수 있습니다. 코드 스 니펫이 반복적으로 반복되는 코드베이스를 생각하면 반복 부분 (낮은 엔트로피 / 파일 크기)으로 인해 높은 압축 비율로 압축 할 수 있지만 코드를 별도의 함수로 이동하면 압축 비율이 낮아집니다 (높은 엔트로피 / 파일 크기).

따라서 압축 품질을 계수로 사용하여 Entropy / CodeLines와 같은 것을 계산하여 코드 품질을 측정 할 수 있지만, 이는 전체 랜덤 입력이 세계 최고의 코드처럼 보일 것이라는 문제가 있습니다.

실제로 압축 비율은 코드의 엔트로피를 측정하는 데 유용한 미터이지만 코드 품질에 대한 좋은 미터는 아닙니다.

엔트로피라는 용어는 열역학 및 정보 이론뿐만 아니라 실제 데이터 압축 세계에서도 나타납니다. 이와 관련하여, 컴프레서가 보는 엔트로피는 생성하는 비트 수와 같습니다. 엔트로피 로 간주되는 것은 입력 데이터를 설명하기 위해 압축기가 사용하는 모델에 따라 달라지기 때문에 " 컴프레서에서 볼 수 있는 엔트로피 "를 언급했습니다. 이것이 다른 압축기가 다른 크기의 파일을 생성하는 이유입니다. 하나는 다른 하나는 악용 가능한 구조입니다.)

이것은 원칙적으로 소스 코드 복잡성에 아름답게 적용될 수 있습니다. "그냥"완전한 표준 호환 소스 코드에서만 작동하고 실제로는 컴파일러처럼 구문 분석하여 해당 구문 트리를 생성하는 압축 압축기를 작성하십시오. 그런 다음이 구문 트리를 걷고 각 노드에서 각 노드에서 가능한 노드를 결정하여 해당 노드를 해당 지식으로 인코딩 할 수 있습니다.

예를 들어, 언어에서 기존 식별자 나 괄호로 묶은 항목 또는 특정 지점의 제품을 허용하는 경우 압축기는 유형 정보를 고려하여 가능한 기존 식별자를 계산합니다 (예 : 3 개의 식별자가 있음) ), 2 개의 가능한 하위 표현식에 2를 더하여 5 가지 가능성을 제공합니다. 따라서 노드는 lb 5 = 2.32비트로 인코딩됩니다 . 두 개의 가능한 하위 표현식의 경우 내용을 인코딩하려면 더 많은 비트가 필요합니다.

이것은 실제로 코드의 복잡성을 매우 정확하게 측정합니다. 그러나이 방법은 여전히 ​​쓸모가 없습니다! 같은 이유로 모든 코드 복잡성 측정이 쓸모가 없다는 것은 쓸모가 없습니다. 측정 된 코드 복잡성 (무엇이든)과 코드가 해결하는 문제의 복잡성을 연결하지 못합니다. LOC 수를 사용하여 고용주에게 인상을주기 위해 프로그래밍 문제에 대한 엄청나게 복잡한 솔루션을 항상 찾을 수 있지만 코드 복잡성 측정으로 인해 일부 노력만으로도 작업을 해결할 수 있다고 말할 수는 없습니다.

코드는 숫자 π만큼 정확하게 엔트로피를 갖습니다.

코드 유지 관리 및 변경으로 인해 엔트로피가 발생할 수 있습니다 (상태 변경이 가능하기 때문).

그러나 코드는 큰 숫자입니다. 이진 표현으로.