[asterisk-scf-dev] Proposed Naming Conventions

[Mark Michelson]

Per https://issues.asterisk.org/jira/browse/ASTSCF-292, I have been 
tasked with streamlining the naming convention for file, component, and 
repository names in Asterisk SCF. If you take a look at the issue, then 
you can see where some of the inconsistencies lie.

My proposal is the following:

1. All repository, file, non-component library, and component names will 
be in UpperCamelCase.

2. All Slice source files, regardless of whether they are defining 
interfaces or are listing classes, will end with "If".

3. All initialisms and acronyms that are typically written in all 
uppercase will be formatted as such (e.g. use "RTP" instead of "Rtp" and 
"PJMEDIA" instead of "PjMedia").

4. The C++ source file in each repo that defines the primary Icebox 
service will be called "Component.cpp". This holds true whether the 
service is defined as a subclass  of AsteriskSCF::Component::Component 
or the service is defined as a direct subclass of Icebox::Service. 
Similarly, if the component provides a state replicator, then the name 
of the source file should be "ComponentStateReplicator.cpp" and the name 
of the header file should be "ComponentStateReplicator.h".

5. The C++ header and source files that handle configuration of the 
component over Ice will be called "Configuration.h" and 
"Configuration.cpp" respectively.

6. Unless there is a compelling reason not to, the primary component 
provided by a repository will have the same name as the repository. The 
state replicator should have the same name as the primary component, 
with "StateReplicator" appended.

7. Where reasonable, a header file containing a primary class 
declaration should have the same name as the class being declared (i.e. 
class Foo should be declared in Foo.h).

8. Non-inlined definitions of a class's methods should be in a .cpp file 
named after the class (i.e. class Foo's methods that are not defined in 
Foo.h should be defined in Foo.cpp).

If there are objections to these guidelines or ideas for further 
guidelines, please make them known.

Mark Michelson