💻 代码思考

    💻 代码思考 存在多个指针类型 out 函数参数,特别小心的是当其中一个out参数取值错误,其他out参数的赋值情况。

    比如

    TestOutClass* out1 = nullptr;
    TestOutClass2* out2 = nullptr;
    bool Getxxx(TestOutClass** ptr, TestOutClass2** ptr2){
    xxx
    }
    auto ret = Getxxx(&out1, &out2);

    当返回值为false的时候,理论上out1 和 out1 仍然是nullptr,外部不需要释放任何资源。

    因此在 Getxxx 函数内部实现的时候,可能会出现ptr 赋值成功,ptr2 赋值失败,此时返回值为false,导致外部没有意识到需要释放out1 的空间导致内存泄露。因此在内部实现的时候,应该等ptr 和ptr2 的内容都获取到后,再给两个指针赋值。

    💻 代码思考 好的注释应该是解释性语言,而不是动作性语言。具体例子:

      // |json_file_path_| is the path of a file that will be source of the
      // deserialization. |options| is a bitmask of JSONParserOptions.
      explicit JSONFileValueDeserializer(
          const base::FilePath& json_file_path,
          int options = base::JSON_PARSE_CHROMIUM_EXTENSIONS);

    上面代码是chromium base 库中关于json 解析工具的注释,它解释了两个参数的作用。

    一个不好的写法如下,对参数的注释是这个函数在做什么,而不是参数本身的说明:

    // We parse the file with the |json_file_path| path, passing in the 
    // bitmask of  JSONParserOptionstype |options| in the process
     explicit JSONFileValueDeserializer(
          const base::FilePath& json_file_path,
          int options = base::JSON_PARSE_CHROMIUM_EXTENSIONS);

    💻 代码思考 以往工作中常用的设计模式只有代理模式、观察者两种,似乎不太需要太复杂的设计模式。这一周工作主要是重构了之前写的一部分代码来支持更通用化的需求。因为这个需求中设计到很多状态的转换,每个状态都会有几个分支,尝试了状态设计模式,设计状态,设计每个状态会执行的动作,设计每个状态执行相应动作应该转移到的下一个状态以及副作用行为。Xstate 项目的可视化非常方便提前先构建好整个状态机的模型。

    写完之后,能很明显的感觉代码思路清晰很多。之前是在很多基础模块中去判断状态,然后进行对应的行为,这次所有的状态管理全部收敛到一个controller中,状态的转移过程对外是不可见的,外部基础模块只要调用controller的对应动作方法,controller会将工作委托给对应的状态处理。不再需要像之前那样,先获取当前状态,再判断当前状态,最后执行某个行为转移到新的状态。

    同时一个独立的功能需求的代码设计是不应该嵌入到一些基础类型的模块中的,而是应该写一个controller,将需要使用的基础模块作为该controller的成员指针来使用。

    💼 从工作中学到的 💻 代码思考在正式工作之前,我没有写过单测,主要是平时自己写的代码通常耦合度较高,没有单独抽象设计模块的概念。

    最近开始写一些通用能力的基础库需要写单测。第一次单测的编写是在代码基本完成后开始写的,完成单测后会发现一些bug,于是修改bug。但这个过程中会发现代码设计的一些不合理之处,比如多个接口的返回值是否更统一,对于接口可能出现错误时的返回值,应该如何处理(这个可以多参考chromium base库中的代码实现)。如果一个模块的多个接口设计不统一、那么单测同样也会非常复杂。

    其实上面的过程就有点TDD那味了,但是测试驱动开发,需要先写一个无法通过的测试,通过修改代码来使得测试通过,再重构代码。在这个过程中不断的开发代码,而不是先写完代码,再写单测试。

    单测的重要性是毋庸置疑,因为代码复杂性总可能出现某个分支逻辑错误。因此TDD将单测与开发结合,减轻了写单测的难度和压力,同时也能通过单测进一步发现代码的设计问题。

    参考文章:

联系方式

关于我

  • 来自南部的一个小城市,个性不张扬,讨厌随波逐流。

那年今日
2 月前

📝 每日记录 今天我终于给住的房子安装了宽带!每个周末看看视频都会非常卡... 更不用说拉个代码...装了200Mbps的联通宽带,应该也够用了。同时还发现了移动宽带为什么这么便宜,不知道有没有了解的这块的。联通200Mbps一年就需要800多,而移动500Mbps/100Mbps甚至价格只有400-500元一年,不太可相信的样子。从网上了解到似乎移动的网络不是很稳定...今天请了病假,上午去医院检查,医生看了周一拍的CT,结论是:肺部没有什么问题,建议多休息... 如果不放心可以去心血管科再查查。但是不想抽血了,今天就没有继续看。🎬 观影 晚上看完了电影《海边的曼彻斯特》。老实说,很久很久没有耐心看完一部电影,大概几个月这么久吧。有点喜欢男主波澜不惊的说话方式。冷静的背后自有千钧之力。看完全片,没有感受太多的悲伤或者是别的感情,只是看完了一个故事,一个纪录片似的。

7 月前

💼 从工作中学到的 写文档和设计代码有一些相似之处。一个比较复杂的话题想要展开,就好比设计一个复杂功能的类。全部代码写在一个文件中当然可以,就会导致单文件代码行数太多,阅读起来很费劲。如果我们能更好的封装与模块化代码,单个类的功能就会更清晰。同理,写一篇复杂话题的文章,也可以有类设计的思想,先介绍最基础的部分,然后基于这个基础会有多个分支展开(子类继承)。多篇文章之间环环相扣,而每篇文章也不会太长,阅读压力也不大。我也看到过有很长文章从头到尾讲一个复杂话题的,写的也特别的好,这个就好比仍然是多个类,只不过放到同一个文件里面而已。

8 月前

📝 每日记录 春节结束!整个7天,基本上就是纯休息,睡觉时间基本上是平时的1.5倍还多... 年终总结都还没有写完∠( ᐛ 」∠)_ 好好休息完,开始新的一年啦!

9 月前

📝 每日记录 第二次租房又被坑了,又贵又坑,被中介给忽悠了。租之前,中介说,这个房源靠近大学,都是有素质的人。相邻房间的是个”小男生”,门对面是“小情侣”,平时也没什么声音。我看房的时候就问原住户,平时有没有声音。原住户愣了一下,说没有。今天上午快到中午时候,隔壁开始弹钢琴,下午快到傍晚有开始吹笛子。对面小情侣晚上回来之后,这个门开关开关不只10次,而且每次开关声音不仅大,而且风把我的房门都刮的很大声响(因为这个门关的不是严丝合缝,而且门的质量很差)。他们住的房子也是独卫,而且这个房源没有客厅,只有一个厨房,根本想不明白他们进进出出到底是在干什么... 晚上又说话声音特别大,隔着一个卫生间都能听到。还有楼上,不定时的拖桌子声....相邻的房间 有两次早上听到对方的打呼的声音….再坚持到明年7月份合同到期一定搬走!就是心疼中介费,从此再也不相信中介半个字,他们根本对住户不了解,也对噪音不了解。签了合同,找他们也没用,问他们就让你找房管。下次租房再也不要让我看到情侣!!!!!!!!!我第一次租的公寓房,隔壁就是情侣,然后第二天就吵的我受不了换了房。但这次本来想是门对面就还好,哎,抱有侥幸心理了。

13 月前

自从工作搬到这个小区,每天两点一线,早上从北门出,晚上从北门进,基本没去过小区的其他的地方,今天找充电桩才知道小区里有一个小公园,有一些简单的设施,我所住的公寓楼的背后就是民房,生活气息更足,小孩子、老人在公园慢慢悠悠玩耍,感觉是应该每天抽空去外面转转,让内心也去浸染一些生活的味道。

18 月前

玉米淀粉与红薯淀粉的区别就和老抽与生抽的差别一样大...

20 月前

此条为私密说说,仅发布者可见