Changes between Version 11 and Version 12 of BestPracticeHandbook

Timestamp:

May 6, 2015, 11:41:57 PM (7 years ago)

Author:

Niall Douglas

Comment:

--

BestPracticeHandbook

@@ -27 +27 @@
 [[PageOutline]]
 
-== 1. PRACTICE: Strongly consider using git and [https://github.com/ GitHub] to host a copy of your library and its documentation ==
+== 1. CONVENIENCE: Strongly consider using git and [https://github.com/ GitHub] to host a copy of your library and its documentation ==
 
 There are many source code control systems, with subversion and CVS being the two most recently popular of yesteryear. Probably the current most popular source code control system is Git, and despite its (Mingw i.e. non-native) port on Microsoft Windows being a bit flaky, it is very useful once mastered.
@@ -90 +90 @@
 
 
-== 2. DESIGN: Strongly consider versioning your library's namespace using inline namespaces and requesting users to alias a versioned namespace instead of using it directly ==
+== 2. COUPLING: Strongly consider versioning your library's namespace using inline namespaces and requesting users to alias a versioned namespace instead of using it directly ==
 
 C++ 11 adds a new feature called inline namespaces which are far more powerful than they first appear:
@@ -390 +390 @@
 
 
-== 9. DESIGN: Consider breaking up your testing into per-commit CI testing, 24 hour soak testing, and parameter fuzz testing ==
+== 9. DESIGN/QUALITY: Consider breaking up your testing into per-commit CI testing, 24 hour soak testing, and parameter fuzz testing ==
 
 When a library is small, you can generally get away with running all tests per commit, and as that is easier that is usually what one does.
@@ -477 +477 @@
 
 
-== 11. QUALITY: Consider having Travis send your unit test code coverage results to Coveralls.io ==
-
-== 12. QUALITY: Consider creating a status dashboard for your library with everything you need to know showed in one place ==
-
-== 13. DESIGN: Consider enabling multiple versions of your library to coexist within the same translation unit ==
-
-== 14. DESIGN: Consider making (more) use of namespace composure as a design pattern ==
-
-
+== 11. CONVENIENCE: Consider having Travis send your unit test code coverage results to Coveralls.io ==
+
+== 12. CONVENIENCE: Consider creating a status dashboard for your library with everything you need to know shown in one place ==
+
+== 13. COUPLING: Consider enabling multiple versions of your (header only) library to coexist within the same translation unit ==
+
+== 14. DESIGN: Consider making (more) use of C++ 11 namespace composure as a design pattern ==
+
+== 15. FUTURE PROOFING: Consider using a precompiled header to feed your (multi-abi) library into your unit tests ==
+
+Good proxy for supporting C++ Modules down the road, usually a massive build time improvement too especially on low end CPUs.
+
+== 16. COUPLING: Consider allowing your library users to dependency inject your dependencies on other libraries ==
+
+== 17.
+
+== 18.
+
+== 19. FUTURE PROOFING: Consider being C++ resumable function ready ==
+
+Never block. Never call anything which blocks.
+
+Everything i/o async. Boost.Fiber.
+
+Automatic WinRT friendly.
+
+== 20. COUPLING/SOAPBOX: Essay about pros and cons of defaulting to standalone capable (Boost) C++ 11/14 libraries with no external dependencies ==
+
+monolithic vs modular
+git submodules vs biicode