home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / perl / 5876 < prev    next >
Encoding:
Internet Message Format  |  1992-09-11  |  3.6 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!eff!world!ora.com!minya!jc
  2. From: jc@minya.UUCP (John Chambers)
  3. Newsgroups: comp.lang.perl
  4. Subject: Re: Perl language formatting conventions?
  5. Summary: y
  6. Message-ID: <1361@minya.UUCP>
  7. Date: 11 Sep 92 19:05:02 GMT
  8. References: <1992Aug25.152315.20630@news.eng.convex.com> <1992Aug27.042932.3143@netlabs.com>
  9. Distribution: comp
  10. Lines: 95
  11.  
  12.  
  13. > I also use 4-space indent, in case you hadn't noticed.  :-)
  14.  
  15. It has always seemed to me that a single tab is the best indent.  That
  16. way,  the  reader  can choose his/her own favorite indent spacing, and
  17. everyone is happy.  (In vi you type "se ts=4" to  get  4-column  tabs;
  18. most editors have a similar command.) It's also very fast to type.
  19.  
  20. One of the silliest frustrations is all the programmers  who  like  to
  21. use  mixtures  of  tabs  and spaces to get 4-column spacing with 8-col
  22. tabs. This forces readers to reset the tabs to 8 columns to make sense
  23. of  the  code; it is slow for the writer to type; it wastes disk space
  24. and network bandwidth.  It's about as wrong a convention as one  could
  25. come up with (so of course it's the most common one ;-).
  26.  
  27.  
  28. > This is evil.  Any dangled statement longer than one line should be
  29. > enclosed in braces.  One of the reasons I require braces in Perl...
  30.  
  31. I'd argue that braces should always be  used.   I've  written  various
  32. programs  to  process C code, and the single most difficult problem is
  33. discovering the scope of if, for, and while constructs.  Suppose,  for
  34. example,  that  my program is trying to add a command as the first (or
  35. last) line of all if and if-else constructs.  In perl, this is  rather
  36. straightforward.   In C, it is almost impossible, without doing a full
  37. parse of the entire language (including reading all header  files  and
  38. expanding all macros).
  39.  
  40. The next most difficult problem, of course, is  finding  the  boundary
  41. between  declarations  and statements in a function (so that something
  42. can be added there).  What's frustrating here is that the  original  C
  43. compiler  allowed declarations to be mixed with statements (as long as
  44. everything was declared before it was used),  so  the  problem  didn't
  45. exist.   The  modern  "improvement"  requiring  that declarations come
  46. before statements made  the  job  much  more  difficult,  and  for  no
  47. apparent  reason  that I've ever heard.  It certainly doesn't make the
  48. compiler's job any easier.  (Yes, I *have* written compilers; I  won't
  49. listen  seriously to any claim that this affects the compiler-writer's
  50. job materially.  ;-)
  51.  
  52. Actually, my favorite bit of nonsense in C formatting is  the  growing
  53. practice  of what I call "Chinese" coding.  Recall that traditionally,
  54. Chinese was written vertically, with one or two character per line. We
  55. are now seeing a lot of C in a similar style:
  56.  
  57.     if (!initf)
  58.     {
  59.         win = 
  60.         XCreateSimpleWindow(
  61.             display,
  62.             RootWindow(display,screen),
  63.             win_x,win_y,
  64.             win_w,win_h,
  65.             border_width,
  66.             WhitePixel(display,screen),
  67.             Pixel(display,screen)
  68.             );
  69.         initf = TRUE;
  70.     }
  71.         else
  72.     {
  73.         (void*)
  74.     fprint(
  75.         stderr,
  76.             "%d *** %s can't create new window [%d=%s].\n"
  77.             timestamp(),
  78.             progname,
  79.             errno,
  80.             sys_errlist[errno]
  81.         );
  82.     }
  83.  
  84. Sometimes 
  85.     I 
  86.     really get 
  87.     the feeling that 
  88.         C programmers 
  89.         are actively trying 
  90.         to make 
  91.         their code 
  92.             as difficult 
  93.         as possible
  94.         to read;
  95.     but then,
  96. at other times,
  97.     I
  98.     just feel
  99.     that
  100.     it's all
  101.         silly.
  102. -- 
  103. All opinions Copyright (c) 1992 by John Chambers. Inquire for licensing at:
  104. 1-617-647-1813 ...!{bu.edu,harvard.edu,eddie.mit.edu,ruby.ora.com}!minya!jc 
  105. --
  106. Pensu tutmonde; agu loke.
  107.