From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d89b08801f2aacae X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-05-27 16:31:13 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!news.stealth.net!news.stealth.net!news-east.rr.com!chnws02.ne.ipsvc.net!cyclone.ne.ipsvc.net!24.128.8.70!typhoon.ne.ipsvc.net.POSTED!not-for-mail Message-ID: <3CF2C1C2.1020602@attbi.com> From: "Robert I. Eachus" Organization: Eachus Associates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en,pdf MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Is strong typing worth the cost? References: <4519e058.0204290722.2189008@posting.google.com> <3CCE8523.6F2E721C@earthlink.net> <3CCEB246.9090009@worldnet.att.net> <3CCFFB7F.B8080F7A@despammed.com> <3CD1608B.A6336379@despammed.com> <3CD176D5.31892591@otelco.net> <3CF1231F.6000609@attbi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 27 May 2002 23:26:57 GMT NNTP-Posting-Host: 24.61.239.24 X-Complaints-To: abuse@attbi.com X-Trace: typhoon.ne.ipsvc.net 1022542017 24.61.239.24 (Mon, 27 May 2002 19:26:57 EDT) NNTP-Posting-Date: Mon, 27 May 2002 19:26:57 EDT Xref: archiver1.google.com comp.lang.ada:24854 Date: 2002-05-27T23:26:57+00:00 List-Id: Brian Rogoff wrote: > Another related question I'd like language designers to think about is the > relationship between verbosity and readability. It's often insinuated in > the Ada community that verbosity and readability are directly proportional, > but I don't believe that's true. If we look at the history of mathematics, > there was a period of time when mathematicians wrote mathematics like > prose, and it was a big advance to get more succint notations. Just making > it like prose does not enhance readability, especially when the underlying > ideas are just inherently difficult, as with mathematics. I think you may have gotten a wrong impression here. I think that outside of software with very tough performance requirements, anyone here would favor adding one line of code if it replaced the necessity for three lines of comments. In practice that trade-off almost always occurs in declarative parts where additional Ada source is unlikely to result in code size expansion or performance penalties. Having said that, if I am given the choice between two ways to implement a function or package in Ada, one that is more complex and requires much more source code, which am I going to choose? Right. So the natural evolution of Ada code during the creation process is toward smaller more easily understood modules with fewer comments explaining obscure or difficult to understand sections. My personal criteria are that comments that explain what a package, module, or section of code does are fine. Comments on why something is done one way instead of another are also a good idea. For example, in an implementation of the Miller-Rabin algorithm I just wrote: -- We now need to pick off all the bits of Reduced in reverse order. -- It shouldn't matter how we express this, but just in case avoid two -- obvious divide routines. loop Temp := Temp_Reduced/2; if Temp + Temp /= Temp_Reduced ... Temp_Reduced := Temp; The first comment is definitely what, and the second explains why I chose not to use (Temp_Reduced mod 2) /= 0 to test the low-order bit. This is inside a generic, with the intent that Temp_Reduced could be a non-standard integer type, and the compiler might not be able to do the test for oddness efficiently. Oh, and the parantheses around Temp_Reduced mod 2 above are another example of helping the reader. I know the parentheses are unnecessary, but they make reading easier. Comments that explain how code works are a clue that I shouldn't write the code that way, but in a way that is more self-explanatory. Comments that explain what a variable is used for indicate that the variable is poorly named, and so on. So I guess what I am saying is that the "Ada style" is to move comments into compilable source code whenever possible.