2. www.luxoft.com
Content
• Where to store the code ?
• How can I build my code ?
• What if I need third party library?
• How can handle the style ?
• How to reduce amount of bugs in compile time ?
• How to reduce amount of bugs before testing ?
• How to maintain that my changes does not breaks anything ?
• How can I do my code better?
7. www.luxoft.com
How to reduce amount of bugs in compile time?
• Think what you write
• Use maximum warnings level
• Warning is an error!
• Use static analyses:
PVS studio
Clang static analyzer
Coverity
Cppcheck
…
9. www.luxoft.com
How to maintain that my changes does not breaks anything?
• Jenkins
• Travis
• Drone.io
• AppVeyor
• TeamCity
• GitLab
10. www.luxoft.com
How can I do my code better?
• Follow the guidelines!
• Think what you write!
• Perform refactoring
• Perform code review
• Learn other programming languages
• Read the good code
• Listen to smart guys
11. www.luxoft.com
Keep you code safety
• Const as Much as Possible
• Avoid Raw Memory Access
• Use std lib containers
• Make errors explicit
• Use asserts as much as possible
• Compile time error is cheaper!
• Keep you code type safety
• Be aware of incapacitation
12. www.luxoft.com
Keep you code maintainable
• Avoid macros
• Avoid multiple inheritance
• Simple is better then complex
• Complex is better then complicated
• Use all of you variables
• Do not ignore return value
• Use override, final keywords
• ...
13. www.luxoft.com
Be aware of performance issues
• Avoid use any kind smart pointers if stack variable is possible
• Singleton's have more drawbacks then benefits
• Know your threads. Avoid a lot of threads
• Use forward declaration when it is possible
• Use templates if it is possible, but keep balance
• Analyze your build process and dependencies
• Reduce temporary objects
• Use moving semantic and unique pointers
• Limit scopes of variables
14. www.luxoft.com
Learn and use Cpp core Guidelines
• P.1: Express ideas directly in code
• P.2: Write in ISO Standard C++
• P.3: Express intent
• P.4: Ideally, a program should be statically type safe
• P.5: Prefer compile-time checking to run-time checking
• P.6: What cannot be checked at compile time should be checkable at run time
• P.7: Catch run-time errors early
• P.8: Don’t leak any resources
• P.9: Don’t waste time or space
• P.10: Prefer immutable data to mutable data
• P.11: Encapsulate messy constructs, rather than spreading through the code
• P.12: Use supporting tools as appropriate
• P.13: Use support libraries as appropriate