C++三则
这是在上周review代码时注意到的三点,感觉有些意思,不妨记录下来。
如无必要,勿增虚函数
比如我们有以下关于球的类层次设计 ,其中需要判断某种球是否是可以踢的(kickable):1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | class Ball { public : virtual bool IsKickable() = 0; }; class Football { public : virtual bool IsKickable() {returntrue;} }; class Basketball { public : virtual bool IsKickable() {returnfalse;} }; |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | class Ball { public : bool IsKickable(){ return m_bIsKickable;} protected : bool m_bIsKickable; }; class Football { public : Football():bIsKickable( true ){} }; class Basketball { public : Basketball():bIsKickable( false ){} }; |
类似这样的设计我碰到过至少两次,一次是被review,一次是review,结果都是改成了第二种我们认为比较合理的方式。
不要用 "||" 做复杂的逻辑判断
"||"是"或运算"符号,当你确实将其作为或运算时,的确很简单明了。但是有人发明了一种比较tricky的方法来使用它。举个例子,我们的程序可能有三种状态:A, B,或者C,现在有一个变量bOk,如果程序当前状态为C的话,bOk必须为true,如何来assert? 一般比较直观的做法是:1 | if (IsC()) assert (bOk); |
1 | assert (IsA() || IsB() || bOk); |
我们一般不推荐用这种不直观的方式来做判断。
纯虚函数与默认实现
有一个基类,我们期望它是一个抽象类,但同时我们又期望其虚函数都有默认实现。这其实一个语法层面的问题:我们是可以把一个虚函数设为纯虚的同时提供默认实现的。(但一开始以为不行,想去把构造函数设为pretected来达到类似的效果,但这样从概念上来讲就不是很合理了)对于这种情况,我想也没必要把所有函数设为纯虚,找一个典型,如把析构函数设为纯虚并提供默认实现:1 2 3 4 5 6 7 8 9 10 11 | class Base { public : virtual ~Base() =0; }; Base::~Base() { printf ( "~Base()\n" );} class Derive: public Base { public : virtual ~Derive(){ printf ( "~Derive()\n" );} } |
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 如何编写易于单元测试的代码
· 10年+ .NET Coder 心语,封装的思维:从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
· 周边上新:园子的第一款马克杯温暖上架
· Open-Sora 2.0 重磅开源!
· 分享 3 个 .NET 开源的文件压缩处理库,助力快速实现文件压缩解压功能!
· Ollama——大语言模型本地部署的极速利器
· [AI/GPT/综述] AI Agent的设计模式综述