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-Thread: 103376,429176cb92b1b825
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news3.google.com!proxad.net!feeder1-2.proxad.net!194.25.134.126.MISMATCH!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Wed, 19 Jan 2011 01:47:33 +0100
From: Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.2.13) Gecko/20101129 Thunderbird/3.1.7
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: AWS Coding Styles (and about boring plain-linear text files in
 the end)
References: <op.vpfsjkfdule2fv@garhos>
	<24418fa4-8843-4fe6-8c2f-026ea6009b68@g26g2000vbz.googlegroups.com>
 <87lj2ido9j.fsf@mid.deneb.enyo.de> <4D35F6C8.2060100@obry.net>
 <4d3608ab$0$7664$9b4e6d93@newsspool1.arcor-online.net>
 <ih539t$7e4$1@munin.nbi.dk>
In-Reply-To: <ih539t$7e4$1@munin.nbi.dk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <4d3634a5$0$7664$9b4e6d93@newsspool1.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 19 Jan 2011 01:47:34 CET
NNTP-Posting-Host: fa17e0c0.newsspool1.arcor-online.net
X-Trace: 
 DXC=:<2o42@]gQTcHPTNZh_e7Qic==]BZ:af^4Fo<]lROoRQ<`=YMgDjhgRDb>jfmWVF0[PCY\c7>ejVXYUcQ_Y3?jUQScZFh`5MJcR
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news2.google.com comp.lang.ada:17510
Date: 2011-01-19T01:47:34+01:00
List-Id: <comp.lang.ada>

On 1/18/11 11:13 PM, Randy Brukardt wrote:
> "Georg Bauhaus"<rm.dash-bauhaus@futureapps.de>  wrote in message
> news:4d3608ab$0$7664$9b4e6d93@newsspool1.arcor-online.net...
>> On 18.01.11 21:23, Pascal Obry wrote:
>>>
>>> Florian,
>>>
>>>> The problem is that the rule is self-contradictory.  I think it should
>>>> say, "should not specifically mention", i.e., the opposite of what you
>>>> suggested.
>>>
>>> No, it is definitely "should specifically mention". We are talking about
>>> the formal name here. Please reread my response to Yannick about this
>>> one.

> [...] Indeed, I still have no idea what the second sentence of
> that style section is supposed to mean. I thought it meant the exact
> opposite of the first sentence (with which I agree wholeheartedly) -- the
> only way *not* to depend on the names is to not include them in the text.
> I'd probably suggest dropping it altogether -- I have no idea how to write a
> useful comment that doesn't depend on the names of things.
>
> Perhaps the point was that there always should be a comment (rather than
> expecting the name of the parameters to serve in place of a comment) -- in
> that case, the text needs to emphasize the need for comments rather than the
> reason for omitting them.

My guess was similar.  When names will need to be changed,
the comments can otherwise stay intact:

    procedure Call (Filename : String);
    --  Filename must be an abosulute name

becomes

    procedure Call (Path : String);
    --  Path must be an abosulute name

(I am not suggesting that Path is better than Filename.)
However, when the name becomes "Frmbloo", as in

    procedure Call (Frmbloo : String);
    --  Frmbloo must be an abosulute name

the comment shows that it does depend on the names of things:
The "file" part has gone missing, leaving a blank that the reader
cannot fill in by inference from either the name or from the comment.
What is a Frmbloo?

The comment specifically mentions the formal argument name,
as should be.  However, the comment does depend on the name of
things.