Size: 2383
Comment:
|
Size: 4642
Comment:
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
== Directories == === Library only === * Put library files in .../components/<library name> * Put unit test files in .../components/<library name>/test * Generate libcl<library name>.so and .a * Put ALL AND ONLY ALL library .o files in $(MWOBJ_DIR) for eventual link into libmw.so & libmw.a * Put non-library .o files in $(OBJ_DIR) === Client/Server === * Put client library files in .../components/<library name> * Put unit test files in .../components/<library name>/test * Put server files in .../components/<library name>/server * Put files common to client library and server in .../components/<library name>/common But common files still get linked into libcl<library name>.so and .a * Generate libcl<library name>.so and .a * Put all and ONLY ALL library .o files in $(MWOBJ_DIR) for eventual link into libmw.so & libmw.a * Put non-library .o files in $(OBJ_DIR) |
|
Line 3: | Line 28: |
* Use .hxx and .cxx, prefix all header files with "cl" | * Use .hxx and .cxx and prefix all header files with "cl". ''example:'' clTransaction.hxx, transaction.cxx * Use bumpyCase for file names, with first character lowercase. |
Line 5: | Line 32: |
examples: ''clLogApi.hxx'', ''clCkptApi.hxx'' '''An application only needs to include these files (they must include other required header files)!''' |
''examples:'' ''clLogApi.hxx'', ''clCkptApi.hxx'' '''An application only needs to include these files'''. These files must include any other required header files. |
Line 8: | Line 36: |
examples: ''clTransaction.hxx'' '''An application MAY include these files if it wants that specific functionality''' |
''examples:'' ''clTransaction.hxx'' '''An application MAY include these files''' if it wants that specific functionality. |
Line 11: | Line 40: |
examples: ''clCkptIpi.hxx'' | ''examples:'' ''clCkptIpi.hxx'' |
Line 17: | Line 47: |
{{{#!highlight cpp | {{{#!highlight cpp |
Line 39: | Line 69: |
{{{#!highlight cpp | {{{#!highlight cpp |
Line 49: | Line 79: |
* Do not hide implementation using Handles. Expose them via pointers or containment. This makes debugging much simpler and its easy enough just to skip over tracing through the implementation if needed. * Also, prefer containment; do not use pointers rather than containment just to hide implementation. clSvcIpi.hxx {{{#!highlight cpp |
* Do not hide implementation using handles. Expose them via pointers or containment. This makes debugging much simpler and its easy enough just to skip over tracing through the implementation if needed. Also, prefer containment; do not use pointers rather than containment just to hide implementation. ''Example:'' clSvcIpi.hxx {{{#!highlight cpp |
Line 65: | Line 96: |
clSvcApi.hxx {{{#!highlight cpp |
clSvcApi.hxx {{{#!highlight cpp |
Line 82: | Line 113: |
Line 84: | Line 114: |
'''''With pointers, predeclarations are preferred''''' {{{#!highlight cpp |
Note that in this case, the application will end up including the Ipi file. This is ok, it is clear by the namespace what is API and what is internal. ''Example:'' '''''With pointers, predeclarations are preferred''''' {{{#!highlight cpp |
Line 103: | Line 136: |
* Do not use "cl" prefix for class or variable declarations. A prefix is unnecessary because we are under the SAFplus namespace. * Classes should be defined using bumpy case, with a leading Capitalization. ''Example:'' MyClass, Checkpoint, * Prefer enums over #defines Enums are under the SAFplus namespace, macros are not. * Prefer inline functions over macros The only exception to this is when you need __FILE__ and __LINE__ macros * Constants should be all caps with underscores ''Example:'' LOG_SEV_EMERGENCY Constants can be actual enum constants, or other items that you want to be considered constant even if they are not. ''Example:'' const WellKnownHandle APP_LOG(2,0); |
|
Line 104: | Line 150: |
* Do not use "using namespace xxxx;" inside a header file. Doing so forces every cxx file that includes this header to be 'using' that namespace and therefore defeats the purpose of having 2 namespaces. |
Directories
Library only
- Put library files in
../components/<library name>
- Put unit test files in
../components/<library name>/test
Generate libcl<library name>.so and .a
Put ALL AND ONLY ALL library .o files in $(MWOBJ_DIR) for eventual link into libmw.so & libmw.a
- Put non-library .o files in $(OBJ_DIR)
Client/Server
- Put client library files in
../components/<library name>
- Put unit test files in
../components/<library name>/test
- Put server files in
../components/<library name>/server
- Put files common to client library and server in
../components/<library name>/common But common files still get linked into libcl<library name>.so and .a
Generate libcl<library name>.so and .a
Put all and ONLY ALL library .o files in $(MWOBJ_DIR) for eventual link into libmw.so & libmw.a
- Put non-library .o files in $(OBJ_DIR)
Files
- Use .hxx and .cxx and prefix all header files with "cl".
example: clTransaction.hxx, transaction.cxx
- Use bumpyCase for file names, with first character lowercase.
Name major functional blocks cl<FN>Api.hxx
examples: clLogApi.hxx, clCkptApi.hxx
An application only needs to include these files. These files must include any other required header files.
- Other files can be named based on the primary class defined inside
examples: clTransaction.hxx
An application MAY include these files if it wants that specific functionality.
Internal APIs should be named cl<something>Ipi.hxx
examples: clCkptIpi.hxx
These files may get pulled into application builds due to object containment. However, it must not be necessary for the application program to ever use symbols defined in the Ipi files.
Definitions
All application-level APIs must be defined under the SAFplus namespace:
All internal APIs must be defined under the SAFplusI namespace (I for internal):
- Do not hide implementation using handles.
- Expose them via pointers or containment. This makes debugging much simpler and its easy enough just to skip over tracing through the implementation if needed. Also, prefer containment; do not use pointers rather than containment just to hide implementation.
Example: clSvcIpi.hxx
clSvcApi.hxxNote that in this case, the application will end up including the Ipi file. This is ok, it is clear by the namespace what is API and what is internal.Example: With pointers, predeclarations are preferred
- Expose them via pointers or containment. This makes debugging much simpler and its easy enough just to skip over tracing through the implementation if needed. Also, prefer containment; do not use pointers rather than containment just to hide implementation.
- Do not use "cl" prefix for class or variable declarations.
- A prefix is unnecessary because we are under the SAFplus namespace.
- Classes should be defined using bumpy case, with a leading Capitalization.
Example: MyClass, Checkpoint,
- Prefer enums over #defines
- Enums are under the SAFplus namespace, macros are not.
- Prefer inline functions over macros
The only exception to this is when you need FILE and LINE macros
- Constants should be all caps with underscores
Example: LOG_SEV_EMERGENCY Constants can be actual enum constants, or other items that you want to be considered constant even if they are not.
Example: const WellKnownHandle APP_LOG(2,0);
- Do not use "using namespace xxxx;" inside a header file.
- Doing so forces every cxx file that includes this header to be 'using' that namespace and therefore defeats the purpose of having 2 namespaces.