It is the complexity calculated based on the number of paths through the code. Whenever the control flow of a function splits, the complexity counter gets incremented by one. Each function has a minimum complexity of 1. This calculation varies slightly by language because keywords and functionalities do.

More details코드이 경로를 기반으로 계산한 복잡도입니다. 소프트웨어 기능의 로직 흐름에 분기가 발생할 때마다, 복잡도 값은 1씩 증가합니다.

각 함수의 복잡도는 최소 1입니다. 각 프로그래밍 언어별로 키워드^keyword 및 기능^{functionality}가 상이하여, 복잡도 계산 정보는 약간 상이할 수 있습니다.

자세히 보기

Number of lines containing either comment or commented-out code.

Non-significant comment lines (empty comment lines, comment lines containing only special characters, etc.) do not increase the number of comment lines.

The following piece of code contains 9 comment lines실제 주석 혹은 주석 처리된 코드의 라인 수입니다.

의미 없는^{non-significant} 코멘트 라인(빈 코멘트라인, 특수 문자만 존재한 라인 등)은 주석 라인 수를 증가시키지 않습니다.

다음 코드는 9 주석 라인을 포함하고 있습니다:

More details더 자세히 보기

Density of comment lines 주석 라인 밀도 = Comment lines 주석 라인 수 / (Lines of code코드 라인 수 + Comment lines주석 라인 수) * 100

With such a formula:

위의 식에 따라:

• 50%: 코드 라인 수와 주석 라인 수가 동일함
• 100%: 주석 라인 만 존재함

Duplicated blocks

duplicated_blocks

Number of duplicated blocks of lines.

For a block of code to be considered as duplicated:

Differences in indentation as well as in string literals are ignored while detecting duplications중복된 라인 블록의 수.

다음의 경우 중복된 블록으로 판단합니다:

• Java 프로젝트 외:
  • 최소한 100개의 토큰이 연속적으로 중복되는 경우
  • 이 토큰들은 최소한 다음 범위에 퍼져 있어야 함:
    • COBOL: 30 코드 라인
    • ABAP: 20 코드 라인
    • 그 외: 10 코드 라인
      
• Java 프로젝트:
  • 토큰 혹은 라인 수에 관계 없이, 최소 10개의 구분이 연속적으로 중복되는 경우

코드 중복 식별시, 들여쓰기(indentation) 및 스트링 문자열(string literal)는 검사 범위에서 제외합니다.

Density of duplication 코드 중복 밀도 = Duplicated lines중복된 라인 수 / Lines 전체 라인 수 * 100

New issues

new_violationsNumber of new issues.

신규 이슈 수

New xxxxx issues

new_xxxxx_violationsNumber of new issues with severity xxxxx, xxxxx being

xxxxx 심각도의 신규 이슈 수

(xxxxx는 blocker, critical, major, minor or 혹은 info .임)

Issues

violationsNumber of issues.

이슈 전체 수

xxxxx issues

xxxxx_violationsNumber of issues with severity xxxxx, xxxxx

being xxxxx 심각도의 이슈 전체 수

(xxxxx는 blocker, critical, major, minor or 혹은 info .임)

Rating given to your project related to the value of your 기술 부채 비율(Technical Debt Ratio. The default Maintainability Rating grid is) 값에 따른 프로젝트 등급. 기본 유지보수성 등급(Maintainability Rating)은 그리드는 다음과 같습니다:

A=0-00~0.05, B=0.06-006~0.1, C=0.11-011~0.20, D=0.21-021~0.5, E=0.51-1

The Maintainability Rating scale can be alternately stated by saying that if the outstanding remediation cost is:

51~1

유지보수성 등급은 필요한 개선 비용(remediation cost)으로 대신 표현할 수 있습니다:

• 5% 이하의 비용을 투입해야 할 경우, A등급에 해당합니다.
• 6~10%의 비용을 투입해야 할 경우, B등급에 해당합니다.
• 11~20%의 비용을 투입해야 할 경우, C등급에 해당합니다.
• 21~50%의 비용을 투입해야 할 경우, D등급에 해다합니다.
• 50% 초과 비용을 투입해야 할 경우, E등급에 해당합니다.

Ratio between the cost to develop the software and the cost to fix it. The Technical Debt Ratio formula is:

	Remediation cost / Development cost 

Which can be restated as:

	Remediation cost / (Cost to develop 1 line of code * Number of lines of code)

소프트웨어 개발 비용과 수정 비용의 비율로, 기술 부채 비율(Technical Debt Ratio)은 다음 식에 따라 계산합니다:

개선 비용(Remediation cost) / 개발 비용(Development cost)

위 공식은 아래와 같이 변경할 수 있습니다:

개선 비용(Remediation cost) / (코드 1 라인 개발 비용 * 코드 라인 수)

코드 1 라인 개발 비용은 0.06일(day)입니다.

Ratio between the cost to developer the code changed in the leak period and the cost of the issues linked to it.

릭 피리어드(leak period)에 변경된 코드를 개발하는 비용과 해당 코드에 관련된 이슈 처리 비용의 비율입니다.

A = 0 Bug버그 수 0개
B = at least 1 Minor Bug마이너(Minor) 버그 최소 1개
C = at least 1 Major Bug메이저(Major) 버그 최소 1개
D = at least 1 Critical Bug크리티컬(Critical) 버그 최소 1개
E = at least 1 Blocker Bug블로커(Blocker) 버그 최소 1개

A = 0 Vulnerability취약점 0개
B = at least 1 Minor Vulnerability마이너(Minor) 취약점 최소 1개
C = at least 1 Major Vulnerability 메이저(Major) 취약점 최소 1개
D = at least 1 Critical Vulnerability크리티컬(Critical) 취약점 최소 1개
E = at least 1 Blocker Vulnerability 블로커(Blocker) 취약점 최소 1개

Number of physical lines that contain at least one character which is neither a whitespace or a tabulation or part of a comment공백(whitespace), 탭문자(tabulation) 혹은 주석의 일부가 아닌 문자를 최소한 한 문자 이상 포함한 물리적인 라인 수.

More details

Number of functions. Depending on the language, a function is either a function or a method or a paragraph함수 수. 프로그래밍 언어에 따라 함수(function), 메소드(method) 혹은 패러그래프(paragraph) 값일 수 있음.

More details

Number of public Classes + number of public Functions + number of public Properties퍼블릭 클래스(public Classes) + 퍼블릭 함수(public Functions) 수 + 퍼블릭 프로퍼티(public Properties) 수

More details

Number of statements구문(statement) 수.

More details

On each line of code containing some boolean expressions, the condition coverage simply answers the following question: 'Has each boolean expression been evaluated both to true and false?'. This is the density of possible conditions in flow control structures that have been followed during unit tests execution조건 커버리지(Condition coverage)는 불리언 표현식을 가진 모든 코드 라인에 대해, '각 불리언 표현이 참과 거짓으로 평가되었는가?'를 판단합니다. 이는 단위 테스트를 실행하는 동안 흐름 제어(flow control)제어 구조에 존재 가능한 조건의 모든 경우를 의미합니다.

Identical to Condition coverage but restricted to new / updated source code조건 커버리지(Condition coverage)와 동일하나, 신규 혹은 업데이트 한 코드로 범위를 한정합니다.

It is a mix of 라인 커버리지(Line coverage and )와 조건 커버리지(Condition coverage. Its goal is to provide an even more accurate answer to the following question: How much of the source code has been covered by the unit tests?)를 조합한 지표. 이 지표는 '단위 테스트로 얼마나 많은 코드를 커버했는가?'에 대한 답을 얻기 위해 사용합니다.

Identical to Coverage but restricted to new / updated source code커버리지(Coverage)와 동일하나, 신규 및 업데이트 된 코드로 범위를 한정합니다.

On a given line of code, Line coverage simply answers the following question: Has this line of code been executed during the execution of the unit tests?. It is the density of covered lines by unit tests라인 커버리지(Line coverage)는 주어진 코드 라인에 대해 '단위 테스트를 수행하는 동안, 이 코드 라인이 실행되었는가?'를 판단하며, 단위 테스트가 커버한 라인의 비율을 의미합니다: