Xref: utzoo comp.object:3296 comp.lang.misc:7573 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!igor!rutabaga!jls From: jls@rutabaga.Rational.COM (Jim Showalter) Newsgroups: comp.object,comp.lang.misc Subject: Re: Readability of Ada Message-ID: Date: 23 Apr 91 00:36:19 GMT References: <3878@ssc-bee.ssc-vax.UUCP> Sender: news@Rational.COM Followup-To: comp.object Lines: 195 >2) What? *as usual*, written with two-character "identifiers"? > After nearly 10 years of C programming, and looking at millions > of lines of others C code, I have *never* seen *anyone* that > used *as usual* 2 char identifiers for variable names. I take it then you've never read the C book written by one of the language's inventors? You know, the one with all the one and two character identifier names? And I take it that you've never seen 'i' used as the control variable on a "for" loop? I mean, really, I've seen ZILLIONS of one or two character identifier names. That the code you've read and the code I've read have been disjoint sets seems to defy the laws of probability. Are you sure you don't want to retract your above claim? "Never" is a rather strong statement. >3) Oh yea, that's what I always try to do when I write C code - > write with maximum utilization of C's cryptic syntax. Get real. Maybe you don't, but it's a popular enough passtime that they have PUZZLE columns in the trade press. >] Writing as well as possible in C, one can still not write >] programs that are as readable and understandable as programs >] written in Ada by an equally competent programmer with the same >] objectives in mind. > Oh, come on. I take back the claim above about the most ridiculous >thing I've ever seen. *This* is the most ridiculous thing I've ever seen... >This is total, absolute, unabashed crap. Look, put up or shut up. I've gotten all sorts of flak about how silly/unfair it is to compare the readability of one language over another, but I haven't yet gotten an example from anybody of what they consider a readable version, in C, of my Ada example. It would seem to me that, if this is so easy to do, SOMEONE on the worldwide net would have been able to do it by now. I mean, all I'm asking people to do is use that wonderful readable C language to write a dinky little algorithm as readably as I did in Ada. Perhaps you'd like to go first? >Well, I was not about to be goaded into writing the julian code in C, >but the last statement I quoted above from Jim has pushed me over the edge. >Here is the code Jim has asked for in C: [several screenfulls of heavily commented C code deleted to save bandwidth and modem agony] So, this is it? Allow me to make a few comments on your example: 1) It takes up considerably more room than my Ada example. Very odd, seeing as how a common criticism people make of Ada is that it is verbose. 2) Much of the space taken up by your example is comments. You'll note that in my example there aren't very many comments. This is deliberate: I think Ada is readable enough to be largely self-documenting. You apparently believe no such thing about C, reinforcing the very point you are struggling to disprove. 3) Much of the rest of the space taken up by your example is occupied by definitions of stuff like Boolean, which is, of course, predefined in Ada. Odd that you would find it necessary to invent Boolean yourself, since one of the criticisms people make of Ada is that it has too many "unecessary" features. Apparently Boolean is not one of them. 4) While it is laudable that you invented an assertion mechanism, this is not necessary in my example because I can use Ada's exception mechanism. Apparently exceptions are ALSO not an "unecessary" feature. 5) You have this stuff about PUBLIC and PRIVATE functions. While I find this confusing enough that I'm not sure I understand it, I BELIEVE what you are doing is inventing some sort of crude form of visibility control. As with Boolean and exceptions, this is predefined in Ada. Yet another "unecessary" feature? 6) You check if the day < 1. I don't have to do this, since the language understands constraint violations inherently. AGAIN, I suppose, an "unecessary" feature? Now, for your comments: >] for Current_Month in January .. Month'Pred (This_Month) loop > I do not understand *exactly* what this means, although I can glean that >we are looping through months. The "Month'Pred (This_Month)" does not make >sense to me. To me, this is much more readable: >while(monthCount < month-1) Uh, except that if your Month is January, it should BLOW UP, since there is no legal value for January - 1. You'll probably get away with this in C, but it's nothing to brag about. I believe the trade name for this is a "bug". You might want to write a test driver that does more than test a single middle-of-the-road-condition as is the case with your current test driver: I suggest checking boundary conditions such as the first day of the first month, etc. I did this with mine and it works just fine. With yours if C had anything approaching real constraint checking you'd fall over dead. > Also, Jim does not clearly separate functions: [package body code deleted] > This looks messy to me. There is no clear distinction (other than the > keywords function, begin and end) as to where one function ends, and another > begins. That's because that's all that is needed. The keywords are completely deterministic: when you see the word "function", you know you're starting the next function. Simple, non-wordy, accurate. > Jim, might I (a lowly C programmer) be so bold as to suggest > an improvement for the readability of your Ada code? How about if you > put a nice comment block before each function: How about if I don't? The use of comment blocks serves only to redundantly paraphrase what is already there, in the typical case. Consider your example: #>-- --------------------------------------------------------------------------- #>-- #>-- FUNCTION: Is_Leap_Year() #>-- #>-- PURPOSE: To Determine if a given year is a leap year. #>-- #>-- RETURNS: true if year is leap year, false if not #>-- --------------------------------------------------------------------------- #>] function Is_Leap_Year (This_Year : in Year) return Boolean is #>] #>] -- A leap year is any year evenly divisible by 4 that is #>] -- not also evenly divisible by 400. #>] #>] begin #>] return (This_Year mod 4 = 0) and not (This_Year mod 400 = 0); #>] end Is_Leap_Year; #>] You have added no value and several lines with your proposed comment block. That the function returns True or False is obvious from the return value (that's what it's THERE for). That the function determines whether or not the given year is a leap year is obvious from the NAME of the damned thing (that's why I chose the name I did). And that the function is a function and is called Is_Leap_Year is obvious too. Indeed, there is nothing in your comment block that could not be programmatically derived from the existing Ada construct, which makes it COMPLETELY trivial (at least if there were some additional comments about the definition of a leap year, etc, there might be SOME value added--but the only non-derivable comment is the one I had already put there). The only time you should add comments is when the information they contain is not already obvious. This is in keeping with the principal of Minimal Noise. Of course, this is less an Ada/C issue than a commenting issue. >(If I were an Ada programmer > I would probably embelish the following comment blocks) No, you wouldn't--because most Ada style guides discourage such things. > Also, a comment indicating what if an >end if; statement terminates might help (just in case Jim writes if elsif, >endif blocks (or whatever you call them in Ada) that are longer. Again, this is superfluous. Ada, by design, has a "comb-like" structure: you can tell immediately from lexical level which construct you're dealing with and, because if/then/elseif/else/end-if constructs do NOT suffer from the dangling else problem of C, the matching up of an end with a begin is strictly deterministic. Besides which, if you add these comments to ends of ifs and then change the conditional on the if, the comment needs to be changed in concert. This is in violation of the principle of Single Point of Maintenance (by the way, your comment blocks are a similar violation of this principle). Or have you never noticed that comments and their associated code tend to wind up bearing no resemblance to each other? > Lastly, note that I am not an anti-Ada bigot. (Clearly, Jim is an anit-C >bigot). Note the tone from one of Jim's earlier postings: A bigot is one who is prejudiced. Prejudice is the formation of opinions prior to or in absence of the facts. I worked in C for years and years: my opinions towards it were formed AFTER I had the facts in hand. Thus I am not prejudiced, merely experienced. And thus I am not a bigot. >Actually, I think Ada has quite a few nice features that C lacks. >Personally though Ada is much too wordy for me. Which is of course why your example is three times longer than mine. >On the *average* Joe Blow's Ada code is *probably* more readable than Jim >Blow's C code. No argument. -- * The opinions expressed herein are my own, except in the realm of software * * engineering, in which case I borrowed them from incredibly smart people. * * * * Rational: cutting-edge software engineering technology and services. *