| |||||||||||||
This is the same as human languagesThis is the same as human languagesPosted Nov 4, 2011 22:37 UTC (Fri) by khim (subscriber, #9252)In reply to: Flippant code comments by giraffedata Parent article: Quote of the week
When I have to understand uncommented C code, I usually decipher it little by little and write down my findings in English and then use that document for all my work. You are doing it wrong(tm)! Side question: how many human languages do you know? I found that "computer languages" and "human languages" share more then just the second word. The same principles work in both cases. As long as you try to use "first translate the sentence, then understand it" approach you'll be crippled WRT human languages. If you use "decipher it little by little ... and then use that document" approach for computer language you'll be crippled WRT computer languages. You can not learn the skill for one simple reason: you are too busy making sure you'll never even try. For example, I have 1300 lines of English about what various parts of Mplayer do. It saves me hours every few years when I have to fix a bug or add a feature. Hmm... This looks like an abstract. Useful thing to have both for large native language creations (like series of novels) and for large programs, too. Does not have anything to do with the ability to read C code. If I didn't want to preserve the ability to merge Mplayer updates from others, I'd just put that text into the source files as comments. Why would you want to do that? There are about 600'000 lines of code in Mplayer. Your abstract only includes 1300 lines. Basically only few lines per file. This is useful thing to have - but why will you need to disperse all this succinct knowledge in large mass of highly detailed C code?
(Log in to post comments)
This is the same as human languages Posted Nov 5, 2011 0:16 UTC (Sat) by giraffedata (subscriber, #1954) [Link] I found that "computer languages" and "human languages" share more then just the second word. The same principles work in both cases. I agree. But the weakest human language outstrips the most powerful computer language in one area: the ability to express abstraction (and for an obvious reason - it would not survive the concomitant imprecision). And here, we're not talking about computer languages in general, but a particularly low level one: C.
As long as you try to use "first translate the sentence, then understand it" ... Agreed, and let me be clear on my process: I don't translate each line of C into a line of English. That would be ridiculous (though it is a popular style, especially among assembly language programmers). I translate maybe 50 lines of code into a few sentences. It's that abstraction that many C programmers appear to eschew. They can read the 50 precise lines more easily than the few abstract sentences. Why would you want to do that? There are about 600'000 lines of code in Mplayer. Your abstract only includes 1300 lines. Basically only few lines per file. This is useful thing to have - but why will you need to disperse all this succinct knowledge in large mass of highly detailed C code? I've never looked at most of those 600,000 lines. My 1300 lines covers a small fraction of them, and if I were to put them into the code as comments, they would show up as e.g. 20 lines at the top of a 300 line subroutine telling what it does or 10 lines below a variable declaration telling what its value means. Maybe 5 paragraphs at the top of the cache subsystem file explaining what the cache subsystem is and how it works. Since I do have to read some of the individual lines of code, it's easiest to have the English adjacent to them to this degree.
|
|||||||||||||