Slashdot Mirror
Ask Slashdot: How Do You Read Code?
New submitter Gornkleschnitzer writes: The majority of humans read silently by rendering a simulation of the printed words as if they were being spoken. By reading that sentence, chances are you're now stuck being conscious of this, too. You're welcome.
As a programmer (and a reader of fanfiction), plenty of things I read are not valid English syntax. When I find myself reviewing class definitions, for loops, and #define macros, I rely on some interesting if inconsistent mental pronunciation rules. For instance, int i = 0; comes out as "int i equals zero," but if(i == 0) sometimes comes out as either "if i is zero" or "if i equals equals zero." The loop for(size_t i = 0; i < itemList.size(); ++i) generally translates to "for size T i equals zero, i less than item list dot size, plus-plus i." I seem to drop C++ insertion/extraction operators entirely in favor of a brief comma-like pause, with cout << str << endl; sounding like "kowt, stur, endel."
What are your code-reading quirks?
As a programmer (and a reader of fanfiction), plenty of things I read are not valid English syntax. When I find myself reviewing class definitions, for loops, and #define macros, I rely on some interesting if inconsistent mental pronunciation rules. For instance, int i = 0; comes out as "int i equals zero," but if(i == 0) sometimes comes out as either "if i is zero" or "if i equals equals zero." The loop for(size_t i = 0; i < itemList.size(); ++i) generally translates to "for size T i equals zero, i less than item list dot size, plus-plus i." I seem to drop C++ insertion/extraction operators entirely in favor of a brief comma-like pause, with cout << str << endl; sounding like "kowt, stur, endel."
What are your code-reading quirks?
It's sometimes odd to hear others pronounce code, because it may not align with your own mental map of how things should be pronounced. I remember getting mildly distracted when watching one of Stephen Lavavej's videos because he would call shared_ptr "shared putter" (with the u pronounced similar to 'put'). Why would you abbreviate the sound when it's not any shorter than "pointer"?
When reading code by myself, though, I think the translation to a phonetic translation happens quite subconsciously, because I'm typically not aware of it at all. It obviously happens to some extent, or I wouldn't have been bothered by STL's reading. So, trying to think it through (which I haven't done before, really), I can assure you that == would never be "equal equal". It would be "is equal to". "cout" is not "kowt", but "see-out". And I use > so infrequently, I think I don't even bother with a mental pronunciation.
Irony: Agile development has too much intertia to be abandoned now.
I teach introductory C++ programming courses at a large, urban community college. Getting students to be able to read and write the syntax reliably is itself a major challenge (e.g., poor initial reading/writing skills, never encountered programming before, about half not native English readers, etc.). So at numerous points during the course I ask for the class as a whole to direct my coding at the lectern for some simple problem. "What should I type here?" And of course, we need some recognized way to verbalize that.
The OP touches on the toughest nut I've found in that regard -- that there's no agreed-upon way to pronounce the symbols for C++ stream insertion/extraction operators (e.g., the OP mentions that he just leaves those uniquely silent). Notice that I'm talking about the typographical symbols here, not the name of the C++ operator. E.g.: For the C++ "and" operator, you type the symbol "double-ampersand". But if a student were to say, "insertion operator", and I said, "and how do we type that on the keyboard?", there is surprisingly no agreement in what that symbol is.
Asked this on Stack Overflow a few months ago, to no good resolution: How do you read the... and... symbols out loud?
We know where leadership by an anti-intellectual "strongman" who scapegoats minorities and likes boisterous rallies goes
That said code should be written in small snippets and as much as possible idiomatically. One recent troubling innovation I have seen are developers trying to do several things in one line of code, like they are trying to win the c obfuscation contest. It makes little sense as we are not using teletypes, and the compiler will optimize code as needed. What we know is that gates and memory is much cheaper than people, and we only need to optimize the code that is run often and is in fact slow.
So, to answer the question, how we read code depends on how code it written, just like we read anything. For the most part code should be written as easily accessible poetry, not literature, not a physics textbook. The skill in reading code, again just like any reading, is not the decoding or sounding out of the text, but the comprehension of the meaning.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
Your post made me realize I do not read the source, I look at them it like I would do with a map or a geometric shape. And when someone reads me code, I have to do the mental work of representing it differently as when spoken.
I recall reading a paper once that mapped how novice programmers read and understand code onto a mapping to express their level of development as programmers. The most basic level was a verbose restatement of the code in English, without grasping what the code did as a whole, whereas the highest level was a high-level description of what it accomplished, typically in as few words as possible.
Also, "plus-plus variable" seems like a bad way to word it internally even if you're breaking it down to the most basic level. "Pre-increment variable" seems like a much better way to think about it, especially if it's being used as an index into an array or anywhere outside of a standalone statement .
Actually, only people who read poorly do that. People who read well decode printed words directly into mental concepts, rather than sounding them all out, only sounding out a word when it is unfamiliar in print.
That (essentially correct) observation led to the creation of the "Look-Say" method of teaching English and its replacement of "Phonics" in the public schools.
Look-Say attempted to skip the "learn new words by sounding them out" step and teach students immediately to use the faster words-as-a-chunk technique of good readers.
But that ended up crippling them, because it left them with no way to acquire new words. They knew the handfull they'd encountered in class as a set of pictograms but didn't have the "secret code" to parse somethig they hadn't seen before. Result: Mostly illiterate graduates whose reading was so painful to them that they did little, getting farther and farther behind.
Turns out that good readers of substantially phonetic languages start with sounding-out (Phonics-style). Then as they gain skill and experience they start recognizing progressively more words at-a-glance, falling back to sounding-out when they hit words for which they hadn't yet built a neural-net recognizer. Eventually the "speed-bump" words become so rare that they blaze along familiar vocabulary without appearing to sound-out at all. But new or rare words bring out the old toolset, rather than bringing them to a full stop.
There are a corresponding pair of methods for learning a "second (i.e. additional) language: The "Grammatical Method" (learn and practice the lnguage rules) and the "Audiolingual Method" (repeat the samples). The latter came from an attempt to emulate the rapid language acquisition of children by modeling their environent
Tested right after a series of courses, college students taught by either method score about the same. Tested a year or so later (if they haven't been re-exposed to the second language meanwhile) those taught by the Grammatical Method had a significant skill loss, while those taught by the Audiolingual Method were unable to emit any sentence they hadn't encountered in class. Oops!
Turns out that (unless you learn two or more languages as a child) the neural structures that make kids little language acquisition machines literally die off, in several stages (at the ends of age ranges called "critical periods") as the neurons that weren't used by the language learned are "pruned". Once this has happened, learning a new language isn't impossible. But it's more like recovering from a stroke.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Not sure how serious you are about this.
I don't "read" code. I parse it with my eyes, and visualize in my mind what it does and how it will execute. As I look through each code file and put the pieces together I can see the bigger picture and how all of the code interacts.
When I'm building an application, I do the reverse. I "see" what I want the outcome to be, and build the code to make it happen. Sometimes mulling the structure for days, weeks, months before actually writing any code.
I'm being quite serious about this... is there a term for this? It's quite difficult to explain to people who don't understand what I mean, and so far the majority of people I've spoken to about it look at me like I'm a nutcase.