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