조건부로 부작용이있는 것이 괜찮습니까? [닫은]

저는 미국의 모든 사람들이들은 대학에서 CS MS 프로그램에 입학하기위한 전제 조건으로 중간 데이터 구조 과정을 밟고 있습니다. 수업에서 작성된 한 줄의 코드가 내 눈을 사로 잡았습니다.

if (a > 33 | b++ < 54) {...}

이것은 내 직장에서 코드 검토를 통과하지 못합니다. 인터뷰에서 이와 같은 코드를 작성했다면 이는 심각한 타격입니다. (부작용이있는 조건부 일뿐 아니라 명확성을 희생하면서 영리합니다.)

사실, 나는 부작용이있는 조건을 본 적이 없으며, 인터넷 검색도 많이 나타나지 않습니다. 다른 학생도 수업 후에 물었다. 그래서 나는 이것이 이상하다고 생각한 유일한 사람이 아니다. 그러나 교수는 이것이 허용 가능한 코드였으며 직장에서 이와 비슷한 것을 쓸 것이라고 단호했습니다. (그의 FT 직무는 모두 들어 본 회사의 교장 SWE입니다.)

이 코드 줄이 바람직 할뿐만 아니라 수용 될 수있는 세상을 상상할 수는 없습니다. 내가 잘못? 이거 괜찮아? 부작용이있는 조건부보다 일반적인 경우는 어떻습니까? 괜찮아?

내가 생각할 수있는 반 조건부 부작용 이 하나 있습니다.while(iter.MoveNext())

그게 내가이 대부분이 '에 빠져 있다고 생각했다 결코 카테고리 정말 큰 한정자입니다 ". 나는 그것이 허용되는 것을 보았던 드문 경우를 생각할 수 있지만 일반적으로 이것은 사악하고 피해야합니다.

또한 특정 라인이 수용 가능한 시나리오는 생각할 수 없지만 해당 라인이 유용한 시나리오는 생각할 수 없으므로 컨텍스트가 어려울지는 상상하기 어렵습니다.

내 세계에서는 메모리에서 읽은 것이 부작용으로 간주 될 수 있습니다 (예 : 메모리 매핑 된 IO).

이제 다음을 고려하십시오.

    while( ( *memory_mapped_device_status_register & READY_FLAG) == 0) {
       // Wait
    }

그리고 다음과 비교하십시오 :

    status = *memory_mapped_device_status_register;
    while( ( status & READY_FLAG) == 0) {
        // Wait
        status = *memory_mapped_device_status_register;
    }

가독성에 도움이되는 상태에서 부작용 (판독)을 피했습니까? 아니면 코드를 복제하고 혼란을 추가 했습니까?

조건에 부작용이있는 것은 좋지 않으며 (코드가 읽기 어려운 경우), 조건에 부작용이있는 것도 괜찮습니다 (코드를 더 읽기 쉬운 경우). 핵심 요소는 "가독성"입니다. 그 밖의 모든 것은 가독성을 향상시키기 위해 잘못된 시도로 바보에 의해 만들어진 규칙입니다 (반대의 효과는 있음).

그런 질문들과 마찬가지로, 이것은 정도의 문제입니다. 있다는 명백한 증거가 있다면 어떤 내에서 부작용 if발현이 항상 나쁜 코드에 LED가, 다음은 그 표현을 만들 불법 일 것입니다. 언어 디자이너, 오류에 빠지기 쉬운 인간 ideosyncratic 수 있지만, 그들은하지 않은 것을 바보.

즉, if? 내의 정당한 부작용의 예는 무엇 입니까? 예를 들어, 감사 목적으로 P법인 자산 에 대한 모든 액세스 권한을 법적으로 기록해야한다고 가정 E합니다. (우라늄 농축 공장에서 일하고 있고 코드에서 허용되는 작업과 수행 방식에 대해 매우 엄격한 법적 통제가 있다고 상상해보십시오.) 그런 다음 if해당 속성을 확인하면 해당 속성의 부작용이 발생할 수 있습니다. 감사 로그가 확장되고 있습니다.

즉, 프로그램의 상태에 대한 당신의 이유를 (매우)에 영향을주지 않습니다, 당신은 완전히 보이지 않는하고있는 라인을 검토 할 때 비를 산만하다고 그래서 그것을 구현할 수있는, 꽤 명확한 교차 절단 우려의 if(숨겨진를 접근 자에서 멀리 떨어져 있거나 AOP를 통해 더 좋습니다. 나는 그것이 부작용이 아닌 분명한 부작용이라고 말합니다. 프로파일 링 등을 위해 분기 실행을 계산하려는 경우에도 비슷한 상황이 발생할 수 있습니다.

이러한 완화 환경이 사라질수록 구조물이 낯선 사람이 될 것입니다. 특정 루프 유형 (예 : if((c = getc()) == 'x') { quit(); }언어 커뮤니티에서 잘 알려져 있고 받아 들여 진다면 자발적으로 발명 할 때보 다 문제가 훨씬 적습니다) 내가 입력하지 않을 끔찍한 것들은 너무 끔찍합니다.

실제로 냄새 나는 코드이지만 동등한 것보다 더 간단하고 (최적의 최적화 컴파일러가 없으면 더 빠를 수도 있음) 이점이 있습니다 if (a > 33 | b < 54) {b++; ...} else b++;

물론 물론 다음과 같이 최적화 할 수 있습니다 (그러나 오버플로의 경우이 동작이 다릅니다!) : b++; if (a > 33 | b < 53) {...}