Some quick shots
ValidateBufferArgs() is not needed, because the
Buffer.BlockCopy()method will handle these cases in the same manner. In addition, why do you call theValidtaeBufferArgs()method before you check forif (!bIsOpen_m)inside theWrite()method ?the naming of your member variables is well strange. First you are using hungarian notation which is an anti pattern if it is used this way. There are ways how this could be acceptable but not like this
private bool bIsOpen_m; indicating by the b prefix that it is a bool.
Next, you postfix the member variables with a _m and you always use this. with them. If you pre- or postfix the variables with either m_ or _m than there is no need to use this..
- you have many places where it is obvious what type you are assigning by checking the right side of the assignment. In such cases you should use the
vartype and let the compiler determine the correct type.
byte[] newBuffer = new byte[count];
would e.g become
var newBuffer = new byte[count];
- IDisposable
Please read: proper-use-of-the-idisposable-interface
If the user calls Dispose() on your object, then everything has been cleaned up. Later on, when the garbage collector comes along and calls Finalize, it will then call Dispose again.
Not only is this wasteful, but if your object has junk references to objects you already disposed of from the last call to Dispose(), you'll try to dispose them again!
- Regions
Please read are-regions-an-antipattern-or-code-smell
Is there a good use for regions?
No. There was a legacy use: generated code. Still, code generation tools just have to use partial classes instead. If C# has regions support, it's mostly because this legacy use, and because now that too many people used regions in their code, it would be impossible to remove them without breaking existent codebases.
Think about it as about goto. The fact that the language or the IDE supports a feature doesn't mean that it should be used daily. StyleCop SA1124 rule is clear: you should not use regions. Never.