거짓말하는 코드를 찾아야합니까?


9

이것은 답변에 대한 토론 과이 질문에 대한 의견을 말하고 있습니다 : 업계의 문서화를 혐오하는 것은 무엇입니까? . 그 대답은 "코드는 거짓말을 할 수 없다"고 주장했기 때문에 문서 대신 이동해야 할 위치에 있어야합니다. 몇몇 의견은 "코드가 거짓말을 할 수있다"고 지적했다. 문서화가 부적절하고 부적절하게 처리되기 때문에 양쪽에 진실이 있습니다.

거짓말하는 코드를 찾아 기존 문서와 비교해야합니까? 아니면 일반적으로 수행해야 할 작업에 가장 적합한 소스입니까? 그것이 민첩한 코드라면 거짓말 가능성이 적습니까, 아니면 그 코드가 전혀 거짓말을 할 수 없습니까?


1
"거짓말"의 의미를 명확하게 설명해 주시겠습니까? 상황을 파악하기 위해 다른 질문에 의견을 언급 할 필요는 없습니다.
— user16764

@ user16764 다른 스레드를 보지 않고 가장 먼저 떠오르는 것은
— Underhanded

문서에서 코드가 foo를 수행해야하고 코드가 bar를 수행한다고 표시하면 bar가 코드가 수행 해야하는 작업임을 의미합니까? 아니면 코드가 항상 정확하기 때문에 문서를 읽지 않기 때문에 bar가 올바른 조치라고 가정합니까?
— thursdaysgeek

코드가 막대로 승인 된 경우 문서가 잘못되고 구식입니다. 그러나 foo와 bar가 밀접하게 관련되어 있고 사용자가 예상대로 문제를 해결하지 못한다는 것을 알지 못하면 foo에 대한 문서가 잘못되지 않았습니까? 다시 말해, 코드는 실제로 코드가 수행해야 할 작업의 전부와 끝입니까?
— thursdaysgeek

답변:


9

평신도의 말로 :

그렇습니다 . 거짓말하는 코드를 찾아서 진실을 말해야합니다. 그러나 그것을 문서와 비교하는 것이 아닙니다. 그것은 거짓말하는 문서를 탐지하는 방법입니다.

코드가 놓일 수있는 몇 가지 방법이 있는데, 그중 몇 가지만 언급하겠습니다.

  • 조건이 충족되지 않아 실행되지 않는 코드 블록. 코드는 그것이 얼마나 많은지에 대해 거짓말하고 있습니다.
  • 불필요한 복잡성을 더하는 코드는 문제가 얼마나 복잡한 지에 달려 있습니다.
  • 명명 규칙이없는 코드는 실제로 수행하는 작업과 다른 것을 수행하도록 오도하기 때문에 거짓말을합니다.

짧을수록 거짓말이 적습니다. 그것은 자명하다.

코드가 덜 복잡할수록 더 투명 해집니다. 따라서 거짓말이 적습니다.

신비한 구문 트릭이 많이 있습니다. 명확한 단계별 알고리즘을 선호하십시오. 그들은 덜 거짓말.

좋은 정적 코드 분석 도구는 거짓말을하는 코드를 찾는 데 도움이 될 수 있습니다.

또한 우수한 자동 테스트 배터리는 코드가 진실을 말하도록 강요합니다.


4
The shorter and terser the code is, the less it lies. It's self evident. 나는 거의 말하지 않을 것입니다. 내 경험에 따르면 코드가 짧고 간결할수록 일반적으로기만 함수 호출에 코드를 숨겨서 깔개 아래에 더 많은 기회가 있습니다.
— 메이슨 휠러

@MasonWheeler 당신이 맞아요. "terse"부분을 편집했습니다.
— Tulains Córdova 2016

나는 "네이밍 규칙이없는 코드"에 확신이 없다. 확실히 나쁘지만 아무 것도 말하지 않으면 어떻게 거짓말을 할 수 있습니까? "나는 당신에게 말하고 있지 않습니다!" 완고하게 폐쇄적이고 정보가 없지만 기만적이지 않습니다. 분명히 "거짓말"은 이름 지정 규칙이 존재하지만 코드가 실제로하는 것과 일치하지 않는 방식으로 사용됩니다 (예 : 헝가리어 (yuck!)를 사용하지만 때로는 p변수에 접두어가있는 경우) 포인터가 아닙니다.
— Steve314

2
실제로, 당신이 제안하는 것은 단순히 "거짓말"보다는 "정신"으로 더 잘 묘사 될 수 있습니다. Sophistry는 상세하고 복잡한 경향이있어 논리적 결함을보기가 어렵고, 겉보기에 영리하고 자신감이있어 사람들이 어리석게 보일 때 질문하기가 무섭습니다.
— Steve314

또 다른 예 : 기본 언어 또는 런타임 속성을 변경하는 코드 (예 : 기본 동작 재정의 또는 마스킹)
— JustinC

6

코드는 거짓말을 할 수 없습니다.

코드에 포함 된 것은 문서, QA 또는 고객의 말에 관계없이 프로그램에서 현재 수행중인 작업입니다. 특히 코드가 릴리스되어 잠시 동안 현장에 있었다면 예상되는 동작을 무시해서는 안됩니다.

코드는 확실히 될 수 있습니다 잘못된 . 이름이나 조직에있어 오해의 소지가있을 수 있습니다. 확실히 읽을 수 없습니다.

그러나 코드가 수행하는 작업 , 수행 해야 할 작업, 수행 된 작업이 아니라 수행 한 작업이 아니라 생각한 작업이 아니라 실제로 수행하는 작업을 알아야하는 경우 코드로 이동하십시오.


고의적으로 기만적이지만 현명하게 옳다면 거짓말을하지 않는다고 생각하는 학교가 있습니다. 생각의 유일한 학교는 아닙니다. 예를 들어, Aldert Vrij 의 Detecting Lies and Deceit의 구버전이 있습니다. 이것이 가장 먼저하는 것 중 하나는 거짓말과 속임수에 대한 다양한 정의를 고려하는 것이며, 어쨌든 일반적인 이해이기 때문에 부분적으로 정확하지만 신중하게 오해의 소지가있는 진술을 포함하도록 선택합니다.
— Steve314

미안하지만 "정말로 맞았다"고해서 거짓말 쟁이라고 불릴 수는 없습니다. 사람들이 말을 다시하지 않더라도 그들은 여전히 ​​그것을 알고 있습니다.
— Steve314

@ steve314-추신. 원래 질문은 의견에 관한 것이었다. 주석에 찬성하여 주장하기 위해 코드의 이름이 잘못 지정되는 희귀 한 시나리오를 위해 밀짚 꾼을 만드는 것은 터무니없는 일입니다.
— Telastyn

1
나는 그 점에 동의한다-나는 당신이 주장하는 것이 아니라 그것을하는 동안 사용하는 "거짓말"의 명백한 정의 만 주장하고있다. 코드 는 컴파일러가 아니라 인간 독자에게 거짓말을 할 수 있습니다. 어떤 경우에는 의도적 인 목표이기도합니다. 난독 화 된 C 콘테스트와 같은 것들이 비교적 양성적인 예입니다. 사용자 의견에 대한 의견에서 제안한 것처럼 Sophistry. 컴파일러가 거짓말을 통해 본다고해서 거짓말이 아님을 의미하지는 않습니다.
— Steve314

@Telastyn 필자는 필터가 리디렉션을 수행하여 실제로 공백에서 발생하는 리디렉션을 수행 한 다음 해당 메소드에서 호출되지 않은 코드로 이동하여 절대 반환하지 않는 것으로 추측합니다. 하나님! 나는 자바와 관련하여! @ # $ Java 개발자를 싫어합니다.
— Erik Reppen 2016 년

0

몇 가지 질문을합니다.

거짓말하는 코드를 찾아야합니까?

물론이야!

[code]를 기존 문서와 비교해야합니까?

다른 답변에서 언급했듯이 더 자주 아프지 않을 수도 있지만 코드가 아닌 문서 에서 문제를 찾을 수 있습니다 .

아니면 [코드]가 일반적으로해야 할 일에 가장 적합한 소스입니까?

그것은 항상 무엇을위한 최고의 소스 입니다 하고. 코드 가 수행 해야 할 가장 좋은 소스 는 다음과 같은 여러 가지 일이 될 수 있습니다.

  • 코드 자체;
  • 호출 코드;
  • 해당 코드의 주석;
  • 선적 서류 비치;
  • 단위 테스트;
  • 적분 및 회귀 테스트;
  • 프로그래머;
  • 최종 사용자;

"최상의"소스 (또는 이들의 조합)는 상황에 따라 다릅니다.

그것이 민첩한 코드라면 거짓말 가능성이 적습니까, 아니면 그 코드가 전혀 거짓말을 할 수 없습니까?

"민첩한 코드"가 무엇을 의미하는지 잘 모르겠습니다. AFAIK "민첩한"은 일반적으로 코딩 프로세스를 나타냅니다. "민첩한 프로그래밍 프로세스에서 생성 된 코드"를 의미한다고 가정하면 여전히 거짓말 을 할 수 있다고 말하는 것이 안전하다고 생각합니다 . 폭포 스타일 프로젝트에서 생성 된 코드와 비교하여 거짓말 가능성은 주관적인 문제입니다 (개인적으로는 큰 관련성이 없다고 생각합니다).


각주
위의 모든 코드 는 거짓말을 할 수 있다는 가정하에 있으며 이것은 기본적인 (비록 생각 된) 예제입니다.

public int DivideByTwo(int input) 
{
    return input / 3;
}

이것은 "코드 거짓말"이라고 말할 수있는 한 가지 예일뿐입니다. @ user61852는 접근 할 수없는 코드, 문제의 복잡성과 일치하지 않는 코드의 복잡성, 잘못된 이름 지정 등이 있습니다. 더 많은 것이 있다고 생각합니다. Wikipedia는 거짓말에 대한 다소 괜찮은 요약을 가지고 있으며 , 그중 많은 것들이 코드를 찾을 수 있습니다.

다른 사람 과 논쟁을 벌이는 경우, 상대방이 "코드가 거짓말을 할 수 없다"는 말이 "코드가하는 일"을 의미하지 않는지 확인하십시오 . 본질적으로 여기에있는 다른 사람은“거짓말을 할 수 없다”라는 진술을 공리 / 기본 진리로 선언 할 수있을 정도로 너무 좁은“거짓말”에 대한 정의를 사용하여 정의하고 있습니다. 이 경우, 아마도 그의 축삭에 동의하는 것이 가장 좋습니다.


0
if (x > 5) {
  doSomething();
} else {
  doADifferentThing();
}

"거짓말"이라는 단어가 기술적으로 적절한 지에 대해서는 논쟁 할 수 있지만이 코드는 x가 때때로 5보다 크거나 때로는 그렇지 않다는 것을 분명히 암시 합니다. 전체 프로그램을보고이 함수가 한 곳에서만 호출되고 x가 항상 상수 6으로 설정되어 있음을 발견하면 거짓말입니다.

또한 컴파일러는이를 알아 차리고이 코드 블록을 간단히

doSomething()

doADifferentThing이 프로그램의 다른 곳에서 호출되지 않으면 프로그램에서 완전히 제거 될 수 있습니다.

언어가 assert프로덕션 빌드에서 꺼져있는 일종의 언어를 지원하는 경우 각 assert진술은 잠재적으로 거짓말입니다. typecast는 거짓말 일 수있는 또 다른 주장입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.