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 Path: g2news1.google.com!news4.google.com!feeder.news-service.com!novso.com!nerim.net!oleane.net!oleane!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Operation can be dispatching in only one type Date: Fri, 4 Dec 2009 20:45:19 -0600 Organization: Jacob Sparre Andersen Message-ID: References: <025105f2-5571-400e-a66f-ef1c3dc9ef32@g27g2000yqn.googlegroups.com> <0f177771-381e-493b-92bb-28419dfbe4e6@k19g2000yqc.googlegroups.com> <1nbcfi99y0fkg.1h5ox2lj73okx$.dlg@40tude.net> <59acf311-3a4a-4eda-95a3-22272842305e@m16g2000yqc.googlegroups.com> <4b150869$0$6732$9b4e6d93@newsspool2.arcor-online.net> <18vlg095bomhd.8bp1o9yysctg$.dlg@40tude.net> <4b152ffe$0$7615$9b4e6d93@newsspool1.arcor-online.net> <19nhib6rmun1x$.13vgcbhlh0og9$.dlg@40tude.net> <4b1557d0$0$7623$9b4e6d93@newsspool1.arcor-online.net> <4b15bf2b$0$7623$9b4e6d93@newsspool1.arcor-online.net> <1jcbtmi5rztyp$.norvlhez9i9$.dlg@40tude.net> <4b179ffb$0$6591$9b4e6d93@newsspool3.arcor-online.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1259981121 23469 69.95.181.76 (5 Dec 2009 02:45:21 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Sat, 5 Dec 2009 02:45:21 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5843 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Xref: g2news1.google.com comp.lang.ada:8311 Date: 2009-12-04T20:45:19-06:00 List-Id: "Dmitry A. Kazakov" wrote in message news:qchmzfxola9n$.1owojhwd91cbc.dlg@40tude.net... > On Thu, 3 Dec 2009 17:08:01 -0600, Randy Brukardt wrote: > >> It should be noted that our local coding standard would consider the >> above >> incorrect; there always must be an else branch or at least a comment >> explaining why there is no else branch: > > What about: > > if Read_Error (File) then > raise Data_Error; > end if; I hardly ever write this. I looked at 15 units picked at random and found only a handful of raises, most of them in case statements. And some of the "if" statements have elses or elsifs anyway. But the couple of examples I did find, I did indeed violate the coding standard, because there is no need to describe the else case. The beginning of our coding standard says that it is guidelines, not something to be followed blindly, and adding noise comments surely would qualify. The one place where this is fairly common (the heading of Claw functions) would have been much better written as preconditions (which Ada 95 didn't have, of course): if not Is_Valid (Window) then raise Not_Valid_Error; end if; doesn't need any explanation, but it would be better to have it clearly in the spec rather than just in comments. Writing in Ada 2012 as proposed today (and that might change before it gets standardized): procedure Do_Something (Window : Claw.Basic_Window_Type; ...) with Pre => Is_Valid (Window); is surely better because it puts the check in the spec where the caller can see it, rather than in comments that can be ignored. (And it also opens up the possibility of tools/compilers warning when it is *not* true at the point of a call, both potentially eliminating generated code and making error detection earlier.) > or > > if Estimated_Error <= Threshold then > return Estimated_Result; > end if; This should always have an else comment, IMHO. In the example you have: if if Estimated_Error <= Threshold then return Estimated_Result; -- else continue iteration end if; because the fact that iteration is intentionally being continued is important. I always try to comment why and how loops are exited, because I find I can't figure it out easily when returning to the code in a year or five. > or "exit when", which is a hidden if without else. I also find that it is very rare that I can use "exit when". If I can, I would prefer to do so, as it doesn't need much commenting (continuation is obvious). But almost always I find that something needs to be done (usually to save the result of the iteration) before exiting for good, so I usually end up with an if statement: for I in Data'Range loop exit when Item = Buffer (I); end loop; -- Oops, we don't know where the item was found or *if* it was found, which was the point of the iteration. So instead: Found := Data'Last + 1; for I in Data'Range loop if Item = Buffer (I) then Found := I; exit; -- else keep looking end if; end loop; -- Found now tells us where the item was, or if it was absent. which is a pattern that seems to happen a lot in my programs. > Maybe "if" with two alternatives should better be "case". Though it would > look strange most of us: > > case Condition is > when True => > X := This; > when False => > X := That; > end case; That's not *that* weird; it's not unusual to find out that there are more than two possibilities and a case statement is often the best way to handle that. Anyway, this is my (and by extension, RR's) coding standard. YMMV. Randy.