가독성과 유지 보수성, 중첩 함수 호출을 작성하는 특수한 경우

중첩 함수 호출에 대한 내 코딩 스타일은 다음과 같습니다.

var result_h1 = H1(b1);
var result_h2 = H2(b2);
var result_g1 = G1(result_h1, result_h2);
var result_g2 = G2(c1);
var a = F(result_g1, result_g2);

최근에 다음과 같은 코딩 스타일이 많이 사용되는 부서로 변경했습니다.

var a = F(G1(H1(b1), H2(b2)), G2(c1));

내 코딩 방식의 결과는 충돌 함수의 경우 Visual Studio가 해당 덤프를 열고 문제가 발생한 줄을 나타낼 수 있다는 것입니다 (특히 액세스 위반이 걱정됩니다).

첫 번째 방식으로 프로그래밍 된 동일한 문제로 인해 충돌이 발생한 경우 충돌을 일으킨 기능을 알 수 없습니다.

반면에 한 줄에 더 많은 처리를할수록 한 페이지에서 더 많은 논리를 얻을 수있어 가독성이 향상됩니다.

내 두려움이 맞습니까, 아니면 뭔가 빠졌습니까? 일반적으로 상업 환경에서 선호되는 것은 무엇입니까? 가독성 또는 유지 보수성?

그것이 관련이 있는지는 모르겠지만 C ++ (STL) / C #에서 일하고 있습니다.

만약 당신이 하나의 라이너를 확장해야한다고 느꼈다면

 a = F(G1(H1(b1), H2(b2)), G2(c1));

난 당신을 비난하지 않습니다. 그것은 읽기가 어렵고 디버깅하기가 어렵습니다.

왜?

1. 조밀하다
2. 일부 디버거는 한 번에 전체를 강조 표시합니다
3. 설명적인 이름이 없습니다.

중간 결과로 확장하면

 var result_h1 = H1(b1);
 var result_h2 = H2(b2);
 var result_g1 = G1(result_h1, result_h2);
 var result_g2 = G2(c1);
 var a = F(result_g1, result_g2);

여전히 읽기가 어렵습니다. 왜? 두 가지 문제를 해결하고 네 번째 문제를 소개합니다.

1. 조밀하다
2. 일부 디버거는 한 번에 전체를 강조 표시합니다
3. 설명적인 이름이 없습니다.
4. 설명이 아닌 이름으로 어수선합니다

새롭고 좋은 의미 의미를 추가하는 이름으로 확장하면 더 좋습니다! 좋은 이름은 이해하는 데 도움이됩니다.

 var temperature = H1(b1);
 var humidity = H2(b2);
 var precipitation = G1(temperature, humidity);
 var dewPoint = G2(c1);
 var forecast = F(precipitation, dewPoint);

적어도 이것은 이야기를 말해줍니다. 그것은 문제를 해결하고 여기에 제공된 다른 것보다 분명히 낫지 만 이름을 생각해 내야합니다.

당신은 같은 의미의 이름으로 할 경우 result_this와 result_that단순히 좋은 이름을 생각할 수 없기 때문에 나는 정말 원합니다 당신은 우리에게 의미 이름의 혼란을 절약하고 좋은 오래된 공백을 사용하여 확장 :

int a = 
    F(
        G1(
            H1(b1), 
            H2(b2)
        ), 
        G2(c1)
    )
;

의미없는 결과 이름을 가진 것보다 더 읽기 쉽지만 읽을 수 있습니다 (이러한 함수 이름이 그렇게 큰 것은 아닙니다).

1. 조밀하다
2. 일부 디버거는 한 번에 전체를 강조 표시합니다
3. 설명적인 이름이 없습니다.
4. 설명이 아닌 이름으로 어수선합니다

좋은 이름을 생각할 수 없을 때 얻는 것만 큼 좋습니다.

어떤 이유로 디버거는 새로운 줄을 좋아 하므로 디버깅이 어렵지 않습니다.

그것으로 충분하지 않다면, G2()여러 곳에서 호출되었다고 상상해보십시오 .

Exception in thread "main" java.lang.NullPointerException
    at composition.Example.G2(Example.java:34)
    at composition.Example.main(Example.java:18)

각 G2()통화가 자체 회선에 있기 때문에이 스타일을 사용하면 기본적으로 문제가되는 통화로 바로 연결됩니다.

따라서 1 번과 2 번 문제를 4 번 문제의 원인으로 삼지 마십시오. 생각할 때 좋은 이름을 사용하십시오. 할 수 없으면 의미없는 이름을 피하십시오.

Orbit의 의견 에서 Lightness Races는 이러한 기능이 인위적이고 나쁜 이름 자체를 가지고 있음을 올바르게 지적합니다. 다음은이 스타일을 일부 코드에 적용하는 예입니다.

var user = db.t_ST_User.Where(_user => string.Compare(domain,  
_user.domainName.Trim(), StringComparison.OrdinalIgnoreCase) == 0)
.Where(_user => string.Compare(samAccountName, _user.samAccountName.Trim(), 
StringComparison.OrdinalIgnoreCase) == 0).Where(_user => _user.deleted == false)
.FirstOrDefault();

줄 바꿈이 필요하지 않은 경우에도 그 소음 흐름을 보는 것이 싫습니다. 이 스타일에서 어떻게 보이는지는 다음과 같습니다.

var user = db
    .t_ST_User
    .Where(
        _user => string.Compare(
            domain, 
            _user.domainName.Trim(), 
            StringComparison.OrdinalIgnoreCase
        ) == 0
    )
    .Where(
        _user => string.Compare(
            samAccountName, 
            _user.samAccountName.Trim(), 
            StringComparison.OrdinalIgnoreCase
        ) == 0
    )
    .Where(_user => _user.deleted == false)
    .FirstOrDefault()
;

보시다시피,이 스타일은 객체 지향 공간으로 이동하는 기능 코드와 잘 작동합니다. 중간 스타일로 좋은 이름을 내면 더 많은 힘을 얻을 수 있습니다. 그때까지 나는 이것을 사용하고 있습니다. 그러나 어쨌든 의미없는 결과 이름을 피할 수있는 방법을 찾으십시오. 그들은 내 눈을 아프게합니다.

반면에 한 줄에 더 많은 처리를할수록 한 페이지에서 더 많은 논리를 얻을 수있어 가독성이 향상됩니다.

나는 이것에 전혀 동의하지 않습니다. 두 코드 예제를 보면이를 잘못된 것으로 호출합니다.

var a = F(G1(H1(b1), H2(b2)), G2(c1));

읽는 소리가 들립니다. "가독성"은 정보 밀도를 의미하지 않습니다. "읽고 이해하고 유지하기 쉽다"는 의미입니다.

때로는 코드가 단순하고 한 줄을 사용하는 것이 좋습니다. 다른 경우에는 그렇게하면 읽기가 더 어려워 져 한 줄에 더 많은 것을 넣는 것 외에는 분명한 이점이 없습니다.

그러나 "충돌을 쉽게 진단 할 수있다"는 것은 코드를 유지하기 쉽다는 것을 의미한다고 주장합니다. 충돌하지 않는 코드는 유지 관리가 훨씬 쉽습니다. "쉬운 유지 관리"는 주로 일련의 자동화 된 테스트로 백업되고 이해하기 쉬운 코드를 통해 달성됩니다.

따라서 코드가 자주 충돌하고 더 나은 디버그 정보가 필요하기 때문에 단일 표현식을 여러 변수가 포함 된 여러 줄로 변환하는 경우에는 중지하고 코드를보다 강력하게 만드십시오. 디버깅하기 쉬운 코드를 디버깅 할 필요가없는 코드를 작성하는 것이 좋습니다.

선택한 이름이 전혀 의미가 없으므로 첫 번째 예인 단일 할당 형식을 읽을 수 없습니다. 그것은 당신의 내부 정보를 공개하지 않으려는 인공물 일 수 있습니다. 진정한 코드는 그 점에서 좋을 것입니다. 어쨌든 정보 밀도가 매우 낮기 때문에 일반적으로 이해하기 쉽지 않습니다.

두 번째 예는 터무니없는 정도로 압축됩니다. 함수에 유용한 이름이 있다면, 너무 많지 않아서 읽기 쉽고 잘 읽을 수 있지만 다른 방향으로는 혼동됩니다.

의미있는 이름을 소개 한 후에는 그 형태 중 하나가 자연스러워 보이는지 또는 촬영해야 할 황금색 중간 점이 있는지 확인할 수 있습니다 .

이제 코드를 읽을 수있게되었으므로 대부분의 버그가 분명하고 다른 버그는 최소한 숨기는 데 어려움이 있습니다.

항상 그렇듯이 가독성과 관련하여 실패는 극단 입니다. 당신이 취할 수 있는 , 좋은 프로그래밍 조언을 종교적인 규칙으로 바꿀하고, 완전히 읽을 수없는 코드를 생성하는 데 사용합니다. 이 날 믿지 않는 경우에 (,이 두 가지 체크 아웃 IOCCC의 수상자 borsanyi 및 고렌을 그들이 완전히 읽을 수있는 코드를 렌더링하는 기능을 사용하는 방법을 다르게 살펴 힌트 :. Borsanyi 사용 정확히 하나 개의 기능을 고렌 훨씬, 훨씬 더 ...)

귀하의 경우 두 가지 극단은 1) 단일 표현식 문만 사용하고 2) 모든 것을 크고 간결하고 복잡한 문으로 결합합니다. 극단적 인 접근 방식은 코드를 읽을 수 없게 만듭니다.

프로그래머로서 당신의 임무 는 균형을 잡는 것 입니다. 당신이 쓰는 모든 진술에 대하여, "이 문장을 이해하기 쉽고, 내 함수를 읽을 수있게하는 역할을합니까?"라는 질문에 대답하는 것이 당신의 임무입니다.

요점은 결정할 수있는 단일의 측정 가능한 복잡성이없고, 단일의 진술에 포함되는 것이 좋은 점입니다. 예를 들면 다음과 같습니다.

double d = sqrt(square(x1 - x0) + square(y1 - y0));

이것은 매우 복잡한 진술이지만 소금을 쓸만한 프로그래머라면 이것이 무엇을하는지 즉시 파악할 수 있어야합니다. 꽤 잘 알려진 패턴입니다. 따라서, 이것보다 훨씬 더 읽기 쉽다

double dx = x1 - x0;
double dy = y1 - y0;
double dxSquare = square(dx);
double dySquare = square(dy);
double dSquare = dxSquare + dySquare;
double d = sqrt(dSquare);

잘 알려진 패턴을 의미없는 수의 간단한 단계로 나눕니다. 그러나 귀하의 질문에 대한 진술

var a = F(G1(H1(b1), H2(b2)), G2(c1));

거리 계산보다 한 번의 작업으로도 너무 복잡해 보입니다 . 물론,이에 대해 아무것도 모르고 날의 직접적인 결과이다 F(), G1(), G2(), H1(), 또는 H2(). 그들에 대해 더 많이 알고 있다면 다르게 결정할 수 있습니다. 그러나 이것이 바로 문제입니다. 성명서의 권장되는 복잡성은 상황과 관련된 작업에 크게 좌우됩니다. 그리고 프로그래머로서 여러분은이 맥락을 살펴보고 단일 진술에 포함 할 것을 결정해야합니다. 가독성에 관심이있는 경우이 책임을 일부 정적 규칙으로 오프로드 할 수 없습니다.

@Dominique, 나는 당신의 질문의 분석에서 "가독성"과 "유지 보수성"이 별개의 두 가지라는 실수를하고 있다고 생각합니다.

유지 보수가 가능하지만 읽을 수없는 코드를 가질 수 있습니까? 반대로, 코드를 매우 읽을 수있는 경우 읽을 수있는 이유 때문에 코드를 유지할 수없는 이유는 무엇입니까? 나는이 요소들을 서로 대항하여 연주하는 프로그래머에 대해 들어 본 적이 없다.

중첩 된 함수 호출에 중간 변수를 사용할지 여부를 결정하는 관점에서 주어진 3 개의 변수, 5 개의 개별 함수에 대한 호출 및 3 개의 깊은 중첩 된 호출의 경우 적어도 일부 중간 변수를 사용하여 분류하는 경향이 있습니다 . 당신이 한 것처럼.

그러나 함수 호출이 전혀 중첩되어서는 안된다는 말은 확실하지 않습니다. 상황에서 판단의 문제입니다.

나는 다음 사항들이 판단에 달려 있다고 말할 것이다.

1. 호출 된 함수가 표준 수학 연산을 나타내는 경우 결과가 예측할 수없고 독자가 반드시 정신적으로 평가할 수없는 모호한 도메인 논리를 나타내는 함수보다 중첩 될 수 있습니다.

2. 단일 매개 변수가있는 함수는 다중 매개 변수가있는 함수보다 중첩 (내부 또는 외부 함수)에 참여할 수 있습니다. 서로 다른 중첩 수준에서 다른 민족의 기능을 혼합하면 코드가 돼지 귀처럼 보이기 쉽습니다.

3. 프로그래머가 특정 방식으로 표현 하는 데 익숙한 함수의 둥지 -아마도 표준 구현을 가진 표준 수학 기술이나 방정식을 나타 내기 때문에 중간 변수로 나뉘어져 있는지 읽고 확인하기가 더 어려울 수 있습니다.

4. 간단한 기능을 수행하고 이미 읽기가 쉽고, 너무 세분화되어 원자화 된 작은 함수 호출 중첩 은 전혀 분류되지 않은 것보다 읽기 가 더 어려울 수 있습니다.

둘 다 차선책입니다. 의견을 고려하십시오.

// Calculating torque according to Newton/Dominique, 4th ed. pg 235
var a = F(G1(H1(b1), H2(b2)), G2(c1));

또는 일반적인 기능이 아닌 특정 기능 :

var a = Torque_NewtonDominique(b1,b2,c1);

어떤 결과를 표시할지 결정할 때 각 설명에 대해 비용 (복사 대 참조, l- 값 대 r- 값), 가독성 및 위험을 개별적으로 염두에 두십시오.

예를 들어, 간단한 단위 / 유형 변환을 자신의 행으로 옮기면 아무런 가치가 없습니다. 읽기 쉽고 실패하지 않기 때문입니다.

var radians = ExtractAngle(c1.Normalize())
var a = Torque(b1.ToNewton(),b2.ToMeters(),radians);

크래시 덤프 분석에 대한 걱정과 관련하여 일반적으로 입력 유효성 검사가 훨씬 중요합니다. 실제 크래시는 해당 함수를 호출하는 것이 아니라 이러한 함수 내에서 발생할 가능성이 높습니다. 일이 터졌습니다. 입력 유효성 검사가 포착하는 위치가 어디에서 발생했는지 아는 것보다 문제가 발생하기 시작한 위치를 아는 것이 더 중요합니다.

가독성은 유지 보수성의 주요 부분입니다. 의심하십니까? 모르는 언어 (프로그래밍 언어와 프로그래머의 언어 모두)에서 대규모 프로젝트를 선택하고 리팩토링에 대해 어떻게 생각하는지 살펴보십시오.

가독성을 80에서 90 사이로 유지합니다. 다른 10-20 %는 리팩토링에 얼마나 적합한 지입니다.

즉, 최종 함수 (F)에 2 개의 변수를 효과적으로 전달합니다. 이 2 개의 변수는 3 개의 다른 변수를 사용하여 생성됩니다. F에 이미 b1, b2 및 c1을 전달하는 것이 좋을 것입니다. F가 이미 존재하는 경우 F의 구성을 수행하고 결과를 반환하는 D를 만듭니다. 이 시점에서 D에게 좋은 이름을 지정하는 것만으로도 어떤 스타일을 사용하든 상관 없습니다.

관련이없는 경우 페이지의 논리가 가독성을 높이는 데 도움이된다고 말합니다. 즉, 메트릭은 페이지가 아니며 메서드이며 메서드에 포함 된 LESS 논리가 더 읽기 쉽습니다.

읽을 수 있음은 프로그래머가 논리 (입력, 출력 및 알고리즘)를 머리에 담을 수 있음을 의미합니다. 그렇게할수록 프로그래머는 그것을 덜 이해할 수 있습니다. 순환 복잡성에 대해 읽어보십시오.

C # 또는 C ++에 있더라도 디버그 빌드에있는 한 가능한 해결책은 함수를 래핑하는 것입니다.

var a = F(G1(H1(b1), H2(b2)), G2(c1));

oneline 표현식을 작성할 수 있으며 여전히 스택 추적을보고 문제가있는 위치를 파악할 수 있습니다.

returnType F( params)
{
    returnType RealF( params);
}

물론 같은 줄에서 같은 함수를 여러 번 호출하면 어떤 함수를 알 수 없지만 여전히 식별 할 수 있습니다.

• 함수 매개 변수 살펴보기
• 매개 변수가 동일하고 함수에 부작용이없는 경우 두 개의 동일한 호출이 두 개의 동일한 호출 등이됩니다.

이것은 은색 총알이 아니지만 중간 정도는 아닙니다.

함수 그룹 랩핑은 코드의 가독성에 더 유리할 수 있습니다.

type CallingGBecauseFTheorem( T b1, C b2)
{
     return G1( H1( b1), H2( b2));
}

var a = F( CallingGBecauseFTheorem( b1,b2), G2( c1));

내 의견으로는, 자체 문서화 코드는 언어와 상관없이 유지 관리 성과 가독성 모두에 더 좋습니다.

위에서 언급 한 내용은 조밀하지만 "자체 문서화"입니다.

double d = sqrt(square(x1 - x0) + square(y1 - y0));

단계적으로 나뉘면 (테스트하기 쉬워야 함) 위에서 설명한대로 모든 컨텍스트가 손실됩니다.

double dx = x1 - x0;
double dy = y1 - y0;
double dxSquare = square(dx);
double dySquare = square(dy);
double dSquare = dxSquare + dySquare;
double d = sqrt(dSquare);

그리고 분명히 목적을 명확하게 나타내는 변수 및 함수 이름을 사용하는 것은 매우 중요합니다.

"if"블록조차도 자체 문서화에 좋거나 나쁠 수 있습니다. 처음 두 가지 조건을 쉽게 세 번째로 테스트하도록 강요 할 수 없기 때문에 이것은 좋지 않습니다 ... 모두 관련이 없습니다.

if (Bill is the boss) && (i == 3) && (the carnival is next weekend)

이것은 "집합적인"의미를 가지며 테스트 조건을 만들기가 더 쉽습니다.

if (iRowCount == 2) || (iRowCount == 50) || (iRowCount > 100)

그리고이 진술은 자체 문서화 관점에서 볼 때 임의의 문자열입니다.

var a = F(G1(H1(b1), H2(b2)), G2(c1));

위의 진술을 살펴보면, H1과 H2 함수가 단일 "H"함수로 통합되는 대신 동일한 "시스템 상태 변수"를 변경하는 경우 유지 보수성은 여전히 ​​중요한 과제입니다. H2 기능은 H2를보고 깨뜨릴 수 있습니다.

체계적으로 감지하고 적용 할 수있는 강력하고 빠른 규칙이 없기 때문에 올바른 코드 디자인은 매우 어려운 문제라고 생각합니다.