3 ms·

Well, OPC (Other People's Code) is generally unpleasant to read. ;) Rarely do people try to write programs "for people to read, and only incidentally for machin

Well, OPC (Other People's Code) is generally unpleasant to read. ;) Rarely do people try to write programs "for people to read, and only incidentally for machines to execute", as SICP puts it. So, I think it helps to do more than just passively "read" it. I might create a private branch, run the sucker with lots of print statements, comment the hell out of it, take copious notes in org-mode, draw diagrams to leverage my visual systems, etc. (It might feel silly, but no one's watching.) Running it repeatedly (with print statements) allows me to form little hypotheses and test them. The idea is to approximate having a REPL. Something like emacs helps to automate this as much as feasible.

Drbble 15y ago
Don't add printf, add unit tests!
- gaius 15y ago
  Printf tells you "this function entered, then that function" while the program is running. Unit tests are trendy, but how do you know what to unit test before you even know the code paths? Do you even care about individual functions at that level? Printf may be dirty, but in the initial stages it's better even than a debugger with breakpoints.
  - calibraxis 15y ago
    Interesting, I too kind of believe that print statements are better than debuggers, but I always thought that was an irrational belief on my part. (Like, I often don't have a decent debugger available, so never got much experience using them.) What are your reasons?
    - gaius 15y ago
      It's just easy, intuitive, doesn't require any scaffolding, and gives you just the information you want, exactly as your program sees it, yet with the full power of the language to format it exactly as you want to see it, in the most useful way. A breakpoint will do the same thing sure, but only by stopping your program in its tracks! Dtrace is the only thing I've seen that is as useful as liberally sprinkled printf's. A unit test will tell you if you know what output a function should give for a given input, that it does. Ermm, brilliant, but what if that function isn't on your code path anyway? And assuming that you already understand the program well enough to create any state the function expects if it's impure. Above poster has drunk too much Kool-aid and is suffering from Golden Hammer Syndrome ;-)

Drbble 15y ago

Don't add printf, add unit tests!

gaius 15y ago
Printf tells you "this function entered, then that function" while the program is running. Unit tests are trendy, but how do you know what to unit test before you even know the code paths? Do you even care about individual functions at that level? Printf may be dirty, but in the initial stages it's better even than a debugger with breakpoints.
- calibraxis 15y ago
  Interesting, I too kind of believe that print statements are better than debuggers, but I always thought that was an irrational belief on my part. (Like, I often don't have a decent debugger available, so never got much experience using them.) What are your reasons?
  - gaius 15y ago
    It's just easy, intuitive, doesn't require any scaffolding, and gives you just the information you want, exactly as your program sees it, yet with the full power of the language to format it exactly as you want to see it, in the most useful way. A breakpoint will do the same thing sure, but only by stopping your program in its tracks! Dtrace is the only thing I've seen that is as useful as liberally sprinkled printf's. A unit test will tell you if you know what output a function should give for a given input, that it does. Ermm, brilliant, but what if that function isn't on your code path anyway? And assuming that you already understand the program well enough to create any state the function expects if it's impure. Above poster has drunk too much Kool-aid and is suffering from Golden Hammer Syndrome ;-)