if / else 또는 boolean 식을 통한 부울 할당 중 유지 관리가 더 쉬운 것은?


11

어느 것이 유지 보수가 용이 한 것으로 간주됩니까?

if (a == b) c = true; else c = false;

또는

 c = (a == b);

Code Complete를 살펴 보았지만 답변을 찾을 수 없습니다.

나는 첫 번째가 더 읽기 쉽다고 생각합니다 (문자 그대로 큰 소리로 읽을 수 있음). 두 번째 것은 확실히 더 의미가 있고 코드를 줄이지 만 C # 개발자가 유지할 수 있는지 확실하지 않습니다 (예 : Python 에서이 관용구를 더 많이 볼 것으로 예상됩니다).


3
둘은 동일하지 않습니다. else c = false첫 번째 에는 a가 필요 하거나 ||=두 번째 에는 과제를 지정 하십시오.

17
첫 번째 양식을 두 번 수정해야한다는 사실이 귀하의 질문에 대한 답변이라고 생각합니다!
James

7
@James에 동의합니다. 두 번째 형태는 장황하지는 않지만 이해하기가 매우 간단하며 그 의미에 대해 모호하지 않습니다. 트릭이나 지름길은 없으며 개념이 간단하기 때문에 짧습니다. 버그로 첫 번째 코드를 코딩했으며 버그를 수정하기 위해 버그를 수정해야 했지만 여전히 완벽하지는 않습니다 (중괄호 사용 불일치)는 생각만큼 간단하지 않다는 긍정적 인 증거입니다.
에릭 킹

5
와우, C # 개발자는 실제로 첫 번째 양식을 수용 가능한 것으로 간주합니까? 이것은 ... 그들에 대한 나의 신뢰를 심각하게 감소시킵니다. 내 경험상, 첫 번째 형식을 사용하면 부울 식을 완전히 오해 할 수 있습니다.
Andres F.

2
흥미로운 점을 유지하기 위해 여기 또 다른 옵션이 있습니다.c = a==b ? true : false;
FrustratedWithFormsDesigner

답변:


14

두 번째 옵션이 더 좋습니다.

코드의 의도를 모호하게하여 유지 관리 성을 손상시키는 영리한 프로그래밍 바로 가기에주의해야 할 확실한 이유가 있습니다. 그래서 나는 그 질문을한다고 당신을 비난하지 않습니다.

그러나 나는 c = (a == b);영리한 트릭의 예 라고 생각하지 않습니다 . 간단한 개념을 간단하게 표현한 것입니다. 최대한 간단합니다.

첫 번째 예제의 적절하고 "유지 가능한"형식은 누락 된 중괄호와 한 줄로 구성 하지 않고 영리한 바로 가기로 간주하여 다음 코드를 생성합니다.

if (a == b)
{
    c = true; 
}
else 
{
    c = false;
}

내 경험상, 이러한 오류가 발생하기 쉬운 간단한 부울 논리를 작성하는 것은 "iffy"코드의 표시입니다. 이 코드베이스에서 더 복잡한 논리를 처리하는 방법이 궁금합니다.


15

먼저, 두 형식이 동일하지 않다는 것을 알아야합니다.

if (a == b) c = true;

ca이 같으면 true로 설정되고, 그렇지 않으면 b값이 이미있는 그대로 유지됩니다.

c = (a == b);

ca이 같으면 true로 설정되고 그렇지 않으면 bfalse로 설정됩니다.

첫 번째 양식의 스타일에서 두 번째 양식과 동등한 것을 원하면 다음과 같이 작성해야합니다.

if (a == b) {
  c = true;
} else c = false;

이제 두 가지 중 어느 것이 더 읽기 쉽고 유지 관리가 용이하며 어떤 것이 변경되면 버그가 발생할 가능성이 적습니다. 두 번째 형태를 고수하십시오.


그렇습니다. 내 질문을 업데이트했습니다.
Bret Walker

두 번째 형식은 너무 길고 복잡하다고 생각합니다. 효과를 원한다면 부울 할당을 사용하십시오.
Reinstate Monica-M. Schröder

11

첫 번째 양식이 더 읽기 쉽다는 것에 동의하지 않습니다. 한 줄에 두 개의 문장을 갖는 것은 관용적 C #이 아니며, if중괄호를 사용하지 않고 문장을 사용하지 않는 것이 좋습니다 .

둘째, 두 번째 양식의 유지 관리가 어려워 보이지 않습니다. 유지할 것이 없습니다. 그것은 관계의 간단한 문의 ab그것은 더 이상 간단하게 표현 할 수 없습니다.

두 번째 양식을 선호하는 또 다른 이유 c는 단일 진술로 선언 하고 할당 할 수 있기 때문입니다.

bool c = (a == b);

변수를 수정하면 쉽게 오류가 발생할 수 있으므로 피해야합니다. if명령문을 사용 하려면 변수를 조건부 전에 선언 한 다음 수정해야합니다.


의사 코드로 한 줄에있는 두 문장을 읽었습니다
Jimmy Hoffa

1
" Another reason to prefer the second form is that you can declare c and assign it in a single statement"에 대한 +1
Andres F.

0

"보다 유지 보수가 용이 한"것은 매우 주관적 일 수 있습니다.

나는 일반적으로 코드 축소보다 가독성과 의도를 선호합니다. 축소 된 형식을 사용하여 8 가지 유형의 문자를 저장한다고 생각합니다.

언어를 중심으로 언어와 문화를 취하는 것은 '가독성'의 특징이라고 생각합니다.

결과 바이트 코드를 최적화하기 위해 코드를 줄이면 성능이 저하 될 수 있지만 프로파일 링 후에는주의해서 수행해야합니다.


주관적 : Duh. 코드 축소 : (과도하지 않은 경우) 선명도를 향상시키고 의도를보다 잘 전달할 수 있습니다. 성능 : 전혀 걱정할 필요가 없습니다. 최적화는 때때로 중요하지만, 실제로 커널이나 드라이버를 작성하더라도 실제로는 중요하지 않기 때문에 최적화에 속하지 않습니다.

4
첫 번째 양식에는 수정해야 할 버그가 1 개 이상 있었으며 자세한 내용은 숨겨져있었습니다. 두 번째 형태는 간단하고 요점이며 버그가 없었습니다. 난 내 경우를 휴식. 어쨌든 주된 목적은 적은 문자를 입력하지 않는 것입니다! 그리고이 질문은 성능에 관한 것이 아니며이 경우에는 관련이 없습니다.
Andres F.

@delnan 정확히 내 요점, Duh. 누군가의 코드 축소는 다른 사람의 명확성입니다. 나는 최적화를 주요 관심사로 인용하지 않았다 ... 나는 그것을 예로 사용했다. 영리한 트릭을 추가하거나 표준을 벗어나는 이유는 귀하 / 문화 / 기업이 읽을 수있는 것으로 간주하는 것에 따라 균형을 이루어야합니다.
Johnnie

1
깨끗한 부울 식을 작성하는 것은 영리한 속임수가 아닙니다!
Andres F.

나는 당신이 실제로 질문의 정신을 다루고 근본적인 개념을 세우는 데 사용되는 미친 비유가 아니라면 당신의 의견에 더 많은 공덕을 쏟을 것 같습니다.
Johnnie

0

두번째. 반복 횟수가 적고 (DRY) 진행 상황을 이해하기가 쉬워서 동일한 c지 아닌지의 가치 를 지니고 a있습니다 b.

IMHO, 더 나은 것

c = a == b

내가 쓰는 것처럼

  • 1 + 2 + 3 대신에 ((1 + 2) + 3)
  • 5 + 3 * 7 대신에 (5 + (3 * 7))

명백하고 사소한 불필요한 코드는 미덕이 아닙니다. 어수선합니다.


-4

다운 투표자 여러분, 수정 된 답변에 무엇이 잘못되었는지 자세히 설명해주십시오.

예, c = (a == b);읽기 어려울 수 있습니다 (아직 StyleCop은 불필요한 괄호에 대해 불평합니다).하지만 여전히의 단순함을 좋아합니다 a == b. 따라서, 여기에 내가 때 모두를 사용하려면 무엇 ab같다 :

private static bool NoPeriod
{
    get
    {
        return this.MyWaveLength == this.HerWaveLength;
    }
}

그리고 당신은 할 수 있습니다 : this.c = this.NoPeriod대신 :

this.c = this.MyWavelength == this.HerWaveLength;

1
그래서 당신은 의미 않았 return this.MyWaveLength = this.HerWaveLength;거나 return this.MyWaveLength == this.HerWaveLength;대신?
제시 C. 슬라이서

5
뭐!? c = (a == b);오류가 발생하지 않습니다. 원래 질문의 첫 번째 형식 은 OP 자체가 버그를 수정하기 위해 자신의 질문을 편집해야 함을 보여 주듯이 오류가 발생하기 쉽다것입니다 !
Andres F.

귀하의 제안 된 솔루션에 버그가 있다고 생각합니다 = vs. ==
Ondra

@ Ondra Morský, 감사합니다 ... 컴파일러가 나를 잡았습니다.
Job

6
StyleCop에 익숙하지 않지만 불필요한 괄호가 나쁘다고 알려 주면 끄십시오. 불필요한 괄호는 컴파일러에 필요하지 않지만 인간의 눈에는 매우 좋을 수 있습니다. 당신이 쓴다면 c = a == b; 컴파일러는 잘 알아낼 수 있지만 인간에게는 더 어렵습니다.
Michael Shaw
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.