Discussion Thread: DIP 1030--Named Arguments--Final Review

[Steven Schveighoffer]

On 5/13/20 9:34 AM, Paul Backus wrote:
> On Wednesday, 13 May 2020 at 12:15:38 UTC, Steven Schveighoffer wrote:
>> On 5/13/20 4:17 AM, Jacob Carlborg wrote:
>>> On 2020-05-12 08:22, Jonathan Marler wrote:
>>> Also, we should avoiding having short, abbreviated symbol names (any 
>>> kind of symbol names, not just parameter names). Although it's worse 
>>> to have abbreviated names which are part of the API or show up in 
>>> generated documentation. There are always exceptions, like when 
>>> abbreviated name is more known and common than the actual full name. 
>>> Examples are: HTTP, FTP and so on.
>>
>> HTTP and FTP are acronyms, which in my opinion ARE the full names.
>>
>> Abbreviations are fine when the abbreviation is unambiguous, like src 
>> and dest.
> 
> Even with such unambiguous abbreviations, the programmer still has to 
> keep track of (a) which words are abbreviated and which are spelled out 
> ("is it `source` or `src`?"), and (b) which abbreviations are used for 
> words with multiple possibilities (e.g., "is it `dest` or `dst`?"). 
> Spelling everything out means you never have to think about this stuff 
> at all--there's always exactly one obvious, correct choice.

If it's always abbreviated (in a certain project, for instance), then 
it's obvious, even as an abbreviation. What you shouldn't have is a 
project with functions that have `dest` and `dst`.

You are not going to ever get global consensus for every project on 
every name. What I was saying is, intra-project consistency is more 
important than forbidding abbreviations. Even when abbreviations are not 
allowed, you can have different spellings (is it `color` or `colour`?)

Naming conventions for parameters really should just look to naming 
conventions for functions for guidance I think. Many of the same rules 
apply.

-Steve