[asterisk-scf-dev] Proposed Naming Conventions

[David M. Lee]

On Nov 21, 2011, at 4:34 PM, Mark Michelson wrote:

> 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.

Renaming the repositories on the server would make it impractical to rebuild older versions, since the only way to build currently is with integrated builds.  Pre-rename revisions of the gitall script will no longer work, since they refer to repos that no longer exist.  And rolling back to pre-rename will not only involve the git trickery to checkout at a particular timestamp, but also include renaming local repositories to match whatever they were pre-rename.

This may not be important since we're in pre-beta, but demonstrates that it will be important document the decision on the wiki and enforce consistency.

I wonder if a non-integrated build would have been more flexible.  Then they would/could be built independently, and individual repository names wouldn't matter.  You still have to checkout each repo to the revision you wish to build, but at least you wouldn't have to worry about how the repositories are named on the local system.

> 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.

No objections, just the comments I stated above.

> Mark Michelson
> 
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> To UNSUBSCRIBE or update options visit:
>  http://lists.digium.com/mailman/listinfo/asterisk-scf-dev

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