Info
SQ Official Doc Link: https://docs.sonarqube.org/display/SONAR/Metric+Definitions

This is not an exhaustive list of metrics. For the full list, consult the metrics search web service on your SonarQube instance.

Complexity

Panel

borderColor	#C3CCD7
bgColor	#FCFCFC

Table of Contents

Table of Contents

indent	16px

SonarQube에서 제공하는 모든 메트릭을 다루지는 않습니다. 여러분이 사용하는 SonarQube 인스턴스에서 제공하는 전체 메트릭 리스트를 확인하고자 하는 경우 metrics search web service를 참조합니다.

복잡도(Complexity)

More details

Name	Key	Description
Complexity	complexity

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.

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

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

Complexity /class

class_complexity

Average complexity by class.

class 별 평균 복잡도
Complexity /file	file_complexity

Average complexity by file.

file 별 평균 복잡도
Complexity /method	function_complexity

Average complexity by function.

Documentation

function 별 평균 복잡도

문서화(Documentation)

Name	Key	Description
Comment lines	comment_lines

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 주석 라인을 포함하고 있습니다:

/** +0 =>

empty comment line

빈 주석 라인
* +0 =>

empty comment line

빈 주석 라인
* This is my documentation +1 =>

significant comment

의미 있는 주석
* although I don't +1 =>

significant comment

의미 있는 주석
* have much +1 =>

significant comment

의미 있는 주석
* to say +1 =>

significant comment

의미 있는 주석
* +0 =>

empty comment line

빈 주석 라인
*************************** +0 =>

non-significant comment

의미 없는 주석
* +0 =>

empty comment line

빈 주석 라인
* blabla... +1 =>

significant comment

의미 있는 주석
*/ +0 =>

empty comment line

빈 주석 라인

/** +0 =>

empty comment line

빈 주석 라인
* public String foo() { +1 =>

commented-out code

주석 처리된 코드
* System.out.println(message); +1 =>

commented-out code

주석 처리된 코드
* return message; +1 =>

commented-out code

주석 처리된 코드
* } +1 =>

commented-out code

주석 처리된 코드
*/ +0 => empty comment line

More details

더 자세히 보기
Comments (%)	comment_lines_density

Density of comment lines

주석 라인 밀도 =

Comment lines

주석 라인 수 / (

Lines of code

코드 라인 수 +

Comment lines

50% means that the number of lines of code equals the number of comment lines

100% means that the file only contains comment lines

주석 라인 수) * 100

With such a formula:

위의 식에 따라:

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

Public documented API (%)

public_documented_api_density

Density of public documented API

문서화 된 공용 API 밀도 = (

Public

공용 API

- Public undocumented API) / Public API

전체 수 - 문서화 되지 않은 공용 API 수) / 공용 API 전체 수 * 100
Public undocumented API	public_undocumented_api

Public API without comments header.

주석 헤더가 없는 공용 API 수
Commented-out LOC	commented_out_code_lines

Commented lines of code

Duplications

주석 처리 된 라인 수

코드 중복(Duplications)

Name	Key	Description
Duplicated blocks	duplicated_blocks

Number of duplicated blocks of lines.

For a block of code to be considered as duplicated:

Non-Java projects:

There should be at least 100 successive and duplicated tokens.

Those tokens should be spread at least on:

30 lines of code for COBOL

20 lines of code for ABAP

10 lines of code for other languages

Java projects:

There should be at least 10 successive and duplicated statements whatever the number of tokens and lines.

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)는 검사 범위에서 제외합니다.

Duplicated files

duplicated_files

Number of files involved in duplications.

중복과 연관된 파일 수
Duplicated lines	duplicated_lines

Number of lines involved in duplications.

중복과 연관된 코드 라인 수
Duplicated lines (%)	duplicated_lines_density

Density of duplication

코드 중복 밀도 =

Duplicated lines

중복된 라인 수 /

Lines

전체 라인 수 * 100

이슈(Issues)

Name	Key	Description
New issues	new_violations

Number of new issues.

신규 이슈 수
New xxxxx issues	new_xxxxx_violations

Number of new issues with severity xxxxx, xxxxx being

xxxxx 심각도의 신규 이슈 수

(xxxxx는 blocker, critical, major, minor

or

혹은 info

.

임)
Issues	violations

Number of issues.

이슈 전체 수
xxxxx issues	xxxxx_violations

Number of issues with severity xxxxx, xxxxx being

xxxxx 심각도의 이슈 전체 수

(xxxxx는 blocker, critical, major, minor

or

혹은 info

.

임)
False positive issues	false_positive_issues

Number of

false positive

issues

이슈 수
Open issues	open_issues

Number of issues whose status is Open

Open 상태의 이슈 수
Confirmed issues	confirmed_issues

Number of issues whose status is Confirmed

Confirmed 상태의 이슈 수
Reopened issues	reopened_issues

Number of issues whose status is Reopened

Severity

Reopened 상태의 이슈 수

심각도(Severity)

Severity	Description
Blocker

Operational

운영/

security

보안 리스크(risk

: This issue might make the whole application unstable in production. Ex: calling garbage collector, not closing a socket, etc.CriticalOperational/security risk: This issue might lead to an unexpected behavior in production without impacting the integrity of the whole application. Ex: NullPointerException, badly caught exceptions, lack of unit tests, etc.MajorThis issue might have a substantial impact on productivity. Ex: too complex methods, package cycles, etc.MinorThis issue might have a potential and minor impact on productivity. Ex: naming conventions, Finalizer does nothing but call superclass finalizer, etc.InfoUnknown or not yet well defined security risk or impact on productivity.

Maintainability

): 이 이슈는 실제 환경에서 운용되는 어플리케이션 전체를 불안정하게 만들 수 있습니다. 예: 가비지 컬렉터 호출, 소켓 닫지 않음 등
Critical	운영 보안 리스크(risk): 이 이슈는 실제 환경에서 운용되는 어플리케이션 전체의 무결성(integrity)에 영향을 미칠 수 있는 예상치 못한 행동으로 이어질 수 있습니다. 예: NullPointerException, 잘못 처리한 익셉션, 단위 테스트 부족 등
Major	이 이슈는 *생산성(productivity)*에 주요한(substantial) 영향을 미칠 수 있습니다. 예: 너무 복잡한 메소드, 패키지 사이클 등
Minor	이 이슈는 생산성(productivity)에 잠재적이거나 미미한 영향을 미칠 수 있습니다. 예: 네이밍 컨벤션, finalizer가 상위 클래스의 finalizer를 호출하기만 하고 아무 동작도 하지 않는 등
Info	이 이슈는 알려지지 않았거나 잘 정의되지 않은 보안 리스크 혹은 생산성에 대한 영향을 의미합니다.

유지보수성(Maintainability)

Name	Key	Description
Code Smells	code_smells

Number of code smells

코드 악취의 수.
New Code Smells	new_code_smells

Number of new code smells

신규 코드 악취의 수.
Maintainability Rating (formerly SQALE Rating)	sqale_rating

Rating given to your project related to the value of your

기술 부채 비율(Technical Debt Ratio

. The default Maintainability Rating grid is

) 값에 따른 프로젝트 등급. 기본 유지보수성 등급(Maintainability Rating)은 그리드는 다음과 같습니다:

A=

0-0

0~0.05, B=0.

06-0

06~0.1, C=0.

11-0

11~0.20, D=0.

21-0

21~0.5, E=0.

51-1

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

<=5% of the time that has already gone into the application, the rating is A

between 6 to 10% the rating is a B

between 11 to 20% the rating is a C

between 21 to 50% the rating is a D

anything over 50% is an E

51~1

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

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

Technical Debt

sqale_index

Effort to fix all maintainability issues. The measure is stored in minutes in the DB

모든 유지보수성 관련 이슈를 해결하기 위한 공수를 의미하며, 측정 값은 데이터베이스에 분 단위로 저장됩니다.
Technical Debt on new code	new_technical_debt	신규 코드의 기술 부채(Technical Debt

of new code

).
Technical Debt Ratio	sqale_debt_ratio

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)

The value of the cost to develop a line of code is 0.06 days

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

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

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

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

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

Technical Debt Ratio on new code new_sqale_debt_ratio

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

Quality Gates

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

품질 게이트(Quality Gates)

Name	Key	Description
Quality Gate Status	alert_status

State of the Quality Gate associated to your Project. Possible values are :

프로젝트에 관련된 품질 게이트(Quality Gate)의 상태. ERROR, WARN

,

및 `OK` 값을 가집니다.
Quality Gates Details	quality_gate_details

For all the conditions of your Quality Gate, you know which condition is failing and which is not.

Reliability

모든 품질 게이트의 임계 조건(condition)에 대해, 각 조건의 성공 및 실패 상태를 확인할 수 있습니다.

신뢰성(Reliability)

Name	Key	Description
Bugs	bugs

Number of bugs

버그 수.
New Bugs	new_bugs

Number of new bugs

신규 버그 수.
Reliability Rating	reliability_rating	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개
Reliability remediation effort	reliability_remediation_effort

Effort to fix all bug issues. The measure is stored in minutes in the DB

모든 버그 이슈를 해결하기 위한 공수를 의미하며, 측정 값은 데이터베이스에 분 단위로 저장합니다.
Reliability remediation effort on new code	new_reliability_remediation_effort

Same as Reliability remediation effort by on the code changed in the leak period.

Security

릭 피리어드(leak period)에서 변경된 코드에 대한 신뢰성 개선 공수(Reliability remediation effort)와 동일합니다.

보안성(Security)

Name	Key	Description
Vulnerabilities	vulnerabilities

Number of vulnerabilities

취약점(vulnerabilities) 수.
New Vulnerabilities	new_vulnerabilities

Number of new vulnerabilities

신규 취약점 수.
Security Rating	security_rating	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개
Security remediation effort	security_remediation_effort

Effort to fix all vulnerability issues. The measure is stored in minutes in the DB

모든 취약점 이슈를 해결하기 위한 공수를 의미하며, 측정 값은 데이터베이스에 분 단위로 저장합니다.
Security remediation effort on new code	new_security_remediation_effort

Same as

릭 피리어드(leak period)에서 변경된 코드에 대한 보안성 개선 공수(Security remediation effort

by on the code changed in the leak period

)와 동일합니다.

Metric	Key	Description
Classes	classes

Number of classes (including nested classes, interfaces, enums and annotations

클래스 수(중첩된 클래스(`classes`), 인터페이스(`interfaces`), 이넘(`enums`) 및 애너테이션(`annotations`) 포함).
Directories	directories

Number of directories

디렉토리 수.
Files	files

Number of files

파일 수.
Lines	lines

Number of physical lines (number of

물리적인 라인 수(캐리지 리턴(carriage returns) 수).
Lines of code	ncloc

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

Lines of code per language

ncloc_language_distribution

Non Commenting Lines of Code Distributed By Language

언어별 비 주석 코드 라인 분포
Methods	functions

Number of functions. Depending on the language, a function is either a function or a method or a paragraph

함수 수. 프로그래밍 언어에 따라 함수(function), 메소드(method) 혹은 패러그래프(paragraph) 값일 수 있음.

More details

Projects projects

Number of projects in a view

뷰의 프로젝트 수.
Public API	public_api

Number of public Classes + number of public Functions + number of public Properties

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

More details

Statements statements

Number of statements

구문(statement) 수.

More details

테스트(Tests)

Metric	Key	Description
Condition coverage	branch_coverage

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)제어 구조에 존재 가능한 조건의 모든 경우를 의미합니다.

Condition coverage = (CT + CF) / (2*B)

where

위 공식에서,

CT =

conditions that have been evaluated to 'true' at least once
CF = conditions that have been evaluated to 'false' at least once

B = total number of conditions

최소 1회 이상 "true"로 평가된 조건
CF = 최소 1회 이상 "false"로 평가된 조건
B = 조건의 총 합

Condition coverage on new code new_branch_coverage

Identical to Condition coverage but restricted to new / updated source code

조건 커버리지(Condition coverage)와 동일하나, 신규 혹은 업데이트 한 코드로 범위를 한정합니다.
Condition coverage hits	branch_coverage_hits_data

List of covered conditions

커버 된 조건 리스트.
Conditions by line	conditions_by_line

Number of conditions by line

코드 라인 당 조건 수.
Covered conditions by line	covered_conditions_by_line

Number of covered conditions by line

코드 라인 당 커버된 조건 수.
Coverage	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?

)를 조합한 지표. 이 지표는 '단위 테스트로 얼마나 많은 코드를 커버했는가?'에 대한 답을 얻기 위해 사용합니다.

Coverage = (CT + CF + LC)/(2*B + EL)

where

위 공식에서,

CT =

conditions that have been evaluated to

최소 1회 이상 'true'

at least once

로 평가된 조건
CF =

conditions that have been evaluated to

최소 1회 이상 'false'

at least once

로 평가된 조건
LC = covered lines = lines_to_cover - uncovered_lines

B =

total number of conditions

조건의 총 수
EL =

total number of executable lines

실행 가능한 총 코드 라인 수 (lines_to_cover)

Coverage on new code new_coverage

Identical to Coverage but restricted to new / updated source code

커버리지(Coverage)와 동일하나, 신규 및 업데이트 된 코드로 범위를 한정합니다.
Line coverage	line_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)는 주어진 코드 라인에 대해 '단위 테스트를 수행하는 동안, 이 코드 라인이 실행되었는가?'를 판단하며, 단위 테스트가 커버한 라인의 비율을 의미합니다:

Line coverage = LC / EL

where

위 공식에서,

LC = covered lines (lines_to_cover - uncovered_lines)
EL =

total number of executable lines

실행 가능한 총 코드 라인 수 (lines_to_cover)

Line coverage on new code new_line_coverage

Identical to Line coverage but restricted to new / updated source code

라인 커버리지(Line coverage)와 동일하나, 신규 및 업데이트 된 코드로 범위를 한정합니다.
Line coverage hits	coverage_line_hits_data

List of covered lines

커버된 라인 목록.
Lines to cover	lines_to_cover

Number of lines of code which could be covered by unit tests (for example, blank lines or full comments lines are not considered as lines to cover

단위 테스트에 의해 커버된 코드 라인 수(예: 빈 라인 혹은 전체 주석 라인은 커버해야 할 라인으로 계산하지 않음).
Lines to cover on new code	new_lines_to_cover

Identical to

커버해야 할 라인의 수(Lines to cover

but restricted to new / updated source code

)와 동일하나, 신규 및 업데이트 된 코드로 범위를 한정합니다.
Skipped unit tests	skipped_tests

Number of skipped unit tests

스킵한 단위 테스트 수.
Uncovered conditions	uncovered_conditions

Number of conditions which are not covered by unit tests

단위 테스트로 커버되지 않은 조건의 수.
Uncovered conditions on new code	new_uncovered_conditions

Identical to Uncovered conditions but restricted to new / updated source code

커버되지 않은 조건의 수(Uncovered conditions)와 동일하나, 신규 및 업데이트 된 코드로 범위를 한정함.
Uncovered lines	uncovered_lines

Number of lines of code which are not covered by unit tests

단위 테스트로 커버되지 않은 코드 라인 수.
Uncovered lines on new code	new_uncovered_lines

Identical to Uncovered lines but restricted to new / updated source code

커버되지 않은 라인 수(Uncovered lines)와 동일하나, 신규 및 업데이트 된 코드로 범위를 한정함.
Unit tests	tests

Number of unit tests

단위 테스트 수.
Unit tests duration	test_execution_time

Time required to execute all the unit tests

모든 단위 테스트를 수행하기 위해 필요한 시간.
Unit test errors	test_errors

Number of unit tests that have failed

실패한 단위 테스트 수.
Unit test failures	test_failures

Number of unit tests that have failed with an unexpected exception

예상하지 않은 익셉션으로 실패한 단위 테스트 수.
Unit test success density (%)	test_success_density	테스트 성공 밀도(Test success density) = (Unit tests - (Unit test errors + Unit test failures)) / Unit tests * 100

The same kinds of metrics exist for 통합 테스트 커버리지(Integration tests coverage and ) 및 전체 테스트 커버리지(Overall tests coverage (= Units tests + Integration tests) .Metrics on test execution do not exist for Integration tests and Overall tests지표에 대해서도 동일한 메트릭을 제공합니다.

단, 통합 테스트와 전체 테스트에 대한 테스트 실행 메트릭은 제공하지 않습니다.

Version	Old Version 1	New Version Current
Changes made by	Moses Kim	Moses Kim
Saved on	2017/04/03	2017/07/04

Content Comparison

Versions Compared

Key

복잡도(Complexity)

문서화(Documentation)

코드 중복(Duplications)

이슈(Issues)

심각도(Severity)

유지보수성(Maintainability)

품질 게이트(Quality Gates)

신뢰성(Reliability)

보안성(Security)

테스트(Tests)