I know I was the one who called for dropping the strtok discussion, but in the light of a new day, I actually thought of a relevant point, and thought I'd toss it out there. The crux of the previous strtok argument (aside from a few technical points) seems to be over whose responsibility it is to either avoid or prevent coders from falling into various programming pitfalls. Before I pose my question, I'll state that I've always been on the side that says one shouldn't have to re-document the C language for future coders. There are thousands of resources available for learning C, and I have always felt free to assume that anyone maintaining my code would have reasonable general knowledge of the language. I was even forced to stand by this conviction once, when during a code review (I am a professional programmer, and am subject to such scrutiny) a fellow programmer requested that I use comments to document a very basic use of a ternary operator because not all programmers would necessarily be familiar with it. All that being said, CircleMUD is clearly not being used solely by experienced C programmers. While I definitely disagree with the notion of bending over backwards to aid hypothetical novices dealing with imagined complexities, I do believe that there are some reasonable steps that could be taken to reduce the learning curve. My question is this: How do people on this list feel about the notion of documenting style, calling conventions, or other _complex_ techniques being used in Circle, as well as in patches, snippets, etc? I also admit to some ignorance as to the state of the "coding" document, but clearly that might be a good alternative if a completed version is available. What do you think? Mike -- +---------------------------------------------------------------+ | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html | | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html | +---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/05/01 PST