4 ms·

Reading code always worried me. That was always my biggest deficit in school - I couldn't just pick up someone else's code and dive in, it took a lot of effort

• roguecoder 14y ago
  It's really about practice and context. Context makes it so much easier. In the real world there is usually a purpose to code, and good code has a cohesive metaphor you can understand before you start reading. Practice eventually makes the syntax second-nature, but I found being able to understand the context and subtext of the code is a much bigger boost. I took a poetry class in college and found that learning to read poetry helped me become more fluent at reading code. Instead of reading it like prose, from start to finish, reading poetry is about building a mental castle of what the poet is talking about, and then the actual words fill in the important details. Plus you learn to pick up on repetition, rhythm, deviations from established patterns and is-a relationships ;-)
• calibraxis 14y ago
  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 14y ago
    Don't add printf, add unit tests!
    • gaius 14y 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 14y 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 14y 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 ;-)
• swapsmagic 14y ago
  For me it's the other way around. Reading and understanding others code is easier for me rather developing it from scratch in the beginning. Though now i have improved in the later part.
• meej 14y ago
  At least you understand how important it is. I graduated from engineering school in 1999 and I still marvel at the classmate in my data structures class who complained that there were too many code reading exercises on the exams during the semester-end course evaluation. It was like he thought he would spend his life writing code and never reading it, I was amazed. I recently started programming at work after at least a decade of mostly not programming at work. My experience so far has been that reading code is easier than writing it, at least when an unfamiliar SDK is involved.