Jaki jest twój ulubiony cytat na temat programowania? [Zamknięte]

Odpowiedzi:

231

Debugowanie jest dwa razy trudniejsze niż pisanie kodu. Dlatego, jeśli piszesz kod tak sprytnie, jak to możliwe, z definicji nie jesteś wystarczająco inteligentny, aby go debugować.

- Brian W. Kernighan

— Fishtoaster
źródło
Za każdym razem, gdy piszę jakiś sprytny fragment kodu, przypominam sobie tę zasadę i oglądam się za nią, aby zobaczyć, czy nie mogę zrobić rzeczy w prostszy sposób, który łatwiej będzie utrzymać później, lub przynajmniej dodać więcej komentarzy .
— CodexArcanum
6
Następstwem prawdziwej maksymy: nie zapominaj, że schemat może zwiększyć moc twojego mózgu. Możesz zamienić „pamiętaj strukturę wielkiej rzeczy” na nielotny papier.
— Tim Williscroft,
1
Podoba mi się ten cytat, ale implikacja jest taka, że ​​powinniśmy w pierwszej kolejności włożyć co najwyżej 50% naszego wysiłku w kodowanie.
— Jon Hopkins,
4
Myślę, że implikacja polega na tym, że powinieneś unikać chęci programisty, by użyć „sprytnego” sposobu zrobienia czegoś, gdy nieco dłuższy, bardziej oczywisty sposób zrobienia czegoś działa dobrze.
— Fishtoaster,
2
Ale co, jeśli to „idealny” kod? Nie ma możliwości „debugowania” tego.
— Mateen Ulhaq,
183

Chodzenie po wodzie i tworzenie oprogramowania ze specyfikacji jest łatwe, jeśli oba są zamrożone.

- Edward V Berard

— Tobiasopdenbrouw
źródło
Cytat roku,
— użyję
Nienawidzę tego. Nigdy tak nie jest, więc kogo to obchodzi?
— JP Alioto,
138

To zawsze trwa dłużej, niż się spodziewasz, nawet biorąc pod uwagę prawo Hofstadtera.
  - Prawo Hofstadtera

— nivlam
źródło
72
Przepełnienie stosu mózgu.
— Nathan Taylor,
3
@Joe D: Jestem ciekawy, jak przepisać rekurencyjne zdanie angielskie na pojedyncze zdanie nierekurencyjne.
— Jon Purdy,
4
Może zbiegać się dla wystarczających małych wartości „dłuższych”
— mouviciel
3
+1 - Z dumą zaliczam się do czołowego miliarda programistów wraz z Douglas Hofstadter.
— Peter Turner,
@gf: Po przekształceniu w późniejsze zdefiniowanie źródła (z myślnikiem), wiodące wprowadzenie nie jest uzasadnione („A: Blah.” -> „Blah. - A”). To nie usuwa części cytatu.
126

Zawsze koduj tak, jakby facet, który ostatecznie utrzyma twój kod, będzie brutalnym psychopatą, który wie, gdzie mieszkasz.

- Rick Osborne

— Wil
źródło
12
Wygląda na to, że w dalszym ciągu utrzymuję kod, który chciałbym wiedzieć, gdzie mieszka twórca, ale prawdopodobnie nie jest to dobra rzecz.
— WalterJ89,
Nadaje nowe znaczenie terminowi „zabójcza aplikacja”. Wydaje mi się, że zawsze kończę utrzymywanie kodu psychopaty po uwięzieniu.
— webbiedave
8
@webbiedave Pracujesz na ReiserFS? :)
— Neil Aitken,
Firma musi cię naprawdę nienawidzić, jeśli zabójca dostał twoją pracę.
— Mateen Ulhaq,
118

Możesz mieć projekt:

  • Gotowe na czas
  • Sporządzono w sprawie budżetu
  • Zrobione poprawnie

Wybierz dwa.

- Nieznany

— Bobby
źródło
22
— rwong
5
Przypomina mi podobny trójkąt, ale z kobietami. „Możesz mieć dziewczynę, która: jest mądra, atrakcyjna, ma dobrą osobowość”.
— Maks.
Nie zapominaj, że istnieją wyjątki, choć są rzadkie - nie licz na to.
— Mircea Chirea
5
@Maxpm: Słyszałem wersję „The 4 S's: Smart, Sexy, Sane, Single. Wybierz 3.”
— Mason Wheeler
1
Tak więc, gdy nie ma ograniczeń czasowych i budżetowych, nie można tego zrobić poprawnie. Dobrze wiedzieć.
— Antsan
111

Niektórzy ludzie, gdy napotykają problem, myślą: „Wiem, użyję wyrażeń regularnych”.
Teraz mają dwa problemy.

- Jamie Zawiński

— Noah Goodrich
źródło
5
Ponadczasowy klasyk
— Factor Mystic
5
Niektórzy ludzie, gdy mają do czynienia z problemem, myślą „Wiem, użyję <implementacja rozwiązywania problemów>”. Teraz mają dwa problemy.
— Callum Rogers,
40
Niektórzy ludzie, gdy napotykają problem, nie sądzą, po prostu publikują na StackOverflow
— Matt Ellen,
5
Niektórzy ludzie nie rozumieją wyrażeń regularnych i nienawidzą ich, ponieważ inni je rozumieją.
— Orbling
3
@Yar - nigdy nie znalazłem osobiście tępej składni, a gęstość jest dobra. Po co wyrażać coś w rodzaju dopasowania wzorca w bardziej pełnym formacie? Tam, gdzie w przypadku czegoś skomplikowanego wymagana jest przejrzystość, można stosować tryb rozszerzony z komentarzami.
— Orbling
110

Teoretycznie nie ma różnicy między teorią a praktyką. Ale w praktyce jest.

- Jan LA van de Snepscheut

— Walter
źródło
27
Słyszałem również: „Różnica między teorią a praktyką jest mniejsza w teorii niż w praktyce”.
1
Słyszałem sformułowanie Rogera Pate'a napisane przez Olin Shivers w „History of T”. Paul Graham mówi o tym tutaj: paulgraham.com/thist.html
— Michael H.
2
Powiedziałbym, że jeśli teoria nie przekłada się na praktykę, to jest ona po prostu niekompletna.
— Rei Miyasaka
105

Możesz użyć gumki na stole kreślarskim lub młota na placu budowy - Frank Lloyd Wright

Nie do końca cytat programowy, ale z pewnością ma zastosowanie.

— Tom Wijsman
źródło
14
Bardzo ważne IMO
— John MacIntyre,
3
Na szczęście dla nas, gdy większość oprogramowania nie działa, nie zawala się i nie zabija ludzi.
— Neil Aitken
8
Z wyjątkiem sytuacji, gdy wysadza Ariane 5 (lot 501) lub dozuje śmiertelnie wysoki poziom promieniowania ...
— Frank Shearar
2
Jak na ironię, wierzę, że wiele bardziej skomplikowanych budynków Franka Lloyda Wrighta popadło w ruinę.
— Maks.
1
@TomWij, @Walter, @Roger: Prosimy nie brudzić tej witryny za pomocą metatalk. Gdybym chciał usłyszeć kłótnie, odwiedziłbym meta.stackoverflow.com. To tutaj powinieneś odbyć tę fascynującą i ponadczasową rozmowę.
— Dan Rosenstark,
103

Dzisiejsze programowanie to wyścig między inżynierami oprogramowania dążącymi do budowania większych i lepszych programów odpornych na idioty, a Wszechświatem próbującym produkować coraz większych idiotów. Jak dotąd Wszechświat wygrywa.

- Rick Cook

— Jonas
źródło
98

Mierzenie postępu programowania liniami kodu jest jak mierzenie postępu budowy samolotu według masy.
  - Bill Gates

— ahsteele
źródło
2
— Bill Karwin
3
Dotyczy to wielu poziomów. Klejnot.
3
Kluczową różnicą jest oczywiście to, że ostateczna waga samolotu jest znana, podczas gdy ostateczna liczba LOC oprogramowania nie jest znana.
— mmyers
5
Dlaczego więc większość produktów Microsoft daje mi wrażenie, że jestem przykuty stopą do samolotu, który próbuje zejść z pasa startowego?
— Sharpie
86

Istnieją dwa trudne problemy w informatyce: unieważnienie pamięci podręcznej, nazywanie rzeczy i błędy off-by-1.

    - Leon Bambrick (@ secretGeek )

(Właściwie wszystko od http://q4td.blogspot.com/search/label/programming widząc, jak tworzę listę).

— Evan
źródło
Nigdy nie widziałem cytatu wskazującego, jak trudne może być nazywanie rzeczy. Nagle odczuwam solidarność.
— CodexArcanum
To 3 rzeczy. Pierwsze dwa to oryginalny cytat Phila Karltona. @CodexArcanum. Nazywanie rzeczy dobrze jest podstęp.
— StuperUser
@StuperUser whooosh! przegapiłeś żart!
— Agos,
Zajęło ci to dwie sekundy, gdy to zauważyłeś. Herp derp.
— StuperUser
85

Dziewięć osób nie może zrobić dziecka w ciągu miesiąca.
  - Fred Brooks, The Mythical Man-Month

— powiększenia
źródło
14
technicznie: 18 osób nie może zrobić dziecka w ciągu miesiąca
— Here Be Wolves
13
@HereBeWolves lub 10
— WalterJ89,
14
Co jest nie tak z 1 facetem i 8 kobietami? Brzmi dla mnie właściwie.
4
Jeśli wybieramy bliźniaki lub trojaczki, potrzebujemy mniej kobiet.
12
Podczas gdy pierwsze dziecko będzie cierpieć z powodu 9-miesięcznego opóźnienia, właściwy rurociąg będzie nadal dostarczał 1 miesięcznie ...
— Brian Knoblauch,
82

My powinniśmy zapomnieć o małych wydajności, powiedzmy około 97% czasu: przedwczesny optymalizacji jest korzeniem wszelkiego zła. Nie powinniśmy jednak tracić naszych szans w tak krytycznych 3%.
  - Donald Knuth, Programowanie strukturalne za pomocą go to Statement , JACM Computing Surveys, tom 6, nr 4, grudzień 1974, str. 268

Zostało to wyodrębnione z dwóch poniższych akapitów, które nie tylko mówią, dlaczego doszedł do powyższego wniosku, ale zawierają informacje, jak uniknąć tego błędu:

Nie ulega wątpliwości, że graal wydajności prowadzi do nadużyć. Programiści tracą ogromną ilość czasu na myślenie lub martwienie się o szybkość niekrytycznych części swoich programów, a te próby wydajności mają silny negatywny wpływ na debugowanie i konserwację. My powinniśmy zapomnieć o małych wydajności, powiedzmy około 97% czasu: przedwczesny optymalizacji jest korzeniem wszelkiego zła.

Nie powinniśmy jednak tracić naszych szans w tak krytycznych 3%. Dobry programista nie uśpi się na skutek takiego rozumowania, rozsądnie przyjrzy się krytycznemu kodowi; ale dopiero po zidentyfikowaniu tego kodu. Często błędem jest osądzanie z góry, które części programu są naprawdę krytyczne, ponieważ uniwersalne doświadczenie programistów używających narzędzi pomiarowych polegało na tym, że ich intuicyjne domysły zawodzą. (…)

— Scott Dorman
źródło
2
@Roger Pate: Podejrzewam, że masz rację, większość ludzi nie zdaje sobie sprawy, że w cytacie jest coś więcej.
— Scott Dorman,
5
Mam nadzieję, że nie masz nic przeciwko, że dodałem trochę więcej. Myślę, że to naprawdę ważne i może zachęci to więcej do przeczytania całego artykułu. :)
@Roger Pate: Wcale nie!
— Scott Dorman,
5
+1 Dzięki za pełną wycenę. Nigdy nie wiem, że było w tym coś więcej.
— Evan Plaice,
2
To wspaniale, że opublikowałeś całą ofertę. Wiele osób po prostu zna wersję i nie ma pojęcia, co tak naprawdę miał na myśli Knuth.
— Dasich
80

Debugery nie usuwają błędów. Pokazują je tylko w zwolnionym tempie.

- Nieznany

— pramodc84
źródło
35
Lub w wielu przypadkach spraw, aby przestały się całkowicie pojawiać.
— Graeme Perrow,
12
@Graeme te przypadki nazywa się Heisenbugs :)
— Here Be Wolves
76

Pierwsze 90% kodu stanowi pierwsze 90% czasu programowania. Pozostałe 10% kodu stanowi pozostałe 90% czasu programowania.

- Tom Cargill

— Roger Pate
źródło
Kto to powiedział pierwotnie?
— Paddyslacker
10
Myślę, że okaże się, że 90% kodu zajmuje 90% czasu, a ostatnie 10% kodu zajmuje pozostałe 90% czasu.
— FacticiusVir
2
Tom Cargill z Bell Labs: en.wikipedia.org/wiki/Ninety-ninety_rule
— Bill Karwin
1
Wiem to: 20% kumpli pije 80% piwa.
— Zzz
1
Osobiście powiedziałbym, że pierwsze 90% kodu stanowi pierwsze 90% czasu programowania. Następnie pozostałe 90% kodu stanowi pozostałe 90% czasu programowania.
— Kaz Dragon
70

Gdyby Java miała prawdziwe czyszczenie pamięci, większość programów usunąłaby się po uruchomieniu.
  - Robert Sewell

— bigown
źródło
22
zabawne, właśnie przypomniało mi się php.
— WalterJ89,
2
@ WalterJ89: Nie martw się! Do PHP 5.3 PHP jest przeliczane.
— zneak 10.10.10
Podoba mi się ten!
— MDV2000,
@ WalterJ89 Cóż, nie widzę powodu, aby wyróżniać Javę w przeciwieństwie do COBOL, C ++, VB lub innych.
— Mark C
69

Informatyka to nie tylko komputery, ale astronomia to teleskopy

- Edsger Dijkstra

— powiększenia
źródło
4
Tak, ale powinno to dotyczyć programowania , a nie informatyki. [sly grin]
— Mark C
Programowanie polega jedynie na wykorzystaniu wiedzy zgromadzonej w informatyce. Nie potrzebujesz komputera do programowania, przynajmniej żaden z nich nie jest zaznajomiony.
— Dasich
Zawsze czułem, że najbardziej denerwujące w programowaniu jest to, że nie mogę oddzielić go od komputerów.
— LoveMeSomeCode
57

Jeśli debugowanie jest procesem usuwania błędów oprogramowania, programowanie musi być procesem ich wprowadzania.
  - Edsger Dijkstra

— pramodc84
źródło
24
Dlatego lubię określać swoją pracę jako angażowanie .
— deceze
9
A konserwacja jako ponowna instalacja ?
— Joe D
1
@JoeD Nie, „obserwowanie błędów”.
— Mark C
56

Istnieją tylko dwa rodzaje języków: te, na które ludzie narzekają i te, których nikt nie używa

- Bjarne Stroustrup

— bigown
źródło
15
zła pretekst do zassania C ++
— hasen
3
C # jest oczywistym kontrprzykładem.
— Timwi
7
A VB należy do obu kategorii.
— Szybki Joe Smith
48

Najlepszą rzeczą w postaci logicznej jest to, że nawet jeśli się mylisz, to tylko trochę cię to niepokoi. - (Anonimowy)

— rev pramodc84
źródło
Najgorsze jest to, że nie możesz się bardziej mylić?
— POSIX_ME_HARDER
46

Dwukrotnie zapytano mnie: „Módlcie się, panie Babbage, jeśli wprowadzicie do maszyny niewłaściwe liczby, czy wyjdą prawidłowe odpowiedzi?” W jednym przypadku członek wyższej, aw drugim członek niższej izby zadał to pytanie. Nie jestem w stanie właściwie zrozumieć tego rodzaju pomieszania pomysłów, które mogłyby wywołać takie pytanie.
  - Charles Babbage

Prawdopodobnie pierwszy udokumentowany przypadek programisty napotykającego głupie pytania użytkowników.

— Jay
źródło
5
Brzmi jak pomysł na koszulkę! „Błąd użytkownika: zanieczyszczenie rzeczy od 1832 roku”. (Data?)
— Mark C
42

Zawsze chciałem, aby mój komputer był tak łatwy w obsłudze jak mój telefon; moje życzenie się spełniło, ponieważ nie mogę już wymyślić, jak korzystać z telefonu

- Bjarne Stroustrup

— 2 obrotów
źródło
42

Wszystko mówi do momentu uruchomienia kodu.
  - Ward Cunningham

— Walter
źródło
39

Obsługa Unicode nie jest „funkcją”. Jest to oczekiwane zachowanie.

To prawda, jest bardzo specyficzne, ale jest moim ulubionym, ponieważ przestarzałe zestawy znaków są po prostu zbyt szeroko stosowane ...

— Timwi
źródło
3
Teraz musisz się tylko spierać o to, który unicode
— Martin Beckett,
@Martin: Nie bardzo, ponieważ konwersja między różnymi rodzajami jest bezstratna.
— Billy ONeal 27.01.11
Aargh ból! Dlaczego muszę kłócić się z klientem, że nie, nie możemy „po prostu” przestawić całej infrastruktury na Latin-1, aby była dla niego nieskończenie wygodniejsza? „W końcu nikt tutaj nie używa tych dziwnych postaci specjalnych; nie może być tak ciężko, prawda?”
— Piskvor
39

Komentowanie kodu przypomina sprzątanie łazienki - nigdy nie chcesz tego robić, ale naprawdę zapewnia przyjemniejsze wrażenia dla Ciebie i Twoich gości.

- Ryan Campbell

— Coder Hawk
źródło
1
Meh ... Większość komentarzy, które spotkałem w życiu, są napisane przy założeniu, że komentarze mogą nadrobić źle napisany kod ..
— riwalk 14.10
Możesz wyczyścić łazienkę, ale jeśli prysznic ma tylko zimną wodę, a umywalka nie ma mydła, będzie to nieprzyjemne doświadczenie. Napisz kod, który czyta się łatwo, zamiast pisać ogromne komentarze, aby wyjaśnić różne rzeczy.
— Keyo,
Komentowanie sprawia mi przyjemność. Czasami umieszczam ważne komentarze w schludnych małych pudełkach z gwiazdkami i ukośnikami. Z drugiej strony jestem dziwakiem.
— Maks.
2
Lubię też pisać komentarze, ale nie chciałbyś widzieć mojej łazienki.
— Timwi
Byłem kiedyś w toalecie, gdzie były bardzo długo rozwiewane komentarze na temat tego, jak i dlaczego należy utrzymywać toaletę w czystości. To nie było czyste.
— Rei Miyasaka,
35

Programowanie jest jak seks: jeden błąd i trzeba go wspierać przez resztę życia.
  - Michael Sinz

— powiększenia
źródło
34

Semble que la perfection soittetee non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher.
  - Antoine de Saint-Exupéry, francuski pisarz (1900–1944), Terre des Hommes (1939)

(Wydawałoby się, że doskonałości osiąga się nie wtedy, gdy nie ma już nic do dodania, ale kiedy nie ma już nic do zabrania.)

— Bill Karwin
źródło
Dotyczy to także muzyki
— Heinz Z.
2
— David Kendal
2
@David Kendal: Fajnie! Podobnie Henry David Thoreau powiedział: „Uprość, uprość”. Co zawsze sprawia, że ​​myślę: „Uprość”.
— Bill Karwin
33

Java to JavaScript, podobnie jak samochód to dywan.
  - Chris Heilmann

— Bill Karwin
źródło
W moim samochodzie jest dywan, więc w Javie jest JavaScript?
— Keyo,
1
@Keyo: Tak, myślałem o tym podejściu. Nadal uważam, że cytat jest naprawdę sprytny.
— Bill Karwin,
31

Jak sformułował Eric S. Raymond :

Prawo Linusa

Biorąc pod uwagę wystarczająco dużą bazę beta-testerów i współautorów, prawie każdy problem zostanie szybko scharakteryzowany, a poprawa oczywista dla kogoś.

Lub mniej formalnie

Biorąc pod uwagę wystarczającą liczbę gałek ocznych, wszystkie błędy są płytkie.

— 8
źródło
brzmi trochę jak reguła małpy / maszyny do pisania ...
— Sean Patrick Floyd
Dlaczego entuzjaści Linuksa spędzają więcej czasu powtarzając ten cytat niż naprawiając błędy?
— Timwi
Albo hasło Atwood dla StackOverflow: „Nikt z nas nie jest tak głupi jak my wszyscy”. Zobacz codinghorror.com/blog/2008/09/…
— Evan Plaice
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.