Naming conventions (Re: PR for adding RtpSender.transport)

On 06/21/2015 02:05 AM, Silvia Pfeiffer wrote:
> On Sun, Jun 21, 2015 at 6:41 AM, Bernard Aboba
> <Bernard.Aboba@microsoft.com> wrote:
>> On Jun 20, 2015, at 5:49 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
>>> The names should at least be correlated - as editor of the stats specification, I'm probably not the right one to decide which spec to suggest changes in; I'm too enamored of my own prose :-)
>> [BA] Yes, please!
>>
>> We actually have 3 sets of object names with slight differences - WebRTC 1.0, Stats API and ORTC. Having to track these different names for what appear to be the same things is quite painful.  For example, it is RTCDTMFSender in WebRTC 1.0 and RTCDtmfSender in ORTC.
>>
> FWIW I find RTCDtmfSender more readable.

We're living in a clash of two naming conventions with regard to use of
CamelCase and acronyms.

The Google C++ convention says to treat an acronym like a word, and
camelcase it (Dtmf, Html, Rtp, DomString).

The Blink C++ convention says to treat an acronym like a bunch of
letters, and capitalize it (DTMF, HTML, RTP, DOMString).

So far, the WebRTC spec has mostly followed the Blink convention (RTC).
Switching to the Google convention would be a major hassle, even though
I find it more readable a lot of the time.

Note: RTCDtmfSender, being a mixture, is not defensible under any of the
conventions.

Harald

Received on Sunday, 21 June 2015 05:31:05 UTC