프로그래밍에 대해 가장 좋아하는 인용문은 무엇입니까? [닫은]

110

프로그래밍에 대해 가장 좋아하는 인용문은 무엇입니까?

하나의 대답은 당 인용 하고, 제발 중복 체크 게시하기 전에!

quotations 
— 젤라틴
소스

답변:

231

디버깅은 처음에 코드를 작성하는 것보다 두 배나 어렵습니다. 따라서 코드를 최대한 영리하게 작성하면 정의에 따라 코드를 디버깅하기에 충분히 똑똑하지 않습니다.

— 브라이언 W. 커니 건

— Fishtoaster
소스
영리한 코드를 작성할 때마다이 규칙을 생각 나게하여 나중에 유지하기가 더 쉬운 간단한 방법으로 작업을 수행 할 수 없는지 또는 최소한 더 많은 주석을 추가 할 수 있는지 살펴 봅니다. .
— CodexArcanum
6
그 밖의 진정한 격언의 추론 : 도표가 뇌의 힘을 증가시킬 수 있다는 것을 잊지 마십시오. 「큰 것의 구조를 기억한다」를 비 휘발성 용지로 교환 할 수 있습니다.
— Tim Williscroft
1
나는 인용문을 좋아하지만 그 의미는 우리가 노력의 50 %를 처음에 코딩해야한다는 것입니다.
— 존 홉킨스
4
그 의미는 약간 더 길고 분명한 방법으로 무언가를 할 때 프로그래머가 '영리한'방법으로 무언가를 수행하려는 충동을 피해야한다는 것입니다.
— Fishtoaster
2
그러나 그것이 "완벽한"코드라면? 그것을 "디버깅"할 방법이 없습니다.
— Mateen Ulhaq
183

둘 다 얼어 붙으면 물 위를 걷고 사양에서 소프트웨어를 개발하는 것이 쉽습니다.

— 에드워드 V 베라 드

— Tobiasopdenbrouw
소스
올해의 인용문, 나는 이것을 사용할 것입니다
— Gortron
나는 이것을 싫어한다. 결코 그런 경우가 아니므로 누가 신경 쓰겠습니까?
— JP Alioto
138

Hofstadter의 법칙을 고려하더라도 항상 예상보다 오래 걸립니다.
  — 호프 스타터의 법칙

— 니블 람
소스
72
뇌 스택 오버플로.
— Nathan Taylor
3
@Joe D : 재귀 영어 문장을 하나의 비 재귀 문장으로 다시 작성하는 방법이 궁금합니다 .
— Jon Purdy
4
"더 긴"의 충분한 작은 값들에 대해 수렴 될 수 있습니다
— mouviciel
3
+1-Douglas Hofstadter와 함께 10 억 명의 프로그래머 중 한 명입니다.
— 피터 터너
@gf : 나중에 소스를 정의로 변환 할 때 (대시로), 주요 소개는 보증되지 않습니다 ( "A : Blah."-> "Blah.-A"). 이것은 인용의 일부를 제거하지 않습니다.
126

항상 코드를 유지 관리하는 사람이 당신이 사는 곳을 아는 폭력적인 정신병자처럼 항상 코딩하십시오.

— 릭 오스본

— Wil
소스
12
생성자가 어디에서 살았는지 알고 싶은 코드를 계속 유지하는 것처럼 보이지만 아마 그렇지 않은 것이 좋습니다.
— WalterJ89
"킬러 앱"이라는 용어에 새로운 의미를 부여합니다. 나는 정신병자의 코드가 수감 된 후에 항상 유지되는 것처럼 보인다.
— webbiedave
8
@webbiedave ReiserFS에서 일하십니까? :)
— Neil Aitken
살인자가 당신의 직업을 얻었다면 회사는 정말 당신을 미워해야합니다
— Mateen Ulhaq
118

당신은 프로젝트를 가질 수 있습니다 :

  • 정시에 완료
  • 예산에 완료
  • 제대로 완료

두 개를 선택하십시오.

— 알 수 없음

— 바비
소스
22
— rwong
5
나에게도 비슷한 삼각형을 생각 나게하지만 여자들도있다. "당신은 여자 친구를 가질 수 있습니다 : 똑똑하고 매력적이며 좋은 성격을 가지고 있습니다."
— Maxpm
예외는 있지만 드물지는 않지만 잊지 마십시오.
— Mircea Chirea
5
@Maxpm : 제가 들었던 버전은 "The 4 S : Smart, Sexy, Sane, Single. Pick 3"입니다.
— 메이슨 휠러
1
따라서 시간과 예산에 제약이 없으면 제대로 수행 할 수 없습니다. 알아 둘만 한.
— Antsan
111

어떤 사람들은 문제에 직면했을 때 "정규 표현을 사용할 것입니다."라고 생각합니다.
이제 두 가지 문제가 있습니다.

— 제이미 자윈 스키

— Noah Goodrich
소스
5
시대를 초월한 고전
— 팩터 미스틱
5
어떤 사람들은 문제에 직면했을 때 "저는 <일부 문제 해결 구현>을 사용할 것입니다"라고 생각합니다. 이제 두 가지 문제가 있습니다.
— Callum Rogers
40
어떤 사람들은 문제에 직면했을 때 그냥 생각하지 않습니다. 그들은 단지 StackOverflow에 게시합니다
— Matt Ellen
5
어떤 사람들은 정규 표현식을 이해하지 못하고 다른 사람들이 있기 때문에 미워합니다.
— Orbling
3
@Yar-개인적으로 구문을 방해하는 구문을 찾지 못했습니다. 밀도는 좋은 것입니다. 더 자세한 형식으로 패턴 일치와 같은 것을 표현하는 이유는 무엇입니까? 복잡한 것을 명확하게해야하는 경우 확장 모드를 주석과 함께 사용할 수 있습니다.
— Orble
110

이론적으로는 이론과 실제에 차이가 없습니다. 그러나 실제로는 있습니다.

— Jan LA van de Snepscheut

— Walter
소스
27
또한 "이론과 실제의 차이는 실제보다 이론에서 더 작습니다"라고 들었습니다.
1
Roger Pate의 공식은 Olin Shivers가 "History of T"에 쓴 글입니다. Paul Graham이 여기에 대해 이야기합니다 : paulgraham.com/thist.html
— Michael H.
2
이론이 실천으로 해석되지 않는다면 이론은 불완전하다는 것입니다.
— Rei Miyasaka
105

제도 테이블에서 지우개를 사용하거나 건설 현장에서 망치를 사용할 수 있습니다-Frank Lloyd Wright

정확하게 프로그래밍 인용은 아니지만 가장 확실하게 적용됩니다.

— Tom Wijsman
소스
14
매우 적용 가능한 IMO
— John MacIntyre
3
운 좋게도 대부분의 소프트웨어가 잘못되었을 때 사람들을 무너 뜨리거나 죽이지 않습니다.
— Neil Aitken
8
그것이 Ariane 5를 날려 버릴 때를 제외하고 (Flight 501), 치명적으로 높은 수준의 방사선으로 사람들을 투약 할 때 ...
— Frank Shearar
2
아이러니하게도, 나는 Frank Lloyd Wright의 더 복잡한 건물이 무너 졌다고 생각합니다.
— Maxpm
1
@TomWij, @Walter, @Roger : 메타 토크로이 사이트를 더럽 히지 마십시오. 울리는 소리를 듣고 싶다면 meta.stackoverflow.com을 방문하십시오. 이곳에서 당신은이 매혹적이고 영원한 대화를해야합니다.
— Dan Rosenstark
103

오늘날의 프로그래밍은 더 크고 더 좋은 바보 방지 프로그램을 구축하기 위해 노력하는 소프트웨어 엔지니어와 더 크고 더 좋은 바보를 만들기 위해 노력하는 소프트웨어 간의 경쟁입니다. 지금까지 우주가 승리하고 있습니다.

— 릭 쿡

— Jonas
소스
98

코드 라인별로 프로그래밍 진행률을 측정하는 것은 무게로 항공기 건물 진행률을 측정하는 것과 같습니다.
  - 빌 게이츠

— ahsteele
소스
2
— Bill Karwin
3
이것은 여러 수준에 해당됩니다. 보석.
3
물론 주요 차이점은 항공기의 최종 무게는 알고 있고 소프트웨어의 최종 LOC 수는 알려져 있지 않다는 것입니다.
— mmyers
5
그렇다면 왜 대부분의 Microsoft 제품이 활주로에서 내리는 데 어려움을 겪고있는 비행기에 발을 묶고 있다는 느낌을 갖게됩니까?
— Sharpie
86

컴퓨터 과학에는 다음과 같은 두 가지 어려운 문제가 있습니다. 캐시 무효화, 명명 및 사물 별 오류.

    — Leon Bambrick (@ secretGeek )

(실제로 목록을 큐레이터로 볼 때 http://q4td.blogspot.com/search/label/programming의 모든 내용 이 표시됩니다.)

— 에반
소스
이름을 지정하는 것이 얼마나 어려운지 인용 한 적이 없습니다. 나는 갑자기 연대를 느낀다.
— CodexArcanum
3 가지입니다. 처음 두 개는 Phil Karlton의 원래 인용문입니다. @CodexArcanum. 이름을 잘 지정하는 것이 요령입니다.
— StuperUser
@StuperUser whooosh! 농담을 놓쳤다!
— Agos
당신이 지적한 후에 그것을 얻기 위해 2 초를 걸렸습니다. 헤르 프
— StuperUser
85

한 달에 아홉 명이 아기를 만들 수 없습니다.
  — 프레드 브룩스, 신화적인 남자-월

— 큰 소유자
소스
14
기술적으로 : 한 달에 18 명이 아기를 낳을 수 없습니다
— 늑대가 되십시오
13
@HereBeWolves 또는 10
— WalterJ89
14
1 명의 남자와 8 명의 숙녀에 무엇이 문제입니까? 나에게 딱 들리는 소리.
4
우리가 쌍둥이 나 세 쌍둥이를 간다면 우리는 더 적은 숙녀가 필요합니다.
12
첫 번째 아기가 9 개월 지연을 겪게됩니다 있지만, 적절한 파이프 라인은 ... 한달에 1을 지속적으로 제공 할 것
— 브라이언 Knoblauch
82

우리 는 시간의 97 % 정도라는 작은 효율성을 잊어야합니다. 조기 최적화는 모든 악의 근원입니다. 그러나 우리는이 중요한 3 %의 기회를 포기해서는 안됩니다.
  — Donald Knuth, 명령문을 사용한 구조화 된 프로그래밍 , JACM 컴퓨팅 설문 조사, Vol 6, No. 4, 1974 년 12 월, p.268

이것은 아래 두 단락에서 발췌 하여 위의 결론에 도달 한 이유 뿐만 아니라이 실수를 피하는 방법 에 대한 정보를 제공합니다 .

효율성의 성패가 학대를 초래한다는 것은 의심의 여지가 없습니다. 프로그래머는 프로그램의 중요하지 않은 부분의 속도에 대해 생각하거나 걱정하는 데 많은 시간을 낭비하며, 이러한 효율성 시도는 실제로 디버깅 및 유지 관리를 고려할 때 큰 부정적인 영향을 미칩니다. 우리 는 시간의 97 % 정도라는 작은 효율성을 잊어야합니다. 조기 최적화는 모든 악의 근원입니다.

그러나 우리는이 중요한 3 %의 기회를 포기해서는 안됩니다. 훌륭한 프로그래머는 그러한 추론을 통해 만족에 빠지지 않을 것입니다. 코드가 확인 된 후에 만 가능 합니다. 측정 도구를 사용한 프로그래머의 보편적 경험은 직관적 인 추측이 실패하기 때문에 프로그램의 어떤 부분이 실제로 중요한지를 미리 판단하는 것은 종종 실수입니다. (…)

— Scott Dorman
소스
2
@Roger Pate : 당신이 옳다고 생각합니다.
— Scott Dorman
5
내가 조금 더 포함했다는 것을 신경 쓰지 않기를 바랍니다. 나는 그것이 정말로 중요하다고 생각하며 아마도 이것이 전체 논문을 읽는 것이 더 도움이 될 것입니다. :)
@Roger Pate : 아직 아닙니다!
— Scott Dorman
5
+1 전체 견적에 감사드립니다. 나는 그것에 더 많은 것이 있다는 것을 결코 알지 못했습니다.
— Evan Plaice
2
전체 견적을 게시 한 것이 좋습니다. 많은 사람들이 정렬 버전을 알고 있으며 Knuth가 실제로 무엇을 의미하는지 전혀 모릅니다.
— DasIch
80

디버거는 버그를 제거하지 않습니다. 그들은 단지 슬로우 모션으로 보여줍니다.

— 알 수 없음

— pramodc84
소스
35
또는 많은 경우에 완전히 나타나지 않도록하십시오.
— Graeme Perrow
12
@Graeme 이러한 경우는 :) Heisenbugs (불확정성 버그)이라고합니다
— 여기에 늑대 수
76

코드의 첫 90 %는 개발 시간의 첫 90 %를 차지합니다. 코드의 나머지 10 %는 개발 시간의 다른 90 %를 차지합니다.

— 톰 카길

— Roger Pate
소스
누가 원래 말했습니까?
— Paddyslacker
10
코드의 90 %가 시간의 90 %를 차지하고 코드의 마지막 10 %가 다른 90 %를 차지한다는 것을 알게 될 것입니다.
— FacticiusVir
2
벨 연구소의 톰 카길 : en.wikipedia.org/wiki/Ninety-ninety_rule
— Bill Karwin
1
나는 이것을 알고있다 : 20 %의 동료는 80 %의 맥주를 마신다.
— Zzz
1
개인적으로, 코드의 첫 90 %가 개발 시간의 첫 90 %를 차지한다고 말하고 싶습니다. 그러면 코드의 나머지 90 %가 개발 시간의 다른 90 %를 차지합니다.
— Kaz Dragon
70

Java에 실제 가비지 콜렉션이있는 경우 대부분의 프로그램은 실행시 스스로 삭제합니다.
  — 로버트 세웰

— bigown
소스
22
웃긴, 방금 PHP를 생각하게 만들었습니다.
— WalterJ89
2
@ WalterJ89 : 걱정하지 마세요! PHP 5.3까지 PHP는 다시 계산됩니다.
— zneak
난이게 좋아!
— MDV2000
@ WalterJ89 글쎄, COBOL, C ++, VB 또는 기타와 달리 Java를 단일화 할 이유가 없다.
— Mark C
69

컴퓨터 과학은 천문학보다 망원경에 관한 것이 아닙니다.

— Edsger Dijkstra

— 큰 소유자
소스
4
예, 그러나 이것은 컴퓨터 과학이 아니라 프로그래밍 에 관한 것 입니다. [sly grin]
— Mark C
프로그래밍은 컴퓨터 과학으로 수집 된 지식을 적용하는 것입니다. 프로그래밍을 위해 컴퓨터가 필요하지 않습니다. 최소한 친숙하지 않은 사람도 있습니다.
— DasIch
저는 항상 프로그래밍에서 가장 성가신 것은 컴퓨터와 분리 할 수 ​​없다는 것입니다.
— LoveMeSomeCode
57

디버깅이 소프트웨어 버그를 제거하는 프로세스 인 경우 프로그래밍은 버그를 처리하는 프로세스 여야합니다.
  — Edsger Dijkstra

— pramodc84
소스
24
그렇기 때문에 제 업무를 enbugging이라고 합니다.
— deceze sep
9
리버 깅으로 유지 보수 ?
— Joe D
1
@JoeD 아니오, "버그 감시".
— Mark C
56

사람들이 불평하는 언어와 아무도 사용하지 않는 언어에는 두 가지 언어 만 있습니다.

— 비얀 스트로 t

— 큰 소유자
소스
15
C ++ suckage 나쁜 변명
— 하센
3
C #은 명백한 반례입니다.
— Timwi
7
그리고 VB는 두 가지 범주로 나뉩니다.
— 빠른 조 스미스
48

부울의 가장 좋은 점은 당신이 잘못하더라도 조금만 벗어난 것입니다. -(익명)

— pramodc84
소스
최악의 상황은 더 잘못 될 수 없다는 것입니다.
— POSIX_ME_HARDER
46

나는 두 번이나 물었다. "기도하십시오. Babbage 씨, 기계에 잘못된 수치를 넣으면 정답이 나옵니까?" 어떤 경우에는 Upper의 일원과 다른 경우에는 Lower House의 일원이이 질문을합니다. 그런 질문을 불러 일으킬 수있는 아이디어의 혼란을 제대로 이해하지 못했습니다.
  — 찰스 배비지

어리석게도 사용자가 어리석은 사용자 질문에 직면 한 최초의 문서화 된 사례입니다.

— Jay
소스
5
티셔츠 아이디어처럼 들린다! "사용자 오류 : 1832 년 이후로 파울 링" (Date?)
— Mark C
42

나는 항상 내 컴퓨터가 내 전화만큼 사용하기 쉽기를 바랐다. 전화 사용 방법을 더 이상 알 수 없기 때문에 소원이 이루어졌습니다

-Bjarne Stroustrup

— bigown
소스
42

코드가 실행될 때까지 모두 대화합니다.
  — 워드 커닝햄

— Walter
소스
39

유니 코드 지원은 "기능"이 아닙니다. 예상되는 동작입니다.

물론, 그것은 매우 구체적이지만, 쓸모없는 문자 세트가 여전히 너무 널리 사용되기 때문에 내가 가장 좋아하는 것입니다 ...

— 팀위
소스
3
이제 어떤 유니 코드에 대해 논쟁해야합니다
— Martin Beckett
@ 마틴 : 실제로는 아닙니다. 다양한 종류의 변환이 무손실이기 때문입니다.
— Billy ONeal
아프다! 왜 고객과 무한히 더 편리하게하기 위해 전체 인프라를 "라틴 -1"로 전환 할 수 없다고 주장해야합니까? "결국, 주위에 아무도 여기가 그 이상한 특수 문자를 사용하지 않고, 열심히 할 수 없다, 그렇지?"
— Piskvor
39

코드를 주석 처리하는 것은 화장실 청소와 같습니다. 절대로하고 싶지는 않지만 실제로는 귀하와 손님에게 더 즐거운 경험을 제공합니다.

— 라이언 캠벨

— 코더 호크
소스
1
Meh ... 내 인생에서 마주 친 대부분의 의견은 주석이 잘못 작성된 코드를 구성 할 수 있다는 가정하에 작성되었습니다.
— riwalk
욕실을 청소할 수 있지만 샤워에 찬물 만 있고 싱크대에 비누가 없으면 불쾌한 경험이 될 것입니다. 설명을하기 위해 큰 주석을 작성하지 않고 쉽게 읽을 수있는 코드를 작성하십시오.
— Keyo
나는 실제로 매우 즐거운 의견을 찾는다. 때로는 별표와 슬래시로 만든 작은 상자에 중요한 주석을 달았습니다. 그리고 다시, 나는 괴물이다.
— Maxpm
2
나도 의견 쓰기를 좋아하지만 내 화장실을보고 싶지 않을 것입니다.
— Timwi
나는 화장실에 있었는데, 왜 당신이 화장실을 깨끗하게 유지해야하는 방법과 이유에 대해 정말 긴 의견이있었습니다. 깨끗하지 않았다.
— Rei Miyasaka
35

프로그래밍은 섹스와 같습니다. 한 번의 실수로 평생 동안 지원해야합니다.
  — 마이클 신즈

— 큰 소유자
소스
34

그림은 완벽하고 완벽한 방법으로 비 퀀 타이어를 더한 rien a ajouter, mais quand il n'y a plus rien à retrancher입니다.
  — 앙투안 드 생 텍쥐페리, 프랑스 작가 (1900-1944), 테레 데 옴므 (1939)

(추가 할 항목이 없을 때가 아니라 제거 할 항목이 없을 때 완벽 함을 얻는 것처럼 보입니다.)

— Bill Karwin
소스
그리고 그것은 음악에도 유효합니다
— Heinz Z.
2
— 데이비드 켄달
2
@David Kendal : 니스! 마찬가지로 Henry David Thoreau는 "간체, 단순화"라고 말했습니다. 항상 "간단히"생각합니다.
— Bill Karwin
33

자동차는 카펫과 마찬가지로 자바도 자바 스크립트입니다.
  — 크리스 헤일 만

— Bill Karwin
소스
내 차에 카펫이 있는데 Java에 Javascript가 있습니까?
— Keyo
1
@Keyo : 그래, 나는 그것을 생각했다. 나는 여전히 인용문이 정말 영리하다고 생각합니다.
— Bill Karwin
31

Eric S. Raymond가 공식화 한대로 :

리누스의 법칙

충분히 큰 베타 테스터 및 공동 개발자 기반을 고려할 때 거의 모든 문제가 신속하게 특성화되고 누군가에게 분명하게 해결됩니다.

아니면 덜 공식적으로

충분한 안구가 주어지면 모든 버그가 얕습니다.

— 8
소스
나에게 원숭이 / 타자기 규칙처럼 들리는 ...
— Sean Patrick Floyd
Linux 애호가가 버그를 수정하는 것보다이 인용문을 반복하는 데 더 많은 시간을 소비하는 이유는 무엇입니까?
— Timwi
또는 AtOver의 StackOverflow에 대한 슬로건은 "우리 중 누구도 우리만큼 바보가 아닙니다". 참조 codinghorror.com/blog/2008/09/...
— 에반 가자미에게
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.