Why not to use Java/MFC/etc convention m_ instead of more arbitrary sounding 'the'? m_ is de facto standard what it comes to the prefixes. (besides, at least I definitely find m_ more descriptive than arbitrary sounding 'the')
About method names.. How do you find this kind of rule with Accessor names: If a method has no arguments, the name should be a simple noun. For example size() instead of getSize(). BUT the method should have verb get prefix if the method has arguments. For example getBytes(byte* buffer). This rule goes pretty much one-to-one with conventions used in Java libraries.
Anyway, great effort! :) C++ community definitely would need consistent coding conventions. (among other things...)
Regards,
Jani Kajala
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The decision for the member name was based in standards and practices for OO development dating back a decade. This is a split hairs argument, so we won't have one :)
We are more and more leaning on our reflective capabilities in the frameworks. "get" and "set" will be standard interface prefixes based on accessors and mutators.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
Why not to use Java/MFC/etc convention m_ instead of more arbitrary sounding 'the'? m_ is de facto standard what it comes to the prefixes. (besides, at least I definitely find m_ more descriptive than arbitrary sounding 'the')
About method names.. How do you find this kind of rule with Accessor names: If a method has no arguments, the name should be a simple noun. For example size() instead of getSize(). BUT the method should have verb get prefix if the method has arguments. For example getBytes(byte* buffer). This rule goes pretty much one-to-one with conventions used in Java libraries.
Anyway, great effort! :) C++ community definitely would need consistent coding conventions. (among other things...)
Regards,
Jani Kajala
The decision for the member name was based in standards and practices for OO development dating back a decade. This is a split hairs argument, so we won't have one :)
We are more and more leaning on our reflective capabilities in the frameworks. "get" and "set" will be standard interface prefixes based on accessors and mutators.