코드 소스 라인

이 문서에는 여러 가지 문제가 있습니다.개선을 돕거나 토크 페이지에서 이러한 문제에 대해 논의해 주십시오.(이러한 템플릿메시지를 삭제하는 방법과 타이밍에 대해 설명합니다) 이 기사의 리드 섹션이 너무 짧아서 요점을 적절하게 요약할 수 없을 수 있습니다. 이 기사의 모든 중요한 측면에 대한 접근 가능한 개요를 제공하기 위해 잠재 고객을 확대하는 것을 검토해 주십시오. (2012년 4월) 이 글은 검증을 위해 추가 인용문이 필요합니다. 신뢰할 수 있는 출처에 인용문을 추가하여 이 기사를 개선하는 데 도움을 주십시오. 조달되지 않은 자재는 제거될 수 있습니다.출처 : "코드 소스 라인"– 뉴스 · 신문 · 서적 · 학자 · JSTOR (2010년 2월) (이 템플릿메시지 삭제 방법 및 삭제 시기 확인) 이 문서에는 무차별, 과도 또는 무관한 예가 포함될 수 있습니다. 설명문을 더 추가하고 관련성이 낮은 예시를 삭제하여 기사를 개선해 주십시오. 더 나은 문서를 작성하려면 Wikipedia의 가이드를 참조하십시오.(2012년 5월) (이 템플릿메시지를 삭제하는 방법과 타이밍을 확인합니다)

코드 라인(SLOC)은 코드 라인(Lines of Code, LOC)이라고도 하며 프로그램의 소스 코드 텍스트에 있는 줄 수를 세어 컴퓨터 프로그램의 크기를 측정하는 데 사용되는 소프트웨어 메트릭입니다.SLOC는 일반적으로 프로그램 개발에 필요한 작업량을 예측하고 소프트웨어 제작 후 프로그래밍 생산성 또는 유지관리 가능성을 추정하기 위해 사용됩니다.

측정 방법

많은 유용한 비교에는 프로젝트에서 코드 행의 크기 순서만 포함됩니다.코드 라인을 사용하여 10,000 라인 프로젝트를 10,000 라인 프로젝트와 비교하는 것이 20,000 라인 프로젝트를 21,000 라인 프로젝트와 비교하는 것보다 훨씬 유용합니다.코드의 행의 측정 방법에 대해서는, 확실히 논란의 여지가 있습니다만, 그 정도의 차이는 소프트웨어의 복잡성이나 공수의 명확한 지표가 될 수 있습니다.

SLOC 측정에는 물리 SLOC(LOC)와 논리 SLOC(LOC)의 두 가지 주요 유형이 있습니다.이 두 가지 척도의 구체적인 정의는 다양하지만 물리적 SLOC의 가장 일반적인 정의는 주석 ^[1]행을 제외한 프로그램의 소스 코드 텍스트에 있는 줄 수이다.

논리 SLOC는 실행 가능한 "문"의 수를 측정하려고 시도하지만, 그 특정 정의는 특정 컴퓨터 언어에 관련되어 있습니다(C와 유사한 프로그래밍 언어에 대한 간단한 논리 SLOC 척도의 하나는 문을 종단하는 세미콜론의 수입니다).물리적 SLOC를 측정하는 도구를 만드는 것이 훨씬 쉽고 물리적 SLOC 정의를 설명하는 것이 더 쉽습니다.단, 물리 SLOC 측정은 논리 SLOC보다 논리적으로 무관한 형식 및 스타일 규칙에 더 민감합니다.단, SLOC 측정은 정의를 제시하지 않고 기술되는 경우가 많으며 논리적 SLOC는 종종 물리적 SLOC와 크게 다를 수 있다.

SLOC를 결정할 때 발생하는 모호성의 예로서 다음 C 코드 조각이 있다고 생각해 주십시오.

위해서 (i = 0; i < > 100; i++) 인쇄물("안녕하세요"); /* 이것은 몇 줄의 코드입니까?*/ 

이 예에서는 다음과 같이 되어 있습니다.

• 물리 코드 라인(LOC)x 1
• 2개의 논리라인 오브코드(LLOC) (스테이트먼트 및 printf스테이트먼트용),
• 댓글 1줄

프로그래머와 코딩 표준에 따라 위의 코드 "라인"은 여러 줄에 작성될 수 있습니다.

/* 코드 행은 몇 줄입니까?*/ 위해서 (i = 0; i < > 100; i++) {     인쇄물("안녕하세요"); } 

이 예에서는 다음과 같이 되어 있습니다.

• 4개의 물리적 코드 라인(LOC): 교정기 설치는 추정할 수 있습니까?
• 2개의 논리 코드 행(LOC): 스테이트먼트 이외의 행을 작성하는 작업은 모두 어떻게 됩니까?
• 1개의 코멘트 행: 툴은 코멘트 배치에 관계없이 모든 코드와 코멘트를 고려해야 합니다.

"논리적인" SLOC 값과 "물리적" SLOC 값에도 다양한 정의가 있을 수 있습니다.Robert E. Park(소프트웨어 엔지니어링 연구소 재직 중)와 다른 사람들은 프로젝트에서 사용되는 SLOC 측정을 신중하게 설명하고 정의할 수 있도록 SLOC 값을 정의하는 프레임워크를 개발했습니다.예를 들어 대부분의 소프트웨어 시스템은 코드를 재사용하며, 조치를 보고할 때 포함할 재사용 코드를 결정하는 것이 중요합니다.

오리진스

사람들이 SLOC를 메트릭으로 사용하기 시작했을 때, FORTRAN이나 어셈블리 언어처럼 가장 일반적으로 사용되는 언어는 라인 지향 언어였습니다.이러한 언어는 펀치 카드가 프로그래밍을 위한 데이터 입력의 주요 형태였던 당시에 개발되었습니다.하나의 펀치 카드는 보통 한 줄의 코드를 나타냅니다.그것은 쉽게 셀 수 있는 하나의 분리된 물체였다.이는 프로그래머의 눈에 보이는 출력이었기 때문에 매니저에게는 프로그래머의 생산성 측정값으로 코드 줄을 세는 것이 의미가 있었고 심지어 "카드 이미지"와 같은 것을 언급하기도 했다.오늘날 가장 일반적으로 사용되는 컴퓨터 언어는 포맷에 더 많은 여유를 줍니다.텍스트 행은 더 이상 80 또는 96개의 열로 제한되지 않으며 텍스트 한 행이 코드 한 줄에 해당되지 않습니다.

SLOC 조치의 사용

이 기사에는 편파적이거나 검증 불가능한 정보를 수반하는 애매한 표현이 포함되어 있다. 이러한 진술은 명확해지거나 삭제되어야 한다.(2013년 9월)

SLOC 조치는 특히 때때로 오용되는 방식에서 다소 논란이 있다.실험은 노력이 SLOC와^{[citation needed]} 높은 상관관계를 갖는다는 것을 거듭 확인했습니다. 즉, SLOC 값이 큰 프로그램은 개발하는 데 더 많은 시간이 소요됩니다.따라서 SLOC는 작업 추정에 효과적일 수 있습니다.단, SLOC와 기능적인 관련성은 낮습니다.숙련 개발자는 코드 수가 훨씬 적은 동일한 기능을 개발할 수 있습니다.따라서 SLOC가 적은 프로그램이 다른 유사한 프로그램보다 더 많은 기능을 나타낼 수 있습니다.SLOC를 생산성 척도로 간주하는 것에는 주의가 필요합니다.개발자는 몇 개의 라인만 개발할 수 있고 기능 면에서는 더 많은 라인(일반적으로 더 많은 노력을 들인 개발자)보다 훨씬 더 생산적이기 때문입니다.우수한 개발자는 여러 코드 모듈을 하나의 모듈에 병합하여 시스템을 개선하지만 코드를 제거하므로 생산성이 저하될 수 있습니다.또한 경험이 부족한 개발자는 코드 복제에 의존하는 경우가 많습니다. 이는 버그가 발생하기 쉽고 유지 보수 비용이 많이 들기 때문에 매우 권장되지 않지만 결과적으로 SLOC가 높아집니다.

SLOC 카운트는 언어를 정규화하기 위해 조정 계수를 적용하지 않는 한 다른 언어로 작성된 프로그램을 비교할 때 더 정확한 문제를 일으킵니다.다양한 컴퓨터 언어에 따라 간결함과 명료함의 밸런스가 다릅니다.대부분의 어셈블리 언어에서는 APL의 몇 글자와 같은 작업을 수행하려면 수백 줄의 코드가 필요합니다.다음 예시는 C로 작성된 "hello world" 프로그램과 특히 상세하다고 알려진 언어인 COBOL로 작성된 동일한 프로그램을 비교한 것입니다.

#실패하다 <stdio.h>  인트 주된() {     인쇄물("\n안녕 세계\n"); } 

      신분증 나누기.       프로그램 ID. 안녕 .       절차. 나누기.       표시'헬로 월드'       돌아가.       끝. 프로그램. 안녕 . 

SLOC 메트릭을 비교할 때 자주 발생하는 또 다른 문제는 자동 생성 코드와 수기 코드 간의 차이입니다.최신 소프트웨어 툴에는 마우스 클릭 몇 번으로 대량의 코드를 자동 생성할 수 있는 기능이 있습니다.예를 들어 그래픽 사용자 인터페이스 빌더는 아이콘을 워크스페이스로 드래그하는 것만으로 그래픽 제어 요소의 모든 소스 코드를 자동으로 생성합니다.예를 들어 이 코드를 작성하는 작업은 디바이스 드라이버를 기술하는 데 필요한 작업과 비교할 수 없습니다.같은 토큰으로 수작업으로 코딩된 커스텀 GUI 클래스는 단순한 디바이스 드라이버보다 부하가 높은 경우가 있기 때문에 이 메트릭의 단점이 있습니다.

SLOC를 입력 매개 변수로 사용하는 여러 비용, 일정 및 노력 추정 모델이 있습니다. 여기에는 Barry Boehm 등이 널리 사용하는 COCOMO(Constructive Cost Model) 시리즈, PRICE Systems True S 및 Galorath의 SEER-SEM 등이 포함됩니다.이러한 모델은 우수한 예측력을 보여 주었지만, 제공된 추정치(특히 SLOC 추정치)만큼만 우수합니다.많은^[2] 사람들이 기능 척도로 SLOC 대신 기능 포인트를 사용하는 것을 지지해 왔지만, 기능 포인트는 SLOC와 높은 상관관계를 가지기 때문에(자동으로 측정할 수 없기 때문에) 이는 보편적으로 받아들여지는 관점이 아닙니다.

예

Vincent Maraia에 ^[3]따르면 Microsoft Windows NT 제품 라인의 다양한 운영 체제의 SLOC 값은 다음과 같습니다.

데이비드 A.Wheeler는 Linux 운영 체제의 Red Hat 배포를 조사하여 Red Hat Linux 버전 7^[6].1(2001년 4월 출시)에 3,000만 이상의 물리 SLOC가 포함되어 있다고 보고했습니다.또, 종래의 독자적인 수단에 의해 개발되었다면, 약 8,000명의 인력의 개발 노력이 필요하게 되어, 10억달러(2000년 미화) 이상의 코스트가 들 것이라고 추측했습니다.

비슷한 연구가 나중에 Debian GNU/Linux 버전 2.2 ("Potato"라고도 함)에 대해 이루어졌습니다. 이 운영 체제는 원래 2000년 8월에 출시되었습니다.이 연구에 따르면 Debian GNU/Linux 2.2에는 5,500만 이상의 SLOC가 포함되어 있으며, 기존의 독점적인 방식으로 개발될 경우 14,005명이 필요하고 개발에 19억 달러가 소요됩니다.이후 사용된 툴의 실행 결과 Debian의 다음 릴리스는 1억400만 SLOC이며, 2005년 현재^[update] 최신 릴리스에는 2억1300만 SLOC가 포함될 예정입니다.

효용.

이 섹션에는 독창적인 연구가 포함되어 있을 수 있습니다. 클레임을 확인하고 인라인 인용을 추가하여 개선해 주십시오. 독창적인 조사로만 구성된 문장은 삭제해야 합니다. (2011년 4월) (이 템플릿메시지를 삭제하는 방법과 타이밍에 대해 알아보기)

이점

1. 카운트 자동화 범위: 코드 라인은 물리적인 엔티티이기 때문에 카운트 프로세스를 자동화함으로써 수동 카운트 작업을 쉽게 줄일 수 있습니다.프로그램의 LOC 카운트를 위해 소규모 유틸리티를 개발할 수 있습니다.그러나 특정 언어용으로 개발된 논리 코드 카운트 유틸리티는 언어 간의 구문 및 구조 차이로 인해 다른 언어에서는 사용할 수 없습니다.단, 물리 LOC 카운터는 수십 개의 언어를 카운트하는 생성되었습니다.
2. 직관적인 측정 기준: 코드 라인은 소프트웨어의 크기를 측정하는 직관적인 측정 기준 역할을 합니다. 소프트웨어의 크기를 확인할 수 있고 그 효과를 시각화할 수 있기 때문입니다.함수점은 물리적 실체로 상상할 수 없고 논리적 공간에만 존재하는 객관적 지표에 가깝다고 한다.이와 같이 LOC는 경험이 적은 프로그래머들 사이에서 소프트웨어의 크기를 표현할 때 유용합니다.
3. 유비쿼터스 대책: ^[15]LOC 대책은 소프트웨어의 초창기부터 있어 왔습니다.따라서 다른 크기 측정보다 더 많은 LOC 데이터를 사용할 수 있다는 것은 논쟁의 여지가 있다.

단점들

1. 설명 책임의 결여: 코드 라인 측정에는 몇 가지 근본적인 문제가 있습니다.일반적으로 전체 ^{[citation needed]}작업의 30%에서 35%에 불과한 코딩 단계의 결과만 사용하여 프로젝트의 생산성을 측정하는 것은 유용하지 않다고 생각하는 사람도 있습니다^[who?].
2. 기능성과의 응집력 결여: 실험은^{[by whom?]} 노력이 LOC와 높은 상관관계가 있는 반면 기능성은 LOC와 덜 상관관계가 있다는 것을 반복적으로 확인했습니다.즉, 숙련된 개발자는 훨씬 적은 코드로 동일한 기능을 개발할 수 있기 때문에 LOC가 적은 프로그램이 다른 유사한 프로그램보다 더 많은 기능을 나타낼 수 있습니다.특히 LOC는 개인의 생산성 지표로 불충분합니다.왜냐하면 적은 라인을 개발하는 개발자가 더 많은 코드를 만드는 개발자보다 더 생산적이기 때문입니다.용장된 코드를 제거하고 깨끗한 상태를 유지하기 위한 "Extract 방법"과 같은 좋은 리팩터링은 대부분 코드 행을 줄입니다.
3. 견적에 대한 악영향: #1에 제시된 사실 때문에 코드행에 기초한 견적이 잘못될 가능성이 높습니다.
4. 개발자의 경험: 특정 논리의 구현은 개발자의 경험 수준에 따라 다릅니다.따라서 코드 행의 수는 개인마다 다릅니다.경험이 풍부한 개발자는 같은 언어를 사용하지만 상대적으로 경험이 적은 다른 개발자에 비해 적은 수의 코드로 특정 기능을 구현할 수 있습니다.
5. 언어의 차이: 동일한 기능을 제공하는 두 가지 응용 프로그램(화면, 보고서, 데이터베이스)을 고려하십시오.애플리케이션 중 하나는 C++로 작성되고 다른 하나는 COBOL과 같은 언어로 작성됩니다.기능 포인트의 수는 완전히 동일하지만 응용 프로그램의 측면이 다릅니다.애플리케이션을 개발하는 데 필요한 코드 행은 분명 같지 않을 것입니다.그 결과, 애플리케이션 개발에 필요한 작업량은 다릅니다(기능 포인트당 시간).코드 줄과 달리 함수 점의 수는 일정하게 유지됩니다.
6. GUI 툴의 등장: GUI 기반의 프로그래밍 언어 및 Visual Basic 등의 툴이 등장함에 따라 프로그래머는 비교적 적은 코드를 쓸 수 있게 되어 높은 수준의 기능을 얻을 수 있게 되었습니다.예를 들어, GUI 도구를 가진 사용자는 창을 만들고 버튼을 그리는 프로그램을 작성하는 대신 드래그 앤 드롭 및 기타 마우스 조작을 사용하여 워크스페이스에 컴포넌트를 배치할 수 있습니다.GUI 툴에 의해 자동으로 생성되는 코드는 LOC 측정 방법을 사용할 때 고려되지 않습니다.이로 인해 언어마다 차이가 생깁니다.한 언어에서 한 줄의 코드(또는 전혀 코드가 없음)로 수행할 수 있는 동일한 작업을 다른 언어에서 여러 줄의 코드가 필요할 수 있습니다.
7. 다국어 문제: 오늘날의 소프트웨어 시나리오에서는 소프트웨어가 여러 언어로 개발되는 경우가 많습니다.복잡성과 요건에 따라 여러 언어가 사용되는 경우가 많습니다.이 경우 시스템 통합 후 특정 언어에 결함이 발생한다고 볼 수 없기 때문에 생산성과 결함률을 추적 및 보고하는 것은 심각한 문제가 됩니다.이 경우 함수점이 크기를 측정하는 가장 좋은 척도가 됩니다.
8. 계수 기준의 결여: 코드 라인에 대한 표준 정의는 없습니다.댓글도 포함되나요?데이터 선언이 포함되어 있습니까?문장이 여러 줄에 걸쳐 있으면 어떻게 됩니까?– 이는 자주 발생하는 질문입니다.SEI 및 IEEE 등의 조직은 계수를 표준화하기 위해 몇 가지 지침을 발표했지만, 특히 매년 새로운 언어가 도입되고 있는 상황에서 이러한 지침을 실천하기는 어렵습니다.
9. 심리학: 생산성이 코드 행으로 측정되는 프로그래머는 불필요하게 상세한 코드를 작성하도록 동기를 부여합니다.관리자들이 코드 라인에 집중할수록 프로그래머는 불필요한 복잡성으로 코드를 확장해야 합니다.이는 복잡성이 증가하면 유지 보수 비용이 증가하고 버그 수정에 필요한 작업이 증가할 수 있기 때문에 바람직하지 않습니다.

PBS 다큐멘터리 "Trump of the Nerds"에서 마이크로소프트 이그제큐티브 Steve Ballmer는 코드 줄을 세는 것을 비판했습니다.

IBM의 소프트웨어에는 K-LOC를 셀 필요가 있다는 종교가 있습니다. K-LOC는 천 줄의 코드입니다.얼마나 큰 프로젝트입니까?오, 이건 일종의 10K-LOC 프로젝트야.이것은 20K-LOCer 입니다.이것은 50K-LOC입니다.그리고 IBM은 우리가 어떻게 돈을 받는지에 대해 일종의 종교로 만들고 싶어했습니다.OS/2로 얼마나 벌었는지, 얼마나 벌었는지.K-LOC 몇 개 했어?그리고 우리는 개발자가 좋은 아이디어를 가지고 있고, 20K-LOC가 아닌 4K-LOC로 무언가를 할 수 있다는 것을 설득하기 위해 계속 노력했습니다.저희는 돈을 적게 벌어야 할까요?더 작고 빠르게 K-LOCs를 덜 만들었기 때문입니다 K-LOCs, K-LOCs, 그게 방법론입니다으악! 어쨌든, 그 모든 것을 생각하면 항상 등이 오그라든다.

컴퓨터 역사 박물관에 의하면, 1982년에 Apple의 개발자인 Bill Atkinson은 이러한 관행에서 문제를 발견했다고 합니다.

1982년 리사 팀이 소프트웨어 완성을 추진하고 있을 때 프로젝트 매니저들은 프로그래머들에게 작성한 코드 줄 수를 보고하는 매주 양식을 제출하도록 요구하기 시작했습니다.빌 앳킨슨은 그것이 어리석다고 생각했다.QuickDraw의 지역 계산 루틴을 6배 더 빠르고 2000줄 더 짧게 고쳐 쓴 주에 그는 폼에 "-2000"을 넣었다.몇 주 더 지나자 매니저들이 그에게 양식 작성을 요구하는 것을 멈추었고, 그는 기꺼이 응했다.^[16][17]

관련 용어

• KLOC / kellkk / KAY-lock : 1,000줄의 코드
  • KDLOC: 1,000줄의 코드 제공
  • KSLOC: 1,000줄의 코드 소스
• MLOC: 100만 줄의 코드
• GLOC: 1,000,000 행의 코드

「 」를 참조해 주세요.

• 소프트웨어 개발 작업 평가
• 견적(프로젝트 관리)
• 소프트웨어 엔지니어링 비용 견적

메모들

레퍼런스

추가 정보

• Li, Luo; Herbsleb, Jim; Shaw, Mary (May 2005). Forecasting Field Defect Rates Using a Combined Time-based and Metric–based Approach a Case Study of OpenBSD (CMU-ISRI-05-125). Carnegie-Mellon University.
• McGraw, Gary (March–April 2003). "From the Ground Up: The DIMACS Software Security Workshop". IEEE Security & Privacy. 1 (2): 59–66. doi:10.1109/MSECP.2003.1193213.
• Park, Robert E.; et al. "Software Size Measurement: A Framework for Counting Source Statements". Technical Report CMU/SEI-92-TR-20.

외부 링크

• RSM(Practical Source Lines of Code Resource Standard Metrics)의 정의는 프로그래밍 스타일에 관계없이 "유효한 코드 행"을 현실적 코드 메트릭으로 정의합니다.
• RSM을 사용하는 일반적인 오픈 소스 소프트웨어 Linux 커널 2.6.17, Firefox, Apache HTTPD, MySQL, PHP의 유효한 코드 eLOC 메트릭.
• Wheeler, David A. "SLOCCount". Retrieved 2003-08-12.
• Wheeler, David A. (June 2001). "Counting Source Lines of Code (SLOC)". Retrieved 2003-08-12.
• Tanenbaum, Andrew S. Modern Operating Systems (제2판)프렌티스 홀.ISBN 0-13-092641-8.
• Howard Dahdah (2007-01-24). "Tanenbaum outlines his vision for a grandma-proof OS". Archived from the original on 2007-01-27. Retrieved 2007-01-29.
• C. M. Lott. "Metrics collection tools for C and C++ Source Code". Archived from the original on June 19, 2020.
• Folklore.org: Macintosh 스토리: -2000 줄 오브 코드