Azayaka
Allelujah
Administrator
LEVEL 55
16 XP
In my recent studies, I've been asked to study coding standards for CPP. I know this may not be news to some of you and that's ok. My intention is to share and get feedback from anyone who is willing to contribute.
I may have some of this wrong and it may not be robust enough to fully understand. And so I would encourage you to explore and research on your own.
Let me know, did you like this? Did you find this helpful or useful? Thanks!
I may have some of this wrong and it may not be robust enough to fully understand. And so I would encourage you to explore and research on your own.
ERR50-CPP: Do not abruptly terminate the program
Abrupt termination using functions like std::abort(), std::quick_exit(), or std::_Exit() bypasses normal program cleanup procedures. This can lead to:
- Resource leaks: Unclosed files, network connections, or memory allocations.
- Data corruption: Inconsistent state due to unfinished operations.
- Security vulnerabilities: Potential exposure of sensitive information.
- Unexpected behavior: Other parts of the program might rely on proper termination.
ERR51-CPP: Handle all exceptions
Unhandled exceptions can lead to program crashes. It's essential to catch and handle exceptions appropriately to prevent unexpected termination.
- Use try-catch blocks to encapsulate code that might throw exceptions.
- Provide meaningful error messages to help with debugging and troubleshooting.
- Consider rethrowing exceptions if you can't handle them at the current level.
ERR52-CPP: Do not use setjmp() or longjmp()
These functions offer non-local jumps, which can make code harder to understand and maintain. They can also lead to undefined behavior in certain situations.
- Prefer try-catch blocks for structured exception handling.
- Consider using alternative mechanisms like error codes or return values for non-exceptional control flow.
ERR53-CPP: Do not reference base classes or class data members in a constructor or destructor function-try-block handler
Accessing base classes or class data members within a constructor or destructor's try-block handler can lead to undefined behavior due to the object's incomplete state.
- Avoid accessing members within these blocks.
- Consider using initialization lists or member initialization to initialize members before the constructor body.
ERR54-CPP: Catch handlers should order their parameter types from most derived to least derived
Properly ordering catch handlers ensures that the most specific exception is caught first. This prevents unintended behavior and allows for more precise error handling.
- List derived exception types before base exception types.
- Use std::exception as a final catch-all for unexpected exceptions.
ERR55-CPP: Honor exception specifications
Exception specifications declare which exceptions a function can throw. Adhering to these specifications improves code clarity and enables compiler optimizations.
- Avoid throwing exceptions not listed in the specification.
- Use noexcept if a function never throws.
ERR56-CPP: Guarantee exception safety
Exception safety ensures that program invariants are preserved even in the face of exceptions. It prevents resource leaks, data corruption, and inconsistent state.
- Use RAII (Resource Acquisition Is Initialization) to manage resources automatically.
- Consider copy-on-write semantics for complex objects.
- Employ the copy and swap idiom for strong exception safety.
ERR57-CPP: Do not leak resources when handling exceptions
Resource leaks can occur when exceptions are thrown before resources are properly released.
- Use RAII to automatically manage resources.
- Consider using smart pointers for automatic memory management.
- Explicitly release resources in destructors or exception handlers if necessary.
ERR58-CPP: Handle all exceptions thrown before main() begins executing
Exceptions thrown before main() can lead to unexpected program termination.
- Use std::set_terminate to install a custom termination handler.
- Consider using atexit to register cleanup functions.
ERR59-CPP: Do not throw an exception across execution boundaries
Throwing exceptions across thread or process boundaries can lead to undefined behavior and difficulties in handling exceptions.
- Use error codes or return values for inter-thread/process communication.
- Consider asynchronous exception handling mechanisms if necessary.
ERR60-CPP: Exception objects must be nothrow copy constructible
Exception objects must be copyable without throwing exceptions to ensure proper exception handling.
- Define a copy constructor for exception classes.
- Avoid throwing exceptions in the copy constructor.
ERR61-CPP: Catch by reference
Catching exceptions by reference avoids unnecessary object copying.
- Prefer catch (const std::exception& e) over catch (std::exception e).
- Consider using const references to prevent accidental modifications.
ERR62-CPP: Detect errors when converting a string to a number
Converting strings to numbers can lead to errors like invalid input, out-of-range values, or format exceptions.
- Check for conversion errors using functions like std::stoi, std::stod, or formatted input streams.
- Handle errors gracefully to prevent program crashes.
Let me know, did you like this? Did you find this helpful or useful? Thanks!