기능이 너무 짧을 수 있습니까?

동일한 논리를 두 번 이상 작성하는 것을 발견 할 때마다 일반적으로 함수에 고정하므로 응용 프로그램에 단 하나의 위치 만 있으므로 해당 논리를 유지해야합니다. 부작용은 때때로 다음과 같은 하나 또는 두 개의 라인 기능으로 끝나는 것입니다.

function conditionMet(){
   return x == condition;
}

또는

function runCallback(callback){
   if($.isFunction(callback))
     callback();
}

이것이 게 으르거나 나쁜 습관입니까? 이것은 매우 작은 수의 논리를 요구하는 함수 호출이 더 많기 때문에 묻습니다.

브라운 씨, 제가 만난 모든 개발자들이 이만큼 작은 기능을 유지하도록 설득 할 수 있다면 소프트웨어 세계가 더 좋은 곳이 될 것입니다.

1) 코드 가독성이 10 배 증가합니다.

2) 가독성으로 인해 코드 프로세스를 쉽게 파악할 수 있습니다.

3) 건조-스스로 반복하지 마십시오-당신은 이것을 잘 준수하고 있습니다!

4) 테스트 가능. 작은 기능은 우리가 너무 자주 보는 200 개의 라인 방법보다 테스트하기가 백만 배 더 쉽습니다.

아, 그리고 성능면에서 "기능 호핑"에 대해 걱정하지 마십시오. "릴리즈"빌드와 컴파일러 최적화는이를 매우 잘 처리하며 시스템 디자인의 다른 부분에서 성능은 99 %입니다.

게으른가요? -정반대!

이것은 나쁜 습관입니까? - 절대적으로하지. 타르 볼이나 "하느님 물체"보다 방법을 만드는 것이 더 흔합니다.

내 동료 장인의 좋은 일을 유지하십시오.)

리팩토링 된 메소드가 다음 중 하나이면 너무 짧습니다.

• 메소드를 작성하는 것 외에 다른 목적으로 원시 조작을 복제합니다.

전의:

boolean isNotValue() {
   return !isValue();
}

또는...

• 이 코드는 한 번만 사용되며 그 의도를 한눈에 쉽게 이해할 수 있습니다.

전의:

void showDialog() {
    Dialog singleUseDialog = new ModalDialog();
    configureDialog(singleUseDialog);
    singleUseDialog.show();
}

void configureDialog(Dialog singleUseDialog) {
    singleUseDialog.setDimensions(400, 300);
}

이것은 유효한 패턴이 될 수 있지만,이 예제에서 configureDialog () 메소드를 인라인하려고합니다.

기능이 너무 짧을 수 있습니까? 일반적으로

실제로 다음을 보장하는 유일한 방법은 다음과 같습니다.

1. 디자인에서 모든 클래스를 찾았습니다.
2. 당신의 기능은 한 가지 일을하고 있습니다.

기능을 최대한 작게 유지하십시오. 즉, 더 이상 추출 할 수 없을 때까지 함수에서 함수를 추출하십시오. 나는 이것을 "떨어질 때까지 추출"이라고 부릅니다.

이것을 설명하기 위해 : 함수는 변수로 통신하는 기능의 덩어리가있는 범위입니다. 클래스는 변수로 통신하는 기능 덩어리가있는 범위이기도합니다. 따라서 긴 함수는 항상 작은 메소드를 가진 하나 이상의 클래스로 대체 될 수 있습니다.

또한 함수에서 다른 함수를 추출 할 수있을만큼 큰 함수는 정의에 따라 둘 이상의 작업을 수행 합니다 . 당신은 그래서 만약 수 서로 기능을 추출, 당신은 해야 그 기능의 압축을 풉니 다.

어떤 사람들은 이것이 기능의 확산으로 이어질 것이라고 걱정합니다. 그들이 맞습니다. 그렇습니다. 실제로 좋은 일입니다. 함수에는 이름이 있기 때문에 좋습니다. 좋은 이름을 선택하는 데주의를 기울이면이 기능은 다른 사람에게 사용자의 코드를 지시하는 사인 포스트 역할을합니다. 실제로, 이름이 잘 지정된 네임 스페이스 내의 이름이 잘 지정된 클래스 내의 이름이 지정된 함수는 독자가 길을 잃지 않도록하는 가장 좋은 방법 중 하나입니다.

cleancoders.com의 Clean Code의 에피소드 III에 더 많은 내용이 있습니다.

와우, 대부분의 답변은별로 도움이되지 않습니다.

ID가 정의 인 함수는 작성하지 않아야합니다 . 즉, 함수 이름이 단순히 영어로 작성된 함수의 코드 블록 인 경우 함수로 작성하지 마십시오.

귀하의 기능 conditionMet과 다른 기능을 고려하십시오 addOne(내 녹슨 JavaScript 용서하십시오).

function conditionMet() { return x == condition; }

function addOne(x) { return x + 1; }

conditionMet적절한 개념적 정의입니다. addOneA는 동어 반복은 . "조건 충족"이라고 말하면 conditionMet무엇이 conditionMet수반 되는지 모르기 때문에 좋지만 addOne영어로 읽어 보면 어리석은 이유를 알 수 있습니다 .

"For the condition to be met is for x to equal condition" <-- explanatory! meaningful! useful!

"To add one to x is to take x and add one." <-- wtf!

여전히 거룩 할 수있는 것들에 대한 사랑을 위해, 긴장된 기능을 쓰지 마십시오!

(같은 이유로 모든 코드 줄에 주석을 쓰지 마십시오 !)

의견을 추가하여 일부 코드의 의도를 개선 할 수 있다고 생각한다면 해당 의견을 추가하는 대신 코드를 자체 메소드로 추출하십시오. 아무리 작은 코드라도

예를 들어 코드가 다음과 같은 경우

if x == 1 { ... } // is pixel on?

대신 다음과 같이 만드십시오.

if pixelOn() { ... }

와

function pixelOn() { return x == 1; }

즉, 메서드 길이가 아니라 자체 문서화 코드에 관한 것입니다.

이것이 바로 당신이하고 싶은 것이라고 생각합니다. 현재이 기능은 한두 줄일 수 있지만 시간이 지남에 따라 커질 수 있습니다. 또한 더 많은 함수 호출을 통해 함수 호출을 읽고 내부에서 발생하는 상황을 이해할 수 있습니다. 이렇게하면 코드를 매우 건조 하게 만들 수 있습니다 (반복하지 마십시오) .

내가 본 다른 모든 게시물에 동의합니다. 이것은 좋은 스타일입니다.

최적화 기가 호출을 최적화하고 코드를 인라인 할 수 있으므로 이러한 작은 메소드의 오버 헤드는 크지 않을 수 있습니다. 이와 같은 간단한 코드는 옵티마이 저가 최상의 작업을 수행 할 수 있도록합니다.

명확성과 단순성을 위해 코드를 작성해야합니다. 방법을 두 가지 역할 중 하나로 제한하려고합니다. 의사 결정; 또는 작업 수행. 이것은 한 줄 방법을 생성 할 수 있습니다. 이 작업을 잘 수행할수록 코드를 더 잘 찾을 수 있습니다.

이와 같은 코드는 높은 응집력과 낮은 결합을 갖는 경향이 있으며 이는 우수한 코딩 관행입니다.

편집 : 메소드 이름에 대한 참고 사항. 메소드가 수행하지 않는 방식을 나타내는 메소드 이름을 사용하십시오. verb_noun (_modifier)가 좋은 이름 지정 체계라는 것을 알았습니다. Select_Customer_Using_NameIdx가 아닌 Find_Customer_ByName과 같은 이름이 지정됩니다. 두 번째 경우는 방법이 수정 될 때 잘못되기 쉽습니다. 첫 번째 경우 전체 고객 데이터베이스 구현을 교체 할 수 있습니다.

한 줄의 코드를 함수로 리팩토링하는 것은 과도하게 보입니다. ver loooooong / comples 줄 또는 expessions와 같은 예외적 인 경우가있을 수 있지만 , 향후 기능이 커질 것임을 알지 못하면이 작업을 수행하지 않을 것입니다.

첫 번째 예제는 전역 코드 사용에 대한 힌트 (코드의 다른 문제를 말하거나 나타내지 않을 수 있음)를 더 리팩토링하고 두 변수를 매개 변수로 만듭니다.

function conditionMet(x, condition){
   return x == condition;
}
....
conditionMet(1,(3-2));
conditionMet("abc","abc");

conditionMet예는 수 상태와 같은 길고 반복적 인 경우 유용합니다 :

function conditionMet(x, someObject){
   return x == ((someObject.valA + someObject.valB - 15.4) / /*...whole bunch of other stuff...*/);
}

이걸 고려하세요:

간단한 충돌 감지 기능 :

bool collide(OBJ a, OBJ b)
{
    return(pow(a.x - b.x, 2) + pow(a.y - b.y, 2) <= pow(a.radius + b.radius, 2));
}

코드에 항상 "간단한"라이너 하나를 쓴다면 결국 실수를 할 수 있습니다. 게다가, 그것을 반복해서 쓰는 것은 정말로 고문입니다.

아니요, 거의 문제가되지 않습니다. 이제 누군가 함수가 한 줄의 코드보다 길어야한다고 생각한다면 (단순 할 수 있다면) 문제가되고 어떤 것이 적절한 지 생각하지 않기 때문에 게으르다.

나는 그들이 너무 짧다고 말하고 싶지만 이것은 나의 주관적인 의견입니다.

때문에:

• 함수가 한두 번만 사용되면 함수를 작성할 이유가 없습니다. 멍청이로 점프. 특히 놀랍도록 빠른 VS 및 C ++ 코드.
• 수업 개요. 수천 개의 작은 기능이 있으면 화를냅니다. 클래스 정의를 볼 수 있고 SetXToOne, SetYToVector3, MultiplyNumbers, + 100 setter / getter가 아닌 클래스 정의를 볼 수있을 때 즐겁습니다.
• 대부분의 프로젝트에서이 헬퍼들은 하나의 리팩토링 단계 이후에 무게가 줄어들고, "모두 검색"-> 삭제를하여 쓸모없는 코드를 제거합니다. 보통 ~ 25 % +입니다.

긴 기능은 나쁘지만 3 줄보다 짧고 1 개만 수행하는 기능은 마찬가지로 나쁜 IMHO입니다.

그래서 작은 함수 만 작성한다고 말하고 싶습니다.

• 3 줄 이상의 코드
• 주니어 개발자들이 놓칠 수있는 것들 (알 수 없음)
• 추가 검증
• 3 배 이상 사용 또는 사용
• 자주 사용하는 인터페이스를 단순화
• 다음 리팩토링 동안 데드 웨이트가되지 않습니다
• 템플릿 전문화 또는 무언가와 같은 특별한 의미가 있습니다.
• 일부 격리 작업-const 참조, 변경 가능한 매개 변수에 영향을 미치고 개인 구성원 검색을 수행합니다

다음 개발자 (노인)는 모든 SetXToOne 기능을 기억하는 것보다 더 좋은 일을 할 것이라고 확신합니다. 그래서 그들은 곧 어느 쪽이든 죽은 무게로 변할 것입니다.

나는 예를 좋아하지 않는다. 1, 일반 이름 때문에.

conditionMet일반적인 것처럼 보이지 않아 특정 조건을 나타냅니다. 처럼

isAdult () = { 
  age >= 18 
}

이것은 괜찮을 것입니다. 의미 상 차이점이지만

isAtLeast18 () { age >= 18; } 

나에게 좋지 않을 것입니다.

아마도 자주 사용되며 나중에 변경 될 수 있습니다.

getPreferredIcecream () { return List ("banana", "choclate", "vanilla", "walnut") }

괜찮습니다. 여러 번 사용하면 내일 휘핑 크림이 가능할 경우 단일 장소를 변경하면됩니다.

isXYZ (Foo foo) { foo.x > 15 && foo.y < foo.x * 2 }

원자 적이 지 않으며 훌륭한 테스트 기회를 제공해야합니다.

물론 함수를 전달해야하는 경우 원하는 것을 전달하고 다르게 보이는 함수를 작성하십시오.

그러나 일반적으로 너무 짧은 기능보다 너무 긴 기능이 훨씬 더 많습니다.

마지막 단어 : 일부 함수는 너무 자세하게 작성 되었기 때문에 적절하게 보입니다.

function lessThan (a, b) {
  if (a < b) return true else return false; 
}

보시다시피,

return (a < b); 

당신은 문제가 없을 것입니다

localLessThan = (a < b); 

대신에

localLessThan = lessThan (a, b); 

코드가없는 코드는 없습니다!

간단하게 유지하고 복잡하게 만들지 마십시오.

게으르지 않고, 당신의 일을하고 있습니다!

예, 짧은 코드 기능이 있습니다. "getters", "setters"와 같은 방법의 경우 "accesors"는 이전 답변에서 언급 한 것처럼 매우 일반적입니다.

서브 클래스에서 재정의 될 때 함수에 더 많은 코드가 있기 때문에 이러한 짧은 "가속기"함수가 가상 인 경우도 있습니다.

전역 또는 메서드를 사용하는 많은 함수에서 너무 짧지 않은 함수를 원할 경우 일반적으로 직접 반환 대신 "결과"변수 (파스칼 스타일)를 사용하므로 디버거를 사용할 때 매우 유용합니다.

function int CalculateSomething() {
  int Result = -1;

   // more code, maybe, maybe not

  return Result;
}

너무 짧으면 결코 문제가되지 않습니다. 짧은 기능에 대한 몇 가지 이유는 다음과 같습니다.

재사용 성

예를 들어 set 메소드와 같은 함수가있는 경우 매개 변수가 유효한지 확인하도록 주장 할 수 있습니다. 이 점검은 변수가 설정되는 모든 곳에서 수행되어야합니다.

유지 보수성

나중에 변경 될 수 있다고 생각하는 진술을 사용할 수도 있습니다. 예를 들어 이제 열에 기호가 표시되지만 나중에 다른 것으로 변경 될 수 있습니다 (또는 경고음).

일률

예를 들어 파사드 패턴을 사용하고 있으며 함수가 수행하는 유일한 일은 인수를 변경하지 않고 함수를 다른 함수에 정확하게 전달하는 것입니다.

코드 섹션에 이름을 지정할 때 본질적으로 이름을 지정 하기위한 것 입니다. 여러 가지 이유가있을 수 있지만 중요한 점은 프로그램에 추가 할 의미있는 이름을 부여 할 수 있다는 것 입니다. "addOneToCounter"와 같은 이름은 아무것도 추가하지 않지만 추가 conditionMet()합니다.

스 니펫이 너무 짧거나 긴지 확인하는 규칙이 필요한 경우 스 니펫의 의미있는 이름을 찾는 데 시간이 얼마나 걸리는지 고려하십시오. 합리적인 시간 내에 스 니펫이 적합하지 않으면 스 니펫이 적합하지 않은 것입니다.

아니요, 그러나 너무 간결 할 수 있습니다.

기억하십시오 : 코드는 한 번 작성되지만 여러 번 읽습니다.

컴파일러 용 코드를 작성하지 마십시오. 코드를 유지해야 할 미래의 개발자를 위해 작성하십시오.

그렇습니다. 기능은 더 작고 작을 수 있으며, 좋든 나쁘 든 사용중인 언어 / 프레임 워크에 따라 다릅니다.

제 생각에는 주로 Front End Technologies에서 일하고 있습니다. 작은 기능은 주로 작은 필터를 사용하고 응용 프로그램에서 동일한 논리를 사용할 때 많은 기능을 사용할 수 있도록 도와주는 도우미 기능으로 주로 사용됩니다. 응용 프로그램에 일반적인 논리가 너무 많으면 수많은 작은 기능이 있습니다.

그러나 일반적인 논리가없는 응용 프로그램에서는 작은 기능을 수행해야하지만 코드를 관리하기 쉽고 이해하기 쉬운 세그먼트로 나눌 수 있습니다.

일반적으로 거대한 코드를 작은 함수로 나누는 것이 좋은 접근 방법입니다. 현대의 프레임 워크와 언어에서는 다음과 같이해야합니다.

data => initScroll(data)

ES 2017 JavaScript 및 Typescript의 익명 함수입니다.

getMarketSegments() {
 this.marketService.getAllSegments(this.project.id)
  .subscribe(data => this.segments = data, error => console.log(error.toString()));
}

위의 코드에서 3 개의 함수 선언과 2 개의 함수 호출을 볼 수 있습니다. 이것은 Typescript를 사용한 Angular 4의 간단한 서비스 호출입니다. 요구 사항으로 생각할 수 있습니다

([] 0)
([x] 1)
([x y] 2)

위의 clojure 언어의 3 가지 익명 함수입니다

(def hello (fn [] "Hello world"))

위의 것은 clojure의 기능 선언입니다.

따라서 기능은 더 작을 수 있지만 다음과 같은 기능이 있다면 좋든 나쁘 든 상관 없습니다.

incrementNumber(numb) { return ++numb; }

잘하는 것이 좋지는 않지만 Angular Framework에서와 같이 HTML 태그 에서이 기능을 사용하는 경우 Angular HTML Templates에서 Increment 또는 Decrement를 지원하지 않으면 어떻게해야합니까? 나를.

다른 예를 보자

insertInArray(array, newKey) {
 if (!array.includes(newKey)) {
   array.push(newKey);
 }
}

위의 예제는 Angular HTML Templates 내부의 배열을 재생할 때 필수입니다. 때로는 작은 함수를 만들어야 할 때가 있습니다

이 시점에서 거의 답변에 동의하지 않습니다.

최근에 다음과 같은 모든 클래스 멤버를 작성하는 동료를 발견했습니다.

 void setProperty(int value){ mValue=value; }
 int getProperty() const { return (mValue); }

산발적 인 경우에는 좋은 코드 일 수 있지만 많은 속성을 가진 많은 클래스를 정의하는 경우 확실하지 않습니다. 이것으로 위의 방법과 같은 방법은 쓰지 않을 것이라고 말하고 싶지 않습니다. 그러나 대부분의 코드를 실제 논리의 "래퍼"로 작성하면 문제가있는 것입니다.

프로그래머는 아마도 전체적인 논리를 그리워하고, 미래의 변화에 ​​대한 두려움과 코드 리팩토링에 대해 두려워 할 것입니다.

인터페이스의 정의는 실제로 필요하기 때문입니다. 실제로 간단한 속성을 설정하고 가져와야하는 경우 (논리가 많지 않아서 멤버가 짧아짐) 가능해야합니다. 그러나 실제 요구를 다른 방식으로 분석 할 수 있다면 왜 더 직관적 인 인터페이스를 정의하지 않습니까?

질문에 실제로 대답하기 위해서는 물론 그렇지 않으며, 그 이유는 매우 분명합니다. 방법 / 속성 / 무엇이 필요한 것에 대해 정의되어야합니다. 빈 가상 함수조차도 존재해야 할 이유가 있습니다.