음수 코드 란 무엇입니까?

답변:

501

중복을 제거하거나 더 간결한 구문을 사용하여 코드 줄을 줄이는 것을 의미합니다.

예를 들어 원래 Apple Lisa 개발자 팀의 유명한 일화 를 참조하십시오 .

Lisa 팀이 1982 년에 소프트웨어를 완성하려고하자 프로젝트 관리자는 프로그래머가 작성한 코드 줄 수에 대한 주간 양식을 제출하도록 요구했습니다. 빌 앳킨슨 (Bill Atkinson)은 이것이 어리 석다고 생각했습니다. 그는 QuickDraw의 영역 계산 루틴을 6 배 더 빠르고 2000 줄 더 짧게 재 작성한 주 동안 "-2000"을 양식에 넣었습니다. 몇 주 후에 관리자들은 그에게 양식을 작성하라는 요청을 중단하고 기꺼이 응했다.

— 틸로
소스
257
더 이상 추가해야 할 것이 아니라 남은 것이 없을 때 완벽이 이루어집니다.- Antoine de Saint-Exupéry
— systempuntoout
7
#LOC는 코드 품질을 측정하는 좋은 방법입니까? C 또는 C ++ 코드를 '최소화'하고 줄 수를 크게 줄일 수는 있지만 유지 관리하는 것은 악몽입니다.
— JBR 윌킨슨
8
@systempuntout-그리고 나서 아인 스텐의 "(과학 이론)은 가능한 한 단순해야하지만 더 단순해서는 안됩니다"
— Jonathan Day
32
없는 코드보다 더 빠르게 실행되거나 더 안정적이거나 유지 관리가 덜 필요한 것은 없습니다. "의심 할 때 그것을 제압하라!"
— TMN
4
@JBRWilkinson : 코드 간결함에 관한 "스위트 스팟"이 있다고합니다. 일반적으로 짧을수록 좋습니다. 그러나 코드가 너무 간결 해져서 다른 프로그래머가 쉽게 해독 할 수없는 시점이 있습니다.
— GordonM
131

코드 단위로 프로그래머 생산성을 측정하는 라인에는 빌 게이츠 (Bill Gates)의 인용문이 있습니다.

LOC 메트릭이 너무 긴 언어를 사용하고 할당량을 충족시키기 위해 의도적으로 바퀴를 재창조하도록 장려했다고 덧붙이고 싶습니다.

— 키랄 레사
소스
30
예, 그것은 어떤 종류의 메트릭의 문제입니다. 사람들의 성과를 판단하기 위해 그것들을 사용하자마자, 그들은 숫자 게임을 시작합니다.
5
실제로 LOC를 성능 지표로 사용한 사람이 있습니까? 나는 "우리가 여기서 말하는 프로젝트의 버그는 무엇입니까?"
— Michael Borgwardt
5
@ 마이클 : 예. 불행히도, 그렇습니다.
— Michael Petrotta
4
우리는 그 은유에 의해 10000 GTON 제트기를 생산하는 회사를 가진 동일한 Bill G에 대해 이야기하고 있습니까? :)
— Daniel Mošmondor
37
우주 왕복선의 온보드 컴퓨터 용 코드를 작성한 프로그래머가 소프트웨어의 무게를 설명해야한다고 말했습니다. 소프트웨어는 실제적이었습니다 (돈을 지불했습니다). 그것은 셔틀에 있었다; 셔틀에 적재 된 모든 중량을 고려해야합니다. 코드 가중치로 프로그래머 생산성을 측정하는 첫 번째 예입니다. (제로는 허용되지 않았으므로 0.00001 그램을 지정했고 모두 만족 스러웠습니다.)
— Mark Lutton
118

제가 고등학교에 다닐 때, 그리고 예, 우리는 70 년대에 컴퓨터를 가지고 있었지만 돌 칼을 사용하여 동물의 가죽으로 컴퓨터를 만들어야했지만 수학 교사 중 한 명이 프로그래밍 콘테스트를 진행했습니다. 규칙은 우승 프로그램이 올바른 출력을 생성하고 코드 시간 라인의 실행 시간이 가장 작은 프로그램이라는 것이 었습니다. 즉, 프로그램이 100 줄의 코드를 사용하여 5 초 동안 실행하면 점수는 500이됩니다. 다른 사람이 90 줄의 코드를 작성하고 6 초 동안 실행하면 점수는 540이됩니다. 골프와 같이 낮은 점수가 이깁니다.

간결함과 성능을 모두 보상하는 뛰어난 점수 시스템으로 저를 놀라게했습니다.

그러나 기술적으로 우승 기준을 충족 한 출품작은 실격되었다. 문제는 100 미만의 모든 소수 목록을 인쇄하는 것이 었습니다. 실격 된 출품작은 다음과 같이 진행되었습니다 (대부분의 학생들은 BASIC을 사용했습니다).

100 print "2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61,"
110 print "67, 71, 73, 79, 83, 87, 89, 91, 97"

이 글을 쓴 학생은 짧고 매우 효율적일뿐만 아니라 프로그래밍에 대한 최소한의 지식 만 있으면 누구나 프로그램을 유지 관리 할 수 ​​있도록 알고리즘이 분명해야한다고 지적했습니다.

— 어치
소스
10
더 많은 증거 코드의 라인을 계산하는 것은 매우 gameable 메트릭 :-)입니다
44
그 기본 프로그램은 훌륭합니다! 교사가 프로그램의 자격을 상실한 것은 오히려 화나고 있습니다. 결국, 룩업 테이블 (프로그램과 다소 유사)은 실제 프로그래밍에서 확실히 찾을 수 있습니다.
— 녹 티스 스카이 타워
6
현명한 교사는이 기본 프로그램을 받아 들여 SRS 권리를 얻는 것의 중요성을 강조하기 위해이를 사용했을 것입니다. 팀과 함께 좌절감을 느낀 야구 코치를 생각 나게한다. 그는 경기를 보여주고, 타자를 치고, 3 번의 스트라이크를했고, 외면하지 말고, 그의 팀에게 소리 쳤다. ***** 지금 플레이 중입니다. 이제 방망이를 가지고 올바르게 플레이하세요! ". 또한 "창조자가 창작자를보고 얼굴을 붉혔다"라고 쓴 사람과 '와인'에 대한 에세이 공모전을 수상한 사람을 생각 나게합니다.
— Nav
3
@Nav : 같은 방식으로 시작되는 비슷한 이야기를 떠올리게합니다. 그런 다음 코치는 공중에 공을 던지고 스윙하고 그리워합니다. 그는 다시 공중에 던지고 스윙하고 그리워합니다. 그는 그것을 공중에 세 번 던지고 스윙하고 그리워합니다. 그런 다음 그는 팀에게 "너는 어떻게 투구해야하는지 봐!"라고 말합니다. (이 이야기가 소프트웨어 개발과 어떤 관련이 있을지 모르겠습니다.)
— Jay
13
이 자격을 박탈 당하면 꽤 화를 낼 것입니다. 결정 론적 문제는 결정 론적 솔루션이 필요합니다. 'Hello World'앱을 작성할 때 'Hello'의 철자가 올바른지 여부를 확인하기 위해 코딩하지 않습니다.
— Kirk Broadhurst
34

혀가 뺨입니다. 평균 코드 라인 당 $ N의 비용이 든다면 "네거티브 라인"을 코딩하는 것이 확실히 승자입니다.

이것은 실제적인 조언으로서, 작업을 수행하는 작은 코드가 동일한 일을하는 큰 코드보다 훨씬 뛰어나다는 것을 의미합니다.

— 아이락 박스터
소스
2
나는 당신이 어디에서 왔는지 알지만 간결하고 이해하기 쉬운 작은 발자국 코드는 한 번에 거의 달성되지 않습니다. 그것은 일반적으로 작동하도록 (많은 라인), 속도를 최적화 (약간 더 적은 라인) 유지 관리 / 가독성을 위해 최적화합니다 (더 적은 라인). 긴 투자 수익으로 인한 실제 비용은 두 번째 및 세 번째 단계이므로 종종 완전히 건너 뜁니다. 그것은 "싸고 빠르며 좋다-둘을 선택할 수있다"와 같다.
2
실제로 유지 관리 / 가독성에 최적화 된 IME는 실제로 자체 문서화를 위해 코드를 다시 작성하면 더 장황하게 보이기 때문에 실제로 LOC를 증가시킬 수 있습니다 .
1
@Visage : "... 다른 모든 것들은 동등하다".
— Ira Baxter
요점은, 다른 모든 것들은 간결한 코드와 자세한 코드 사이에서 같을 수 없다는 것입니다.
— Tomas Narros
평균 코드 줄이 $ N 인 이유는 처음 X줄을 쓰는 데 시간을 소비하기 때문 입니다. 그런 다음 여러 번 반복하여 최종 제품을 Y줄 단위 로 줄입니다. 따라서 (X-Y)리팩토링의 대학살이 모든 균열을 없애기 때문에 나머지 라인은 매우 비용이 많이 드는 것으로 보입니다.
27

적은 코드로 동일한 프로그램을 작성하는 것은 모든 사람의 목표입니다.

프로그램이 코딩에 200 LOC를 사용하고 150으로 작성하면 -50 LOC를 썼습니다. 그래서 부정적인 코드를 썼습니다.

— 루카 비
소스
3
또한 적은 LOC를 작성하면 오류를 줄이고 오류를 쉽게 발견 할 수 있습니다.
— LucaB
3
랜덤 노이즈로 압축 될 수있는 Haskell 및 기타 언어에는 해당되지 않습니다. :)
— Macke
1
물론, 요점은 "압축 코드"가 아니라 LOC가 적은 얇은 알고리즘을 작성하는 것입니다. :) +1.
— LucaB
9

Thilo의 대답 은 역사적으로 가장 정확하지만 "음수 코드"는 또한 성능과 메모리 사용을 포함 할 수 있습니다. 실제로 필요할 때까지 무언가의 실행 또는 할당을 연기하려는 노력입니다.

이 "미루는 대가"는 "무언가를하는 것이 항상 무언가를하는 것보다 빠르다", "가장 빠른 코드는 절대로 실행되지 않는 코드", "만약 당신이 그것을 길게 할 수 있다면 당신은 그것을 할 필요가 없을지도 모른다 "

부정적인 코드를 실현하는 한 가지 기술은 문제의 초기 가정과 정의에 이의를 제기하는 것입니다. "sticky issue # 3"이 범주 적으로 불가능하도록 문제 / 입력 도메인을 재정의 할 수 있다면, sticky issue # 3을 다루는 시간이나 코드를 소비 할 필요가 없습니다. 디자인을 최적화하여 코드를 제거했습니다.

— 드 소프
소스
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.