간결함이 더 이상 미덕이 아닌 시점은 무엇입니까?

최근 버그 수정으로 인해 다른 팀 구성원이 작성한 코드를 살펴 보았습니다.이 코드는 C #입니다.

return (decimal)CostIn > 0 && CostOut > 0 ? (((decimal)CostOut - (decimal)CostIn) / (decimal)CostOut) * 100 : 0;

이제는 모든 캐스트에 대한 합당한 이유가 있으므로 여전히 따르기가 매우 어렵습니다. 계산에 사소한 버그가 있었고 문제를 해결하기 위해 그것을 풀어야했습니다.

코드 검토에서이 사람의 코딩 스타일을 알고 있으며 그의 접근 방식은 짧을수록 거의 항상 더 좋습니다. 그리고 물론 거기에는 가치가 있습니다. 우리는 모두 잘 배치 된 몇몇 연산자로 정리할 수있는 불필요하게 복잡한 조건부 논리 체인을 보았습니다. 그러나 그는 하나의 진술로 가득 찬 연산자 체인을 따르는 데있어 나보다 분명히 더 능숙합니다.

물론 이것은 궁극적으로 스타일의 문제입니다. 그러나 코드 간결성을위한 노력이 유용하지 않고 이해의 장벽이되는 시점을 인식하기 위해 어떤 글을 작성하거나 연구 한 적이 있습니까?

_{캐스트 이유는 Entity Framework입니다. db는 이들을 널 입력 가능 유형으로 저장해야합니다. 소수? C #의 Decimal과 같지 않으며 캐스팅해야합니다.}

현존하는 연구에 대한 질문에 대답하기 위해

그러나 코드 간결성을위한 노력이 유용하지 않고 이해의 장벽이되는 시점을 인식하기 위해 어떤 글을 작성하거나 연구 한 적이 있습니까?

예,이 분야에 대한 연구가있었습니다.

이 내용을 이해하려면 메트릭 을 계산하는 방법을 찾아야 합니다 (다른 답변과 마찬가지로 지혜와 직관을 기준으로 비교를 수행하는 대신) 정량적으로 비교할 수 있습니다. 살펴본 잠재적 인 측정 항목 중 하나는

순환 복잡성 ÷ 소스 코드 라인 ( SLOC )

코드 예제에서이 비율은 매우 높습니다. 모든 것이 한 줄로 압축 되었기 때문입니다.

SATC는 가장 효과적인 평가는 크기와 [Cyclomatic] 복잡성의 조합이라는 것을 발견했습니다. 복잡성과 크기가 큰 모듈은 안정성이 가장 낮은 경향이 있습니다. 크기가 작고 복잡도가 높은 모듈은 코드가 매우 간결하여 변경 또는 수정이 어렵 기 때문에 안정성 위험이 있습니다.

링크

관심이 있다면 몇 가지 참고 자료가 있습니다.

McCabe, T. 및 A. Watson (1994), 소프트웨어 복잡성 (CrossTalk : The Journal of Defense Software Engineering).

Watson, AH, & McCabe, TJ (1996). 구조적 테스트 : Cyclomatic Complexity Metric (NIST Special Publication 500-235)을 사용한 테스트 방법론. McCabe Software 웹 사이트에서 2011 년 5 월 14 일에 확인 함 : http://www.mccabe.com/pdf/mccabe-nist235r.pdf

Rosenberg, L., Hammer, T., Shaw, J. (1998). 소프트웨어 메트릭스 및 신뢰성 (소프트웨어 신뢰성 엔지니어링에 관한 IEEE 국제 심포지엄의 절차). Penn State University 웹 사이트에서 2011 년 5 월 14 일에 확인 함 : http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.104.4041&rep=rep1&type=pdf

내 의견과 해결책

개인적으로, 나는 간결성을 소중히 여기지 않았으며 가독성 만 가지고 있습니다 . 때로는 간결함이 가독성에 도움이되고 때로는 그렇지 않습니다. 더 중요한 것은 WOC (Write-Only Code ) 대신 ROC (Really Obvious Code) 를 작성하는 것입니다.

재미를 위해 여기에 글을 쓰는 방법이 나와 있으며, 팀원들에게 글을 쓰도록 요청하십시오.

if ((costIn <= 0) || (costOut <= 0)) return 0;
decimal changeAmount = costOut - costIn;
decimal changePercent = changeAmount / costOut * 100;
return changePercent;

또한 작업 변수를 도입하면 정수 산술 대신 고정 소수점 산술을 트리거하는 데 따른 부작용이 발생하므로 모든 캐스트 decimal가 필요하지 않습니다.

간결함은 중요한 것들 주위의 혼란을 줄이면 좋지만, 간결 해지면 너무 많은 관련 데이터를 너무 조밀하게 따라 쉽게 따르지 않으면 관련 데이터가 복잡해져 문제가 있습니다.

이 특별한 경우에, 캐스트 decimal는 계속해서 반복된다; 아마도 다음과 같이 다시 작성하는 것이 더 좋습니다.

var decIn = (decimal)CostIn;
var decOut = (decimal)CostOut;
return decIn > 0 && CostOut > 0 ? (decOut - decIn ) / decOut * 100 : 0;
//                  ^ as in the question

갑자기 논리를 포함하는 선이 훨씬 짧고 하나의 수평선에 맞기 때문에 스크롤하지 않고도 모든 것을 볼 수 있으며 그 의미는 훨씬 더 분명합니다.

이 주제에 대한 특정 연구를 인용 할 수는 없지만 코드 내 모든 캐스트는 자신을 반복하지 말 것 원칙을 위반하는 것이 좋습니다. 코드가 수행하려고하는 것으로 costInand and costOuttype을 변환 Decimal한 다음 이러한 변환 결과에 대한 온전한 검사를 수행하고 검사가 통과되면 변환 된 값에 대한 추가 작업을 수행합니다. 실제로, 코드는 변환되지 않은 값에 대한 온 전성 검사 중 하나를 수행하여 costOut이 0보다 크지 만 Decimal나타낼 수 있는 가장 작은 0이 아닌 크기의 절반보다 작은 값을 보유 할 가능성을 높 입니다. 코드는 Decimal변환 된 값을 보유하기 위해 유형의 변수를 정의한 다음 그에 따라 작동하면 훨씬 명확 해집니다.

당신이의 비율에 더 관심이있을 것이라고 호기심 보인다 Decimal의 표현 costIn과 costOut실제 값의 비율보다 더 costIn와 costOut코드가 일부 다른 목적으로 소수점 표현을 사용하려고하지 않는 한,. 코드가 이러한 표현을 더 많이 사용하려는 경우 코드 전체에 캐스트 시퀀스가 ​​연속되는 것이 아니라 해당 표현을 보유 할 변수를 작성하는 추가 인수가됩니다.

이 코드를보고 "비용이 어떻게 0 (또는 이하)이 될 수 있습니까?"라고 묻습니다. 그 특별한 경우는 무엇입니까? 코드는

bool BothCostsAreValidProducts = (CostIn > 0) && (CostOut > 0);
if (!BothCostsAreValidProducts)
  return NO_PROFIT;
else {
   // that calculation here...
}

나는 이름을 여기에서 추측하고 있습니다 : 변경 BothCostsAreValidProducts하고 NO_PROFIT적절합니다.

간결함 은 그 자체가 미덕 이라기보다는 목적을 의미한다는 것을 잊었을 때 미덕이되는 것을 멈 춥니 다 . 우리는 간결함과 관련이 있기 때문에 간결함을 좋아하고, 간단한 코드는 이해하기 쉽고 수정하기 쉽고 버그가 적기 때문에 단순함을 좋아합니다. 결국 우리는 코드가 이러한 목표를 달성하기를 원합니다.

1. 최소한의 작업으로 비즈니스 요구 사항 충족

2. 버그를 피하십시오

3. 앞으로도 계속해서 1과 2를 충족시키는 변경을 할 수 있습니다.

이것이 목표입니다. 모든 설계 원칙 또는 방법 (KISS, YAGNI, TDD, SOLID, 증명, 유형 시스템, 동적 메타 프로그래밍 등)은 이러한 목표를 달성하는 데 도움이되는 정도로 미덕입니다.

해당 라인이 최종 목표를 놓친 것 같습니다. 짧지 만 간단하지 않습니다. 실제로 동일한 캐스팅 작업을 여러 번 반복하여 불필요한 중복성을 포함합니다. 코드를 반복하면 복잡성과 버그 가능성이 높아집니다. 캐스팅과 실제 계산을 혼합하면 코드를 따르기가 어렵습니다.

라인에는 가드 (특수 케이싱 0), 유형 캐스팅 및 계산의 세 가지 문제가 있습니다. 개별적으로 고려할 때 각 문제는 매우 간단하지만 모두 같은 표현으로 혼합되어 따르기 어렵습니다.

그것이 CostOut처음 사용되었을 때 캐스트되지 않는 이유 는 분명 하지 않습니다 CostIn. 좋은 이유가있을 수 있지만 의도는 명확하지 않습니다 (적어도 컨텍스트가없는 것은 아님). 관리자는 숨겨진 가정이있을 수 있기 때문에이 코드를 변경하는 것에주의해야합니다. 그리고 이것은 유지 보수성에 대한 혐오입니다.

CostIn0과 비교하기 전에 캐스팅되기 때문에 부동 소수점 값이라고 가정합니다. (int 인 경우 캐스팅 할 이유가 없습니다). 그러나 CostOut부동 소수점 인 경우 부동 소수점 값은 작지만 0이 아닌 10 진수로 캐스팅 할 때 0이되기 때문에 코드가 모호한 0으로 나누기 버그를 숨길 수 있습니다 (적어도 가능할 것이라고 생각합니다).

따라서 문제는 간결하거나 부족한 것이 아니며, 유지 관리하기 어려운 코드로 이어지는 문제의 논리와 혼란이 반복됩니다.

캐스트 된 값을 보유하는 변수를 도입하면 아마도 수의 코드 수로 계산되는 코드의 크기가 증가하지만 복잡성을 줄이고 우려를 분리하며 명확성을 향상시켜 이해하고 유지하기 쉬운 코드의 목표에 더 가깝게 만듭니다.

간결함은 미덕이 아닙니다. 가독성은 미덕입니다.

간결함은 미덕을 달성하는 도구 일 수도 있고, 예와 같이 정확히 반대의 것을 달성하는 도구 일 수도 있습니다. 이런 식 으로든, 그것은 그 자체의 가치도 거의 갖지 않습니다. 코드가 "가능한 한 짧아야"한다는 규칙은 "가능한 한 외설적"으로 대체 될 수 있습니다. 더 큰 목적을 달성하지 않으면 모두 의미가없고 잠재적으로 피해를줍니다.

또한 게시 한 코드는 간결한 규칙을 따르지 않습니다. 상수는 M 접미사 선언했다 끔찍한 대부분의 (decimal)컴파일러가 남아 촉진하는 것처럼 캐스트는 피할 수 int에 decimal. 나는 당신이 묘사하는 사람이 단지 간결성을 변명으로 사용하고 있다고 생각합니다. 고의적으로는 아니지만 여전히 가능성이 높습니다.

수년간의 경험에서, 나는 최고의 간결함이 시간의 것임을 믿게되었습니다 . 시간은 다른 모든 것을 지배합니다. 여기에는 성능 시간 (프로그램이 작업을 수행하는 데 걸리는 시간)과 유지 관리 시간 (기능을 추가하거나 버그를 수정하는 데 걸리는 시간)이 모두 포함됩니다. (이 두 가지의 균형을 맞추는 방법은 문제의 코드가 얼마나 자주 수행되고 있는지에 따라 달라집니다. 조기 최적화는 여전히 모든 악의 근원 이라는 것을 기억하십시오 .) 코드의 간결함은 두 가지의 간결성을 향상시키기위한 것입니다. 더 짧은 코드는 일반적으로 더 빨리 실행되며 일반적으로 이해하고 유지하기가 더 쉽습니다. 둘 중 하나도 수행하지 않으면 순 부정적인 것입니다.

여기에 표시된 경우 텍스트의 간결함이 가독성을 희생하여 줄 수의 간결함으로 잘못 해석되어 유지 관리 시간이 늘어날 수 있다고 생각합니다. (캐스팅 수행 방법에 따라 수행 시간이 더 오래 걸릴 수 있지만 위의 행을 수백만 번 실행하지 않으면 걱정할 필요가 없습니다.)이 경우 반복적 십진법 캐스팅은 읽기가 어렵습니다. 가장 중요한 계산이 무엇인지 확인하십시오. 나는 다음과 같이 썼을 것이다.

decimal dIn = (decimal)CostIn;
decimal dOut = (decimal)CostOut;
return dIn > 0 && CostOut > 0 ? ((dOut - dIn) / dOut) * 100 : 0;

(편집 : 이것은 다른 답변과 동일한 코드이므로 끝났습니다.)

나는 삼항 연산자의 팬 ? :이므로 그것을 그대로 두겠습니다.

위의 거의 모든 답변과 마찬가지로 가독성은 항상 기본 목표가되어야합니다. 그러나 나는 또한 형식화가 변수와 줄 바꾸기를 통해 이것을 달성하는보다 효과적인 방법이라고 생각합니다.

return ((decimal)CostIn > 0 && CostOut > 0) ?
       100 * ( (decimal)CostOut - (decimal)CostIn ) / (decimal)CostOut:
       0;

대부분의 경우 순환 복잡성 인수에 강력하게 동의하지만 함수가 작고 단순하여 좋은 테스트 사례로 더 잘 해결할 수 있습니다. 호기심 때문에 왜 십진수로 캐스트해야합니까?

필자는 여기에서 가독성과 관련한 큰 문제가 서식이 완전히없는 것 같습니다.

나는 이것을 다음과 같이 쓸 것이다.

return (decimal)CostIn > 0 && CostOut > 0 
            ? (((decimal)CostOut - (decimal)CostIn) / (decimal)CostOut) * 100 
            : 0;

의 여부를 유형에 따라 CostIn및 CostOut부동 소수점 형 또는 정수형입니다, 캐스트의 일부는 불필요 할 수있다. 달리 float하고 double, 정수 값은 암시 적으로 추진된다 decimal.

코드는 서둘러 작성할 수 있지만 위의 코드는 훨씬 나은 변수 이름으로 작성해야합니다.

그리고 코드를 올바르게 읽으면 총 마진 계산을 시도합니다.

var totalSales = CostOut;
var totalCost = CostIn;
var profit = (decimal)(CostOut - CostIn);
var grossMargin = 0m; //profit expressed as percentage of totalSales

if(profit > 0)
{
    grossMargin = profit/totalSales*100
}

CostIn * CostOut은 정수라고 가정합니다.이를
쓰는 방법입니다
.M (돈)은 10 진수입니다

return CostIn > 0 && CostOut > 0 ? 100M * (CostOut - CostIn) / CostOut : 0M;

사람들이 이해하도록 코드가 작성되었습니다. 이 경우의 간결함은 많이 사지 않으며 관리자의 부담을 증가시킵니다. 이 간결성을 위해 코드를보다 자체 문서화 (더 나은 변수 이름)로 만들거나 왜 이런 방식으로 작동 하는지 설명하는 주석을 추가하여 확장해야합니다 .

오늘날 문제를 해결하기 위해 코드를 작성할 때 요구 사항이 변경되면 해당 코드가 내일 문제가 될 수 있습니다. 유지 보수는 항상 고려해야하며 코드의 이해도를 향상시키는 것이 필수적입니다.

간결함은 더 이상 미덕이 아닙니다

• 사전에 0을 점검하지 않고 Division이 있습니다.
• 널 검사는 없습니다.
• 정리가 없습니다.
• TRY CATCH는 오류를 처리 할 수있는 먹이 사슬을 던집니다.
• 비동기 작업의 완료 순서에 대한 가정
• 향후 일정 변경 대신 지연을 사용하는 작업
• 바늘 IO가 사용됩니다
• 낙관적 업데이트를 사용하지 않음

이것이 유효성 검사 단위 테스트를 통과했다면 새로운 사양이 추가되거나 새로운 테스트 또는 향상된 구현이 필요하고 코드의 간결성을 풀어야 할 때, 즉 문제가 발생합니다.

분명히 코드의 버그는 Q / A에 또 다른 문제가 있음을 보여 주므로 발견되지 않은 버그가 있다는 사실은 우려의 원인입니다.

코드의 "가독성"과 같은 비 기능적 요구 사항을 처리 할 때는 개발 관리자가이를 정의하고 수석 개발자가 관리해야하며 적절한 구현을 보장하기 위해 개발자가이를 존중해야합니다.

"가독성"과 "유지 보수 용이성"을 보장하기 위해 표준화 된 코드 구현 (표준 및 규칙)을 유지하십시오. 그러나 이러한 품질 속성이 정의되고 적용되지 않으면 위의 예와 같은 코드가 생깁니다.

이런 종류의 코드를보고 싶지 않다면 팀이 구현 표준 및 규칙에 동의하도록하고 코드를 작성하고 규칙을 준수하는지 확인하기 위해 임의 코드 검토 또는 스팟 검사를 수행하십시오.