컴파일시 최적화 된이 간단한 조건 연산자가 될 것입니까? (.그물)

Question

레거시 코드로 작업하면서, 나는이 같은

bool isAEqualsB = (a == b) ? true : false; 

과 같은 많은 문장이 있다는 것을 알았습니다.

bool isAEqualsB = (a == b) 

아니면 컴파일 시간에 최적화 될까요?

미리 감사드립니다.

Santi! =)

Answer 1

성능을 무시 - 그 그렇게 가능성, 당신이 이 적절한 벤치 마크 관련이을 입증했습니다 때까지 당신이 어떻게 생각하는지 안 병목 수 있습니다.

나는 을 절대적으로 읽고 가독성에 신경을 썼다. 그리고 그 관점에서, 나는 두 번째 접근법이 훨씬 더 좋다고 생각하고, 확실히 그것을 사용할 것이다.

편집 : 최적화의 관점에서, 그것을 최적화하지 않는 C# 컴파일러과 같습니다

// First form 
    IL_0000: ldarg.0 
    IL_0001: ldarg.1 
    IL_0002: beq.s  IL_0007 
    IL_0004: ldc.i4.0 
    IL_0005: br.s  IL_0008 
    IL_0007: ldc.i4.1 
    IL_0008: stloc.0 

    // Second form 
    IL_0009: ldarg.0 
    IL_000a: ldarg.1 
    IL_000b: ceq 
    IL_000d: stloc.1 

는하지만, 물론 중요합니다 IL 아니다 - 그것은 JIT 컴파일러가하는 일입니다. 이제 IL 크기의 차이가 일 수 있습니다.은 인라이닝과 그렇지 않은 것의 차이를 의미합니다 ...

Answer 2

최적화 여부에 관계없이 첫 번째 문을 대체하는 것이 좋습니다.

bool isAEqualsB = (a == b) 

이것은 깨끗한 코드입니다. a == b은 부울 식입니다. 다른 것은 필요 없습니다. 코드베이스의 유지 보수성과 가독성을 개선하기위한 리팩토링으로 생각하십시오.

Answer 3

확실히 다시 써주십시오. 컴파일러는이 최적화를 만들지 만, 시간을 현 시점에서 수정하면 코드가 훨씬 더 읽기 쉬울 것이므로 중요하지 않습니다.

더 나은 점은 먼저 변수 선언을 사용하지 말고 용도를 ​​a == b으로 바꿉니다.

또한,이 코드를 작성 누구든지 찾아 그들에게 악마의 눈 :

Answer 4

코드가 작동하면, 나는 그에게 그것이 길을 떠날 줄을 제공합니다. 다시 쓸 때 쓰는 시간은 결코 상환되지 않습니다. 예, 두 번째 방법은 더 명확하고 읽기 쉽지만, 패턴을 500 번 이상 변경하고 오류를 만들 가능성이 있습니다 (작업 코드를 작동하지 않는 코드로 바꾸는) 제로. 리팩토링에서 얻을 수있는 작은 가독성 이점은 변경 작업과 관련된 시간과 위험을 보상하지 않습니다.

실행과 관련하여 컴파일러는 첫 번째를 두 번째로 최적화합니다. 그러나 다른 사람들이 말했듯이 컴파일러가 최적화하지 않더라도 성능 향상은 미미합니다.

하지만 새로운 코드에는 두 번째 방법을 사용합니다.