Choose names that clearly reveal the purpose, behavior, or type of the code elements they represent. A good name should answer "what" rather than "how" and should be precise enough to avoid ambiguity.
Choose names that clearly reveal the purpose, behavior, or type of the code elements they represent. A good name should answer “what” rather than “how” and should be precise enough to avoid ambiguity.
For functions, choose names that indicate what they do or return:
// Less clear
inline bool is_float(const int dtype) {
// checks if dtype is any floating point type
}
// More clear
inline bool is_floating(const int dtype) {
// clearly indicates checking for any floating point type
}
For variables, use domain-specific terms that express their meaning:
// Less clear
const int strides_1 = floor((IH << 1) / OH) - floor(IH / OH);
const int strides_2 = floor((IW << 1) / OW) - floor(IW / OW);
// More clear
const int strides_H = floor((IH << 1) / OH) - floor(IH / OH);
const int strides_W = floor((IW << 1) / OW) - floor(IW / OW);
Use prefixes or qualifiers when name conflicts might occur:
// Potential conflict with mshadow::kInt8
enum QuantizeOutType { qAuto = 0, qInt8, qUint8 };
For configuration variables, be specific about what they control:
// Too generic
bool disable_fuse_all = dmlc::GetEnv("MXNET_DISABLE_ONEDNN_FUSE_ALL", false);
// More specific
bool disable_fuse_requantize = dmlc::GetEnv("MXNET_DISABLE_ONEDNN_FUSE_REQUANTIZE", false);
bool disable_fuse_dequantize = dmlc::GetEnv("MXNET_DISABLE_ONEDNN_FUSE_DEQUANTIZE", false);
Extract meaningful operations into well-named functions instead of using inline code blocks.
Enter the URL of a public GitHub repository