Re: AWS Coding Styles (and about boring plain-linear text files in the end)

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Le Wed, 19 Jan 2011 01:47:33 +0100, Georg Bauhaus  
<rm-host.bauhaus@maps.futureapps.de> a écrit:
> 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.
So this turn to be a suggestion about the good way to name program  
elements ? If a name is natural enough, it appears similarly naturally in  
comments and is less likely to be changed, so less likely to become a  
matter about broken sync between comment and source.

By the way, to talk about these particular identifiers, the File_Name vs  
Path is troublesome to me. From source to source in multiple places, the  
definition of a file name seems to vary: sometime the file base name +  
file extension, without directory, sometime the directory to which is  
appended the file base name and extension. I feel this should always be  
file base name + extension without directory, so that you may have  
Directory_Name the same way there may be File_Name, and Entry_Name when  
the type is unknown (either file or directory).

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]