home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / perl / 5892 < prev    next >
Encoding:
Internet Message Format  |  1992-09-12  |  6.4 KB
  1. Path: sparky!uunet!spool.mu.edu!sol.ctr.columbia.edu!usc!news!netlabs!lwall
  2. From: lwall@netlabs.com (Larry Wall)
  3. Newsgroups: comp.lang.perl
  4. Subject: Re: Perl language formatting conventions?
  5. Message-ID: <1992Sep12.203752.13716@netlabs.com>
  6. Date: 12 Sep 92 20:37:52 GMT
  7. References: <1992Aug25.152315.20630@news.eng.convex.com> <1992Aug27.042932.3143@netlabs.com> <1361@minya.UUCP>
  8. Sender: news@netlabs.com
  9. Distribution: comp
  10. Organization: NetLabs, Inc.
  11. Lines: 156
  12. Nntp-Posting-Host: scalpel.netlabs.com
  13.  
  14. In article <1361@minya.UUCP> jc@minya.UUCP (John Chambers) writes:
  15. : 
  16. : > I also use 4-space indent, in case you hadn't noticed.  :-)
  17. : 
  18. : It has always seemed to me that a single tab is the best indent.  That
  19. : way,  the  reader  can choose his/her own favorite indent spacing, and
  20. : everyone is happy.  (In vi you type "se ts=4" to  get  4-column  tabs;
  21. : most editors have a similar command.) It's also very fast to type.
  22.  
  23. That's fine if nobody but you ever has to look at the file, and you
  24. never have to print it.  It's also fine if you editor translates to
  25. standard 8-space hard tabs for you on input and output.  But if your
  26. editor is going to do that, why not just disconnect the notion of soft
  27. tab stops from hard tab characters?  In vi you just set sw=4 and learn
  28. to use ^T instead of TAB.  (Mind you, I'd've made TAB work like ^T
  29. does, and DEL/BACKSPACE like ^D, just so people couldn't use the
  30. laziness argument to avoid ^T/^D.  Then make some way to insert a hard
  31. tab if you want one.  One could almost do it with a keyboard mapping.)
  32.  
  33. : One of the silliest frustrations is all the programmers  who  like  to
  34. : use  mixtures  of  tabs  and spaces to get 4-column spacing with 8-col
  35. : tabs. This forces readers to reset the tabs to 8 columns to make sense
  36. : of  the  code;
  37.  
  38. Eek.  Talk about cultural differences...
  39.  
  40. : it is slow for the writer to type;
  41.  
  42. No.  Not with sw=4 and ^T and autoindent.
  43.  
  44. : it wastes disk space and network bandwidth.
  45.  
  46. A somewhat valid point, but I sincerely doubt that most of your disk is
  47. taken up with source code.  And much long haul traffic nowadays is
  48. compressed such that the way you tab your lines doesn't matter.
  49.  
  50. : It's about as wrong a convention as one  could
  51. : come up with (so of course it's the most common one ;-).
  52.  
  53. That's the point.  Yes, it's just a convention to be broken, but civil
  54. disobedience always has a price.  What I balk at, of course, is when *I*
  55. have to pay the price for *your* civil disobedience.  Then it's no longer
  56. mere civil disobedience.  More like disturbing the peace, or maybe
  57. dictatorship of the proletariet.  :-)
  58.  
  59. I don't mind squabbling over mere cultural differences as long as we
  60. realize that's all we're doing.  Certainly, I've learned to deal with
  61. the other sort of file--look at the retab script in the book, after all.
  62. Note that the default is to translate 8 spacing to 4...  :-)
  63.  
  64. : The next most difficult problem, of course, is  finding  the  boundary
  65. : between  declarations  and statements in a function (so that something
  66. : can be added there).  What's frustrating here is that the  original  C
  67. : compiler  allowed declarations to be mixed with statements (as long as
  68. : everything was declared before it was used),  so  the  problem  didn't
  69. : exist.   The  modern  "improvement"  requiring  that declarations come
  70. : before statements made  the  job  much  more  difficult,  and  for  no
  71. : apparent  reason  that I've ever heard.  It certainly doesn't make the
  72. : compiler's job any easier.  (Yes, I *have* written compilers; I  won't
  73. : listen  seriously to any claim that this affects the compiler-writer's
  74. : job materially.  ;-)
  75.  
  76. Yes, and you'll note that the distinction disappears again in C++.  Almost
  77. enough reason to switch right there...  :-)
  78.  
  79. : Actually, my favorite bit of nonsense in C formatting is  the  growing
  80. : practice  of what I call "Chinese" coding.  Recall that traditionally,
  81. : Chinese was written vertically, with one or two character per line.
  82.  
  83. Well, I'm sure they think of the lines as vertical, not horizontal.
  84. More cultural differences.  It's just the column-major vs row-major
  85. fight all over again.  :-)
  86.  
  87. : We are now seeing a lot of C in a similar style:
  88. : 
  89. :     if (!initf)
  90. :     {
  91. :         win = 
  92. :         XCreateSimpleWindow(
  93. :             display,
  94. :             RootWindow(display,screen),
  95. :             win_x,win_y,
  96. :             win_w,win_h,
  97. :             border_width,
  98. :             WhitePixel(display,screen),
  99. :             Pixel(display,screen)
  100. :             );
  101. :         initf = TRUE;
  102. :     }
  103. :         else
  104. :     {
  105. :         (void*)
  106. :     fprint(
  107. :         stderr,
  108. :             "%d *** %s can't create new window [%d=%s].\n"
  109. :             timestamp(),
  110. :             progname,
  111. :             errno,
  112. :             sys_errlist[errno]
  113. :         );
  114. :     }
  115.  
  116. This is becoming an unfortunate necessity.  The only alternatives I see are
  117.  
  118.     1) Go back to simpler problem spaces and simpler solution spaces.
  119.     2) Use shorter, less mnemonic names and consequently suffer more
  120.         confusion and name collisions.
  121.     3) Put fewer but wider windows on the screen and blow off the
  122.         punchcard metaphor once and for all.
  123.  
  124. My basic policy is, of course, to use one line or maybe two, until it
  125. starts looking cluttered, and then switch to the vertical format.  (The
  126. vertical format actually works better in languages that have named
  127. parameters.  In Perl 5, I'm making => a synonym for comma, so you can
  128. say things like:
  129.  
  130.     $childmess = &Get(
  131.             OC           => $oc,
  132.             OI           => $oi,
  133.             SCOPE        => $scope1,
  134.             ATTR_ID_LIST => $no_attrs);
  135.  
  136. As someone pointed out earlier, all you do is stuff the list into an
  137. associative array, and then pull out the parameters in the order you
  138. like.  If you don't think this is a win, note that the actual
  139. &new_GetReq call has 14 arguments, but most of them have defaults or
  140. can be undefined:
  141.  
  142.     sub Get {
  143.     local(%arg) = @_;
  144.     &new_GetReq(
  145.         defined($arg{ID}) ? $arg{ID} : &new_id(),
  146.         $arg{DELETE_CB},
  147.         $arg{SOURCE} || *def_source,
  148.         $arg{DEST} || *def_dest,
  149.         $arg{QOS} || *def_qos,
  150.         $arg{MODE},
  151.         $arg{APP_CONTEXT},
  152.         $arg{OC},
  153.         $arg{OI},
  154.         $arg{ACCESS},
  155.         $arg{SYNC},
  156.         $arg{SCOPE} || *def_scope,
  157.         $arg{FILTER} || *def_filter,
  158.         $arg{ATTR_ID_LIST});
  159.     }
  160.  
  161. So, would you rather call &Get, or &new_GetReq?  And if you really
  162. detest vertical alignment, you often have a better chance to fit it
  163. onto one line with named parameters than with positional parameters:
  164.  
  165.     $childmess = &Get(OC=>$oc, OI=>$oi, SCOPE=>$scope1, ATTR_ID_LIST=>$no_attrs);
  166.  
  167. Shoot, almost made it...  :-)
  168.  
  169. Larry
  170.