• PUDN用户
  • tcl/tk
  • 54KB
  • zip
  • 0
  • 1 积分
  • 4
  • 2010-04-17 07:24
Tcl/Tk Engineering Manual John K. Ousterhout
  • engManualTCL.pdf
<html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta charset="utf-8"> <meta name="generator" content="pdf2htmlEX"> <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"> <link rel="stylesheet" href="https://static.pudn.com/base/css/base.min.css"> <link rel="stylesheet" href="https://static.pudn.com/base/css/fancy.min.css"> <link rel="stylesheet" href="https://static.pudn.com/prod/directory_preview_static/622b5be815da9b288bf71a17/raw.css"> <script src="https://static.pudn.com/base/js/compatibility.min.js"></script> <script src="https://static.pudn.com/base/js/pdf2htmlEX.min.js"></script> <script> try{ pdf2htmlEX.defaultViewer = new pdf2htmlEX.Viewer({}); }catch(e){} </script> <title></title> </head> <body> <div id="sidebar" style="display: none"> <div id="outline"> </div> </div> <div id="pf1" class="pf w0 h0" data-page-no="1"><div class="pc pc1 w0 h0"><img class="bi x0 y0 w1 h1" alt="" src="https://static.pudn.com/prod/directory_preview_static/622b5be815da9b288bf71a17/bg1.jpg"><div class="t m0 x1 h2 y1 ff1 fs0 fc0 sc0 ls0 ws0">T<span class="_ _0"></span>cl/Tk Engineering Manual<span class="_ _1"> </span>September 1, 1994<span class="_ _2"> </span>1</div><div class="t m0 x2 h3 y2 ff2 fs1 fc0 sc0 ls0 ws0">T<span class="_ _3"></span><span class="ls1">cl/Tk Engineering Manual</span></div><div class="t m0 x3 h4 y3 ff3 fs2 fc0 sc0 ls0 ws0">John K. Ouster<span class="_ _4"></span>hout</div><div class="t m0 x4 h5 y4 ff1 fs2 fc0 sc0 ls0 ws0">Sun Microsystems, Inc.</div><div class="t m0 x5 h5 y5 ff1 fs2 fc0 sc0 ls0 ws0">john.ousterhout@eng.sun.com</div><div class="t m0 x6 h6 y6 ff4 fs2 fc0 sc0 ls0 ws0">1.<span class="_ _5"> </span>Introduction</div><div class="t m0 x7 h7 y7 ff1 fs3 fc0 sc0 ls0 ws0">This is a manual for people who are developing C code for T<span class="_ _6"></span>cl, Tk, and their extensions and</div><div class="t m0 x7 h7 y8 ff1 fs3 fc0 sc0 ls0 ws0">applications. It describes a set of conventions for writing code and the associated test scripts.</div><div class="t m0 x7 h7 y9 ff1 fs3 fc0 sc0 ls0 ws1">There are two reasons for the conventions. First, the conventions ensure that certain important</div><div class="t m0 x7 h7 ya ff1 fs3 fc0 sc0 ls0 ws2">things get done; for example, every procedure must have documentation that describes each of</div><div class="t m0 x7 h7 yb ff1 fs3 fc0 sc0 ls0 ws0">its arguments and its result, and there must exist test scripts that exercise every line of code.</div><div class="t m0 x7 h7 yc ff1 fs3 fc0 sc0 ls0 ws0">Second, the conventions guarantee that all of the T<span class="_ _6"></span>cl and Tk code has a uniform style. This</div><div class="t m0 x7 h7 yd ff1 fs3 fc0 sc0 ls0 ws0">makes it easier for us to use, read, and maintain each other&#8217;<span class="_ _0"></span>s code.</div><div class="t m0 x8 h7 ye ff1 fs3 fc0 sc0 ls0 ws0">Most of the conventions originated in the Sprite operating system project at U.C. Berke-</div><div class="t m0 x7 h7 yf ff1 fs3 fc0 sc0 ls0 ws0">ley<span class="_ _6"></span><span class="ws3">. At the beginning of the Sprite project my students and I decided that we wanted a uniform</span></div><div class="t m0 x7 h7 y10 ff1 fs3 fc0 sc0 ls0 ws4">style for our code and documentation, so we held a series of meetings to choose the rules. The</div><div class="t m0 x7 h7 y11 ff1 fs3 fc0 sc0 ls0 ws0">result of these meetings was a document called<span class="_"> </span><span class="ff3">The Sprite Engineering Manual</span>. None of us</div><div class="t m0 x7 h7 y12 ff1 fs3 fc0 sc0 ls0 ws5">was completely happy with all the rules, but we all managed to live by them during the project</div><div class="t m0 x7 h7 y13 ff1 fs3 fc0 sc0 ls0 ws6">and I think everyone was happy with the results. When I started work on T<span class="_ _6"></span>cl and Tk, I decided</div><div class="t m0 x7 h7 y14 ff1 fs3 fc0 sc0 ls0 ws7">to stick with the Sprite conventions. This document is based heavily on<span class="_"> </span><span class="ff3">The Sprite Engineering</span></div><div class="t m0 x7 h7 y15 ff3 fs3 fc0 sc0 ls0 ws7">Manual<span class="ff1">.</span></div><div class="t m0 x8 h7 y16 ff1 fs3 fc0 sc0 ls0 ws0">There are few things that I consider non-negotiable, but the contents of this manual are</div><div class="t m0 x7 h7 y17 ff1 fs3 fc0 sc0 ls0 ws0">one of them. I don&#8217;t claim that these conventions are the best possible ones, but the exact con-</div><div class="t m0 x7 h7 y18 ff1 fs3 fc0 sc0 ls0 ws0">ventions don&#8217;t really make that much dif<span class="_ _0"></span>ference. The most important thing is that we all do</div><div class="t m0 x7 h7 y19 ff1 fs3 fc0 sc0 ls0 ws0">things the same way<span class="_ _6"></span>. Given that the core T<span class="_ _6"></span>cl and Tk code follows the conventions, changing</div><div class="t m0 x7 h7 y1a ff1 fs3 fc0 sc0 ls0 ws0">the rules now would cause more harm than good.</div><div class="t m0 x8 h7 y1b ff1 fs3 fc0 sc0 ls0 ws0">Please write your code so that it conforms to the conventions from the very start. For</div><div class="t m0 x7 h7 y1c ff1 fs3 fc0 sc0 ls0 ws0">example, don&#8217;t write comment-free code on the assumption that you&#8217;ll go back and put the</div><div class="t m0 x7 h7 y1d ff1 fs3 fc0 sc0 ls0 ws0">comments in later once the code is working. This simply won&#8217;<span class="_ _0"></span>t happen. Regardless of how</div><div class="t m0 x7 h7 y1e ff1 fs3 fc0 sc0 ls0 ws0">good your intentions are, when it comes time to go back and put in the comments you&#8217;ll &#64257;nd</div><div class="t m0 x7 h7 y1f ff1 fs3 fc0 sc0 ls0 ws0">that you have a dozen more important things to do; as the body of uncommented code builds</div><div class="t m0 x7 h7 y20 ff1 fs3 fc0 sc0 ls0 ws0">up, it will be harder and harder to work up the ener<span class="_ _4"></span>gy to go back and &#64257;x it all. One of the fun-</div><div class="t m0 x7 h7 y21 ff1 fs3 fc0 sc0 ls0 ws0">damental rules of software is that its structure only gets worse over time; if you don&#8217;<span class="_ _0"></span>t build it</div><div class="t m0 x7 h7 y22 ff1 fs3 fc0 sc0 ls0 ws0">right to begin with, it will never get that way later<span class="_ _6"></span>. When I write code I typically write the pro-</div><div class="t m0 x7 h7 y23 ff1 fs3 fc0 sc0 ls0 ws0">cedure headers for a whole &#64257;le before I &#64257;ll in any of the bodies.</div><div class="t m0 x8 h7 y24 ff1 fs3 fc0 sc0 ls0 ws0">The rest of this document consists of 8 major parts. Section<span class="_"> </span>2 discusses the overall struc-</div><div class="t m0 x7 h7 y25 ff1 fs3 fc0 sc0 ls0 ws0">ture of a package and how to organize header &#64257;les. Section<span class="_ _7"> </span>3 describes the structure of a C</div><div class="t m0 x7 h7 y26 ff1 fs3 fc0 sc0 ls0 ws0">code &#64257;le and how to write procedure headers. Section<span class="_"> </span>4 desribes the T<span class="_ _6"></span>cl/Tk naming conven-</div><div class="t m0 x7 h7 y27 ff1 fs3 fc0 sc0 ls0 ws8">tions. Section<span class="_"> </span>5 presents low-level coding conventions, such as how to indent and where to put</div><div class="t m0 x7 h7 y28 ff1 fs3 fc0 sc0 ls0 ws0">curly braces. Section<span class="_"> </span>6 contains a collection of rules and suggestions for writing comments.</div><div class="t m0 x7 h7 y29 ff1 fs3 fc0 sc0 ls0 ws0">Section<span class="_"> </span>7 describes how to write and maintain test suites. Section<span class="_"> </span>8 describes how to make</div></div><div class="pi" data-data='{"ctm":[1.568627,0.000000,0.000000,1.568627,0.000000,0.000000]}'></div></div> </body> </html>