코드에서 줄 수를 줄이는 것이 얼마나 중요합니까?

J2SE (core java)에서 작업하는 소프트웨어 개발자입니다.
코드를 검토하는 동안 코드의 줄 수를 줄여야하는 경우가 종종 있습니다.

중복 코드를 제거하는 것이 아니라 코드에서 줄 수를 줄이면서 동일한 작업을 수행하는 데 중점을 둔 스타일을 따르는 것이지만 줄 수를 늘리는 것을 의미하더라도 코드를 명확하게 믿습니다.

올바른 일을하는 방법은 무엇이라고 생각하십니까?
LOC (코드 줄)가 작은 경우 코드에 어떤 영향을 줍니까? LOC가 더 큰 경우 코드에 어떤 영향을 줍니까?

웹 사이트의 예 : "javaranch"-

public static void happyBirthday(int age)
{  
    if ((age == 16) || (age == 21) || ((age > 21) && (((age % 10) == 0) || ((age % 25) == 0))))        
    {
        System.out.println("Super special party, this year!");
    }
    else
    {
        System.out.println("One year older. Again.");
    }
}

VS

public static void happyBirthday(int age)
{

    boolean sweet_sixteen = (age == 16);
    boolean majority = (age == 21);
    boolean adult = (age > 21);
    boolean decade = (age % 10) == 0;
    boolean quarter = (age % 25) == 0;

    if (sweet_sixteen || majority || (adult && (decade || quarter)))
    {
        System.out.println("Super special party, this year!");
    }
    else
    {
        System.out.println("One year older. Again.");
    }
}

측정의 문제는 아무리 잘 의도되어 있더라도 품목을 측정하는 행위가 중요하다는 것이며, 결과적으로 품목을 측정하지 않는 행위는 중요하지 않습니다. 중요한 것을 측정하고 중요하지 않은 것을 측정하지 않는 것이 절대적으로 중요합니다.

SLOC 측정 (귀하의 리뷰가 효과적으로 수행하는 작업)은 SLOC를 중요하게 만듭니다 .... SLOC가 중요합니까? -절대로, 결코 (외부 난독 화 된 프로그래밍 경연 대회 ), 결코 상업 조직에 있지 않을 것입니다.

"이 루틴의 SLOC를 줄이려면 어떻게해야합니까?"라는 간단한 질문을 해보십시오. 이 경우에 발생할 수있는 일은 SLOC가 복잡성을 측정하는 순진한 방법으로 사용되고 있다는 것입니다. 모든 비용에서 피해야 할 것은 중요한 수를 세는 것이 아니라 SLOC와 같은 객관적인 측정, 즉 계산하기 어려운 콩 (가독성, 복잡성 등)을 계산하는 것입니다.

코드 검토 자에게는 별표가 있지만 동의합니다. 코드에 작성하는 각 진술은 기술적 인 책임이며 잠재적 인 장애 지점입니다. 10 개의 문장으로 메소드를 작성하고 동료가 5 개의 문장으로 동일한 기능을 수행하는 메소드를 작성하는 경우, 문제 가능성에 의해 측정 된 방법이 더 낫습니다 (코드가 잘못 될 수있는 위치가 두 배 더 많음) 복잡하거나 문제가 있습니다).

그러나 별표가 있습니다. 아이디어의 실제 코드 줄 수에 관한 것이 아닙니다. 왜냐하면 다음과 같이 줄 수를 줄일 수 있기 때문입니다.

void someMethod() {   
 someobject.doSomething(someSingleton.getInstance().with().a().lot().of().law().of().demeter().violations()).and().if().that().werent().enough().theres().more();
}

이것은 한 줄의 코드이지만 놀라운 일이 잘못 될 수있는 곳입니다. 그래서 나는 가장 적은 진술로 최선을 다하는 것에 초점을 맞추고 싶습니다. 일을 끝내기 위해 필요한만큼 많은 코드를 작성하십시오. 적어도 코드 검토자가 추진하는 것이라고 생각합니다.

개인적으로, 나는 맞닥뜨릴 균형이 있다고 생각합니다. 내가 말했듯이, 당신이 작성하는 각 진술은 책임이지만 설명적인 이름을 가진 지역 변수를 꺼내면 메소드가 훨씬 명확하고 읽기 쉽다면 그렇게해야 할 경우가 있습니다. 나는 사람들이 상대적으로 작은 미적 차이를 극복하는 상황에 쉽게 들어갈 수 있다고 생각하지만, 전체적으로는 리뷰어가 올바른 아이디어를 가지고 있다고 생각합니다.

명백한 직접적인 결과는 간결한 한 줄짜리 (라인 길이 제한에도 불구하고)를 홍보하기 때문에 리뷰어의 조언을 문자 그대로 사용하는 것은 좋지 않습니다. 그러나 여기서 배울 교훈은 코드가 적은 일을하는 것 입니다.

다시 말해, 이것은 단순성을 요구합니다. 코드가 자산이 아니라 책임 이라고 주장하는 것은 매우 인기있는 주장 이므로 기능을 유지하면서 코드 의 양 을 줄이는 것은 고귀한 노력입니다. 이는 문제를 직접 해결하고 간결한 솔루션을 선호하는보다 직접적인 직접 접근 방식으로 달성 할 수 있습니다.

Ken Thompson이 한 번 말한 것처럼 : 가장 생산적인 날 중 하나는 1000 줄의 코드를 버리고있었습니다 .

나는 "줄 수를 늘리는 것을 의미하더라도 코드를 명확하게하는"당신의 입장에 동의하는 경향이있다.

나는 상당히 간결한 하나의 라이너를 너무 많이 보았지만 그들이하는 일을 즉시 분명하지는 않습니다. 다른 개발자가 코드를 유지 관리해야하기 때문에 가독성이 중요합니다.

나는 더 나은 목표는 짧은 방법이라고 주장한다. 몇 줄의 코드로 인해 짧지는 않지만 단일 작업을 수행하기 때문에 짧습니다.

저는 현재 주요 회사의 선임 응용 프로그램 개발자 및 프로젝트 비즈니스 분석가로 일하고 있으며 개발의 라인 수가 관심의 대상이 된 적이 없습니다. 그러나 코드가 많이 압축 될수록 코드를 신속하게 분석하고 수정하거나 추가 할 수있는 비용을 들이지 않는 것이 좋습니다. 나에게, 당신은 광범위한 수준의 확장 성을 가져야하고 논스톱 변화하는 환경에서 즉각적인 변경이 가능한 비즈니스 크리티컬 애플리케이션을 담당 할 때 간결하고 읽기 쉬운 코드는 개발에서 가장 중요한 요소 중 하나입니다. . 의 신용 에릭 디트리히의 응답 이 :

void someMethod() {   
someobject.doSomething(someSingleton.getInstance().with().a().lot().of().law().of().demeter().violations()).and().if().that().werent().enough().theres().more();
}

그러나 나에게 완전히 받아 들일 수는 없지만 모든 기존 회사 코드를 다음과 같이 변경했습니다.

if (boolean == true){
value.prop = option1;
}
else{
value.prop = option2;
}

에:

value.prop =  boolean ? option1 : option2;

가독성을 희생하지 않는 탁월한 코드 압축 선택이었습니다.

코드에 어떤 영향을 미치는가? 100 줄의 코드에서 성능이 향상되거나 떨어지는 것을 보지 못했습니다. 간단한 사실은 최종 라인에 도착하는 데 걸리는 라인 수보다 최종 제품에 도달하는 데 사용하는 프로세스가 더 많다는 것입니다. 나는 매우 압축 된 비효율적 인 일부 프로세스가 더 나은 코드 흐름으로 긴 코드와 다르게 수행되는 것을 보았습니다.

IMO, 사소한 LOC 수로 코드 효과를 측정하는 것은 좋지 않습니다. 올바르게 엔지니어링되고 효과적인 코드를 만드는 데에는 더 많은 것이 있습니다.

내 경험상 효과적인 코드 :

• SOLID 원칙을 위반하지 않습니다
• 읽기 쉽고 설명이 필요합니다
• Albert Einstein의 단순성 테스트를 통과합니다. "모든 것이 가능한 한 단순해야하지만 단순하지 않아야합니다."

LOC를 유지하는 기술적 인 장단점과 의미있는 품질의 소프트웨어 메트릭인지 여부를 다루는 많은 답변이 있습니다. 그것은이 질문에 관한 것이 아닙니다. 중요한 것은 특정 코딩 규칙을 순진하게 교리 적으로 고집하는 경영진을 다루는 방법입니다.

안타깝게도 사람들이 적절한 맥락에서 사용하고 실용적으로 적용 할 때 좋은 조언 인 것들에 집착하고, 그 맥락에서 그것들을 꺼내어 독단적으로 적용하는 것은 조언이 처음에 완화하기 위해 존재하는 문제들을 이해하지 못하고있는 것이 일반적입니다. .

LOC 유지에 관한 조언은 한 번에 너무 많은 것을 시도하는 방법의 생성을 피하고 "신 클래스"의 생성을 막는 것입니다. 직접적인 책임과 시스템의 다른 모든 클래스에 의존합니다. 더 짧은 코드의 또 다른 장점은 더 읽기 쉽다는 점입니다. 지적한 바와 같이, 가독성이 실제로 저하되기 시작하는 지점까지 코드를 능가 할 수 있습니다.

낮은 LOC 수에는 큰 이점이 있습니다 (작은 방법은 큰 방법보다 머리에 더 쉽게 맞고 코드에 적은 수의 것은 잘못 될 수있는 적은 수 등을 의미 함). 또한 수익 감소 법칙의 적용을받습니다. 150 라인 방법을 여러 20 라인 방법으로 리팩토링하는 것은 10 라인 방법을 7 라인 방법으로 리팩토링하는 것보다 훨씬 큰 승리입니다.

그러한 리팩토링이 좋은 소프트웨어 디자인의 다른 측면 (예 : 가독성)을 희생 시키면, 당신은 그것을하지 않는 것을 정당화 할 수있는 지점에 도달하게됩니다. 코드의 의미에 대한 컨텍스트를 제공하는 변수를 제거하고 그렇지 않은 리터럴로 바꾸는 것은 매우 나쁜 일입니다. 좋은 코드에는 리터럴이 거의 없습니다. 그러나 이러한 변수 (및 상수라고 함)는 프로그램에 직접 기여하지 않는 코드 라인이므로 LOC가 일종의 신으로 숭배되는 경우 그러한 명확한 라인은 빠른 승리를 위해 정리되고 위험에 처하게됩니다. 경영진의 잘못된 칭찬.

나는 당신이 이것을 깨닫기에 충분히 똑똑하다고 믿습니다. 사실 그것은 당신의 원래 질문의 추력과 거의 같습니다. 문제는 코드 축소가 좋은시기와 그렇지 않은 경우 일반적으로 합리적인 관행을 무차별 적으로 적용하는 데 대한 독단주의입니다.

시간을내어 경영진과 대화하면서 자신의 입장을 설명하고 요청받은 내용이 코드가 도움이되기보다는 코드에 해가된다고 생각하는 이유를 설명하는 것이 좋습니다. 대립을 피하려고 노력하지만 그러한 토론 중에는 합리적이고 침착성을 유지하십시오. 경영진이 프로그래밍이 실용적 활동임을 이해하는 것이 중요하며 모범 사례 조언은 실용적으로 적용되는 경우에만 유용합니다. 모범 사례는 돌로 조각되지 않은 책으로 작성되며 충돌 할 때 (짧은 코드와 읽을 수있는 코드) 따라야 할 모범 사례에 대한 판단을 적용하는 것은 프로그래머의 몫입니다. 희망적으로 그들은 이와 같은 의견을 높이는 합리적인 사람들입니다.

불필요하거나 부적절하다고 생각되는 곳에서 LOC를 줄 이도록 압력을 받고 있다면 조용한 삶을 위해 어쨌든 변화를 취하는 것이 당연하기 때문에 약간 용감해야합니다. 이 일을 거부하고 그 결정을 "소유"해야합니다. 관리가 합리적인 상황에서는 지침을 정확하게 준수 할 필요는 없지만, 그렇지 않은 상황을 정당화 할 수 있어야합니다.

안타깝게도 사람들은 특히 자신의 결정과 규칙에 대해 의문을 제기하는 사람들에게 비합리적 일 수 있습니다. 그들은 합리적이지 않도록 선택할 수 있습니다. 당신도 그렇게 준비해야합니다. LOC 베스트 프랙티스가 다른 베스트 프랙티스와 직접 충돌하는 경우와 그것이 제품을 손상시키는 이유를 시연 할 수 있고, 개인적 관여가 거의 없거나 전혀없는 코드베이스의 일부에서이를 수행 할 수있는 경우 (그렇지 않습니다. 자신의 업무 나 감독 한 업무에 대한 개인적인 공격처럼 보이지는 않습니다.) 그러면 주장을 강화하는 데 도움이 될 수 있습니다. 다시, 당신은 침착하고 합리적인 방식으로 자신을 정당화하고 당신이하고있는 주장을 "소유"할 수 있도록 준비해야합니다.

귀하의 경영진이 합리적 인 사람이라면 귀하의 주장을 뒷받침하는 증거를 제공 할 수 있다면 귀하의 말에 가치가 있음을 인식해야합니다.

실제로 SLOC가 적은 기능을 갖기 위해 노력해야한다고 생각합니다.

LOC (코드 줄)가 작은 숫자 인 경우 코드에 어떤 영향을 미치고 LOC가 큰 숫자 인 경우 코드에 어떤 영향을 미칩니 까?

이상적으로는 30 줄을 이해하는 것보다 한 줄로 8 줄의 코드를 이해하는 것이 더 쉬워야합니다.

그렇다고 8 개의 라인으로 압축 된 30 개의 LOC가 이해하기 쉽다는 것을 의미하지는 않습니다.

올바른 일을하는 방법은 무엇이라고 생각하십니까?

일반적으로 함수에서는 추상화 수준 ( "IO 코드 여기", "여기에서 유효성 검사", "계산 여기"등)별로 그룹화하려고합니다.

그런 다음 빈 줄로 구분하여 블록으로 나눕니다. 코드가 약 10 줄 이상이면 각 블록을 다른 함수로 추출합니다 (어쨌든 두 번 이상 나타나는 코드에 대해서는 그렇게합니다). 나는 이런 식으로 성능을 떨어 뜨리는 것에 대한 논쟁을 들었지만 (불필요한 함수 호출) 실제로는 이것으로 인해 성능 병목 현상이 발생하지 않았습니다.

즉,이 추출을 수행 한 함수가 있었고 그 후에 함수는 ~ 40 줄 길이 (C 코드)였습니다. 코드가 가능한 한 그룹화되어 있으면 더 긴 기능에 문제가 발생하지 않습니다.

LOC보다 깨끗하고 자동 문서화 된 코드에 집중하는 것이 더 중요하다고 생각합니다. 그래도 예제를 좋아하지 않습니다. 왜냐하면 코드가 무엇을하는지 설명하지 않기 때문입니다. 예를 들면 다음과 같습니다.

부울 sweet_sixteen = (나이 == 16);

꽤 중복됩니다. "나이 == 16"을 읽는 사람은 누구나 알고 있습니다. 차라리 다음과 같은 코드를 작성하고 싶습니다.

public static boolean companyShouldThrowABigParty(int age) {
    return (age == 16) || (age == 21) || ((age > 21) && (((age % 10) == 0) || ((age % 25) == 0))); 
}

public static void happyBirthday(int age)
{  
    System.out.println(companyShouldThrowABigParty(age) ? "Super special party, this year!" : "One year older. Again.");
}

파티를 언제 던질 것인지 결정하는 논리는 System.out과 별개이며 테스트 할 수 있으며 이해하기 쉽습니다. 더 중요한 것은, 코드를 읽는 누군가가 그 방식으로 작성된 이유를 이해할 수 있다는 것입니다 ( "회사는 일부 사람들을 위해 큰 파티를 열기를 원합니다").

적은 코드 줄 = 더 읽기 쉬운 코드라고 생각합니다.

그러나 물론 줄 수를 줄이려고 코드를 축소 / 분산하기 시작할 때 약간의 제한이 있습니다.

/** Pad a number with 0 on the left */
function zeroPad(number, digits) {
    var num = number+"";
    while(num.length < digits){
        num='0'+num;
    }
    return num;
}

이것은 논리가 동일하고 가독성이 떨어지는 최소화입니다. 이것은 사람에 의해 수행되어서는 안됩니다.이 축소는 기계가 기계에 의해 읽히도록 수행됩니다.

function zP(e,t){var n=e+"";while(n.length<t){n="0"+n}return n}

코드 조각을 제거 할 수 있고 알고리즘이 여전히 수행해야하는 작업을 수행하는 경우 계속 진행하십시오. 코드를 축소하지 말고 더 좋은 도구가 있습니다.

더 적은 코드 줄 == 더 읽기 쉬운 코드라고 생각하지 않습니다. 그러나 이론과는 매우 다른 현실은 많은 수의 행을 가진 코드가 종종 적절한 디자인없이 작성된다는 것입니다. 결과적으로, 적은 수의 라인이 필요하기 때문에 일부 프로그래머는 가능한 경우 더 나은 디자인을 만들 수 있습니다. 트위스트는 많은 프로그래머가 그렇지 않다는 것이므로 요구 사항은별로 도움이되지 않습니다.

정상적인 상황에서는 줄 수를 문제로 보지 않지만 문제를 가리킬 수 있습니다. 누군가 1000 줄의 코드가있는 클래스를 보여 주면 클래스가 수행되었거나 디자인 된 방식에 문제가 있어야합니다.

귀하의 예는 더 많은 수의 코드 줄이 적합한 경우를 가리 킵니다. 그러나 이것이 그 예입니다. 매일 계획 부족으로 줄 수를 첨부하는 예를 봅니다.

LOC는 실제 구현보다 프로젝트 시작시 더 유용한 지표라고 생각합니다. 기능 포인트 당 LOC를 알면 프로젝트 노력과 프로젝트 소요 시간 및 최적의 개발자 수를 추정 할 수 있습니다.

또한 디자인 및 언어 선택에 영향을 줄 수 있습니다. 기능 포인트를 줄이거 나 LOC / FP가 낮은 언어로 전환하면 프로젝트 노력이 줄어 듭니다.

코드 줄 자체는 그다지 중요하지 않습니다. 그것을 보는 한 가지 방법은 그것을 산문과 비교하는 것입니다. 첫 번째 실현은 코드와 산문의 중요한 속성 (정확성을 가정 함)이 가독성이라는 것입니다. 가독성 (및 이해 가능성)은 유지 보수성 및 정확성과 같은 다른 특성에 도움이됩니다.

적은 수의 라인에 기능을 적용 할 수 있다는 장점이 있습니다. 그러나 단락이없는 텍스트는 가독성을 떨어 뜨립니다. 어려운 개념, 어려운 단어 및 복잡한 표현 방식은 일반적으로 아이디어를 표현하는 데 필요한 단어의 양을 줄이지 만 동시에 텍스트의 읽기 수준을 중등 학교 수준에서 전문 학업 수준으로 이동시킵니다. 산문의 경우).

일반적으로 코드에 추상화를 추가하고 도우미 등을 사용하는 것이 도움이되지만 다시 추상화가 너무 많아 질 수 있습니다. 코드의 다른 부분으로 복잡성을 옮기는 것도 발생할 수 있습니다. 때로는 전문가로서 주니어 프로그래머 (또는 학생)가 사용할 프레임 워크 / 라이브러리를 디자인 할 때와 같이하는 것이 좋습니다. 그러나 주니어가 코드의 작동 방식을 이해할 수 있다고 기대하지 말고 잘못 사용하기가 매우 어렵습니다.

코드를 작성할 때, 특히 코드에 빈 줄을 추가하지 마십시오. 그것들은 단락으로 기능하며 함수의 다른 부분을 분리하는 데 도움이됩니다 (아직 도우미에 넣지 않아도).

모든 공식 코드 평가 방법의 큰 문제점은 일부 코드에서 실패한다는 것입니다. 이는 프로그래밍이 일종의 기술이기 때문에 명확한 평가 기준이 존재하지 않기 때문입니다. 물론 다양한 종류의 예술이 있습니다-그림의 대량 생산도 존재하며,이 사업에서는 한 그림에 많은 페인트가 소비되는 것이 중요합니다. :)

완벽하게 솔직히 말해서 LOC 측정에 대한 정보는 제공하지 않습니다. 물론, 함수 나 프로시 저는 가능한 짧게 작성하는 것이 좋지만, 언제든지 읽을 수있는 코드를 짧게 작성합니다.

LOC를 줄이려면 항상 코드를 읽기가 어렵다는 데 동의합니다.

그러나 코딩 스타일이 너무 장황하고 검토자가 더 간결한 방법이 더 좋다고 생각할 수 있습니다. 예를 들어 변수 이름을 명확하게 선택하여 상당히 분명한 문장 하나만 설명하는 주석은 쓸모가 없습니다.

코드 줄이 측정하는 것은 단 한 가지 뿐이며 코드 줄의 수입니다. 다른 모든 것은 열기, 투기 및 편견입니다.

이 일이 더 악화하지 더 나은 만들 수 있습니다 적은 코드를 가진 방법의 다른 답변에서 좋은 사례가 많이 있지만, 하나의 핵심 포인트는 누락 된 것, 그리고 그 : 얼마나 많은 줄 당신이 실제로 할 필요가 이 일을 ?

작업을 수행하려면 10 줄의 코드가 필요하므로 10 줄로 수행하십시오. 달성하려면 10,000 줄이 필요하면 마찬가지로 10,000 줄로 수행하십시오. "더 적은 코드 줄"이라는 컬트는 1,000 번 또는 2,000 번 또는 그 외의 다른 방법으로 수행해도 후자의 예제를 더 잘 만들지 못할 것입니다. 작업이 필요한 것 등 검증, 오류 검사, 보안, 레이어 포함 10,000 선 그 10,000 선을 놓친 당신이 더 적은에서 그것을 한 경우입니다.

편집하다

이것이 몇 가지 다운 보트를 얻었으므로 여기에서 내가 말하는 것에 대해 더 구체적이어야한다고 생각합니다. 누군가가해야 할 첫 번째 일은 이것을 읽는 것 입니다. 내가 그것을 요구하는 요점은 작성하는 고급 코드가 실제로 실행되는 기계 코드와 거의 또는 전혀 유사하지 않을 수 있다는 것입니다. 이 점의 관련성은 실제로 진행되는 작업에 대한 이해없이 높은 수준의 코드에 초점을 맞추는 것이 잘못되었다는 것입니다.

이제 다음을 고려하십시오.

• 단 한 줄로 아주 나쁘고 느린 코드를 작성할 수 있습니다. 제공 한 링크의 끝에 삼항 연산자에 대한 주석을 적어 두십시오.

• 한 줄의 코드가 API 호출 (또는 외부 라이브러리에 대한 다른 호출)을 수행하는 경우 정의에 따라 실행 대상 또는 효율성을 직접 제어 할 수있는 방법이 거의 없습니다.

• 오류 검사, 정리 등은 모두 추가 코드 줄을 추가하며 더 적은 코드 줄의 가장 열렬한 팬조차도 그에 대해 논쟁하지 않을 것이라고 확신 합니다 .

따라서 코드 줄은 깨진 메트릭입니다. 코드 줄 수가 적더라도 추가 성능을 보장 할 수 없습니다. API 또는 라이브러리 호출은 한 줄이며 통제 범위를 벗어날 수 있습니다. 코드 줄 수가 적더라도 추가적인 견고성이 보장되지 않습니다. 오류 확인 및 정리에는 항상 줄이 추가로 필요합니다. 코드 줄이 더 적더라도 가독성이나 유지 관리 성이 향상되지는 않습니다 . IOCCC 만 살펴보면됩니다 .

더 적은 코드 줄이 무엇을 보장합니까? 더 적은 코드 줄만 있으면됩니다.

2,000 줄에서 10,000 줄로 같은 일을하는 데 집중하는 것은 매우 잘못된 일입니다. 대신, 허용되는 허용 범위 내에서 작동하고, 계속 읽고 이해하기 쉬운 작동하는 코드에 집중하십시오. 때로는 낮은 LoC 수로 수행 할 수 있음을 의미하고 때로는 LoC 수를 더 많이 수행해야 함을 의미하지만 LoC 수는 여기서 중요하지 않아야합니다.

코드에서 줄 수를 줄이는 것이 얼마나 중요합니까? 대부분의 경우 전혀 아닙니다. 실제로, 대부분의 경우 복잡한 연산을 더 읽기 쉬운 단계로 나누고 각 단계에 주석을 달고 일반적으로 주석을 추가하여 코드를 더 읽기 쉽고 확장 가능하게 만들어 코드 줄 수를 늘리는 것이 더 중요합니다 당신을 따르는 개발자.

초기에는 로크 인 코드 줄의 수가 많으면 코드가 효과적이며 코드가 사용되는 모든 작업을 수행하지만 어느 정도 시간이 지나면 로크가 클수록 더 많은 코드가 실현된다고 가정했습니다. 시스템이 코드를 실행하는 데 드는 비용이 매우 적기 때문에 효율성이 있습니다. 따라서 시스템 위치를 개선하기 위해 시스템 위치를 줄이려고했기 때문에 loc shoul이 더 작다고 가정하여 다음 요소를 줄였습니다. 고려해야합니다.

1. 문제의 순서도를 만드십시오
2. 최대한 적은 수의 루프를 사용하십시오
3. 함수 호출은 그리 많지 않아야합니다
4. 스택 또는 큐가 관련 정보를 저장하는 데 사용되는 경우 TRIE와 같은 새로운 데이터 구조를 사용해야합니다.
5. 그리고 매우 큰 배열에 많은 수의 숫자를 저장 한 다음 배열을 통해 액세스하려고하는 상상적인 접근 방식보다는 현실적인 접근 방식으로 문제를 해결하려고 노력하십시오.]
6. 가능한 많은 매크로를 사용하십시오. 또한 사용하는 방법은 문제에 따라 달라집니다. 실제로 복잡한 경우 간단한 방법을 사용하는 것도 복잡한 방법과 같습니다.