Hacker News 의견

• 원문을 읽어보면 각 항목의 목적을 설명하고 있음
• 원문은 주로 C 언어를 대상으로 하며, C로 작성된 중요한 응용 프로그램의 신뢰성을 더 철저히 검사할 수 있도록 최적화하려고 함
• 원저자는 자신이 무엇을 하는지 명확히 이해하고 있으며, C 코드를 검증하는 여러 방법을 설명함
• 원문에 있는 논리는 모두 완벽하게 이해됨
  • 아마도 작은 시스템에서 C를 배웠기 때문일 것임
  • 임플란트 의료 기기를 위한 하드웨어용 C를 배웠으며, 실험실에서도 유사한 지침을 따랐음
• 마지막 단락은 훌륭함
  • 규칙이 처음에는 엄격하게 느껴질 수 있지만, 코드의 정확성에 생명이 달려 있을 수 있는 경우를 고려해야 함
  • 자동차의 안전벨트처럼 처음에는 불편할 수 있지만, 시간이 지나면 자연스럽게 사용하게 됨
• 이 규칙에 대한 나의 비판은 OP와는 매우 다를 것임
  • setjmp/longjmp를 옹호하는 글을 처음부터 진지하게 받아들이기 어려웠음
  • 이 패턴은 접근해본 사람이라면 누구나 명백히 문제가 있음
  • 글은 setjmp/longjmp가 예외 처리라고 주장함
  • 예외 처리는 좋다고 주장함
  • 두 번째 전제에 심각한 문제가 있음
• 루프에 대해 최대 반복 횟수를 설정하라는 의미임
  • 10^90은 어리석고 관련이 없음
  • 이 지점 이후로 글을 읽지 않았음
• 규칙을 비판한다면 다음과 같은 점에 초점을 맞출 것임
  • 함수 본문의 길이는 이해의 단순성과 상관관계가 없으며, 오히려 규칙이 암시하는 것과 반대일 수 있음
  • 2개의 단언은 완전히 임의적이며, 단언할 수 있는 모든 것을 단언해야 함
  • Ada, Pascal (Delphi), JavaScript, 또는 함수형 언어를 사용하는 사람들은 가능한 한 지역적으로 타입과 함수를 선언해야 함
• JavaScript에서의 개인적인 접근 방식은 명시적으로 값을 캡처하려는 경우를 제외하고 중첩된 방식으로 함수를 정의하지 않는 것임
  • 오래된 정신 모델 때문일 수 있음
  • 성능 프로파일링에서 함수가 호출될 때마다 재정의된다고 보여졌음
  • 현대 JavaScript 인터프리터가 이렇게 작동한다고는 생각하지 않음
  • 화살표 함수 도입 이후로 깊은 최적화가 이루어졌을 것임
  • 오래된 습관은 쉽게 사라지지 않음
  • 지역 변수를 캡처하지 않는 명명된 함수는 파일/모듈 범위에 유지함
• 다른 많은 노트는 흥미롭고 매우 세세한 부분임
  • "기술적으로 정확한 것이 가장 좋은 정확성"이라는 방식으로 오래된 엔지니어들이 좋아함
  • NASA 규칙이 전달하려는 신중함의 일반적인 톤이 매우 좋다고 생각하며 대부분을 지지함
• 문맥상, 이것들은 "규칙"이라기보다는 제안된 관행임
  • 공식적인 "규칙"은 "NPR" 같은 이름의 문서에 있음
  • 개발자는 이 "규칙"을 준수하거나 무시할 의무가 없음
• GCC는 컴파일 후 스택 사용량과 호출자-피호출자 관계를 얻을 수 있음
  • setjmp()와 longjmp()는 예외를 처리하는 나쁜 방법임
  • 청소 코드가 실행되지 않음
  • 규칙의 정신을 따르면 청소가 필요한 자원이 없어야 함
• 주요 문제는 각 응용 프로그램에서 다르게 나타남
  • 반복 제한이 초과되거나 시작 시 할당된 고정 자원이 충분하지 않을 때 어떻게 할 것인가
• 요즘 프로그래머들은 코드를 화면에서 읽기 때문에 종이 크기가 더 이상 관련이 없는 이유가 명확하지 않음
  • 표준 페이지와 문자 크기에 대한 반복이 있었음
  • 종이의 한계뿐만 아니라 인간의 한계 때문임
• 재귀에 대한 규칙은 필요한 스택 공간의 정적으로 알려진 경계를 보장하기 위한 것임
  • 컴파일러에 의존한다는 비판은 맞지만, 런타임의 상한을 도출하기 위한 전제 조건임
  • 안전이 중요한 시스템에서는 보장된 응답 시간이 필요함
• 제목은 규칙에 대한 _비판_임을 나타내야 함
• 엄격한 타입 사용을 권장함
  • 모든 스칼라 타입에 대해 엄격한 타입 사용
  • 제국 단위와 미터법 단위를 혼합하지 않음