home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / c / 12898 < prev    next >
Encoding:
Internet Message Format  |  1992-08-27  |  2.9 KB
  1. Path: sparky!uunet!olivea!decwrl!bu.edu!spacefox
  2. From: spacefox@acs.bu.edu (Godfrey Degamo)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Most difficult part of learning C?
  5. Message-ID: <94798@bu.edu>
  6. Date: 28 Aug 92 01:50:17 GMT
  7. References: <9208251159.AA04122@ult4> <15230@ksr.com>
  8. Sender: news@bu.edu
  9. Organization: Boston University, Boston, MA, USA
  10. Lines: 51
  11. Originator: spacefox@acs.bu.edu
  12.  
  13.  
  14.  
  15. I agree totally with John F. Woods.  Learning C was easy.  Mastering C,
  16. just like mastering any computer language, will take a lifetime pursuit.
  17. This reminds me of a funny, but full of wisdom quote from my C bible :)  :
  18.  
  19.  
  20.      A substantial part of designing good modules and good functions is
  21. perhaps best described as "common sense."  This includes a healthy respect
  22. for human frailty and a willingness to leave well enough alone.  For example,
  23. C is designed to implement the int data type efficiently.  If you don't
  24. have a particular need for a long int or unsigned int, don't use them.  Don't
  25. use an isolated char simply to save an atom of space.  Avoid fiddling with
  26. data types just for some aesthetic pleasure or sense of orderliness.  Don't
  27. use typedef symbols when keywords will do.  Don't #define constants when
  28. what you mean is zero or nonzero; just use zero and one.  Resists casts;
  29. they're for broken bones.  Don't create data structures if there's nothing
  30. inherently structured about your data.  Use short names when they say what
  31. you mean.
  32.  
  33. [But, heres where it gets pretty funny....]
  34.  
  35.      Eliminate the ornaments of programs and instead focus on the clarity
  36. of your code and the ingenuity of your methods.  You will program rings around
  37. Fancy Dan, who never learned to leave well enough alone.  While Fancy Dan
  38. is becoming an expert on the faults of compilers, because his program stress
  39. their limitations, you are getting your work done.
  40.  
  41.                                                 -Craig Bolan,
  42.                                                  Mastering C
  43.                                                  III:12:221
  44.  
  45. :)
  46.  
  47.  
  48. Well, I'll admit this is just a waste of newsgroup space!  I suggest that
  49. you introduce the concepts of software engineering early.  but, then
  50. software engineering is not specific to the C language!  Ah well...
  51. I find that with me, most of the things people have listed as the hardest
  52. part of learning C, is really just a lack of discipline.  No insult intended!
  53. If you're having problems with pointers, draw a diagram; if you're having,
  54. problems with operator precedence memorize them or use alot of '()'
  55.  
  56. Well, to stop making you think that I'm an arrogant C programmer, I don't know
  57. the correct syntax to the switch statement, in fact, I don't know more than 60%
  58. of the specifics to any of the stdio.h or stdlib.h modules!  But, that's why
  59. I have a trusty C manual!  (maybe that's why Microsoft turned me down?  hmmm...)
  60.  
  61.                                        -scherzo,
  62.                                         G. Degamo,
  63.                                          spacefox@acs.bu.edu
  64.