[asterisk-scf-dev] Proposed Naming Conventions

[Joshua Colp]

----- Original Message -----
> 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").

+trillion

It throws me off every time I see this violated right now.
 
> 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).

Looks good to me.

-- 
Joshua Colp
Digium, Inc. | Developer of Software
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at:  www.digium.com  & www.asterisk.org