专栏首页嵌入式学习编程中有哪些好习惯一开始就值得坚持?

编程中有哪些好习惯一开始就值得坚持?

给变量、函数取个好名字

ITWorld 曾经发起了一个“程序员最头疼的事情”投票,结果非常有趣,近半数的程序员认为命名是最头疼的事情。

规范的命名对于阅读程序是如此重要,本文开篇就不得不提到它。在阅读代码时,理解一个变量和函数都是从名字开始的。它是什么?它的职责是什么?这些问题从名字就应该看出来,如果名称需要注释来补充,那就不算是好名字。

例如:将变量名

修改为:

将函数名

修改为:

宁可名字取长一点,也不要起个模糊的名字。一个清楚的变量名还会带来可搜索的好处。即使在写二分算法时,也尽量别用"l"和"r"来指代左右边界,换成"left"和"right"会更好。

不过,变量名也并非越长越好,去除变量名中的冗余也是一个好习惯。Variable 一词永远不应当出现在变量名中,Table 一词永远不应当出现在表名中。 nameString 与 name 没区别,moneyAmount 与 money 没区别, customerInfo 与 customer 没区别, theMessage 也与 message 没区别。

命名风格应该保持统一,每个概念对应一个词。如果一堆代码中既有 Controller,又有 Manager,还有 Driver,Presenter,就会令人困惑:他们之间有什么区别?为什么不全用 Controller?如果同一概念可被多个词语描述,请确定其中一个名字,并在你的代码中一以贯之。

总之,取一个精准的名字是一名优秀程序员的基本功。从一开始学习编程时,每次取名都应仔细思考,切不可草草了事。

保持代码美观

感受一下两种格式的代码:

同样的代码,仅仅是加上空格与缩进就能看起来更美观。现代化的 IDE 都有代码格式化快捷键,在代码敲完后随时格式化,并去掉多余的空行,是一个让代码保持美观的好习惯。

先想通逻辑,再写代码

斐波那契程序员:每天都在修复昨天和前天的 bug

你是否有过这样的经历:代码删了又写,写了又删。在敲代码之前,先问自己一个问题:我写下的这行代码是真的能用上的吗?会不会有逻辑漏洞?思考清楚业务流程之后再写代码,往往事半功倍。

以笔者亲身经历过的一个项目为例,项目已经做了一年, 除了三方库,代码量共有两万行,平均算下来,开发者一年来每天只需要写 55 行代码。这样看来,开发者的每一天都差不多是“很闲的”,然而开发者每天都忙得不得了,从早到晚都在码代码。这些代码量如果纯粹敲出来,最多十个小时就可以完成。我们应该用大部分的时间思考代码逻辑,不要花大量时间将代码删了又写,写了又删。磨刀不误砍柴工,事先做好全面的考虑,争取让写下的每一行代码都有价值。

程序员的时间分配

梳理代码逻辑是有一定方法的,例如:

  • 通过画图工具先将逻辑画出来,流程图、UML 图、时序图、思维导图都能对你有所帮助。
  • 写接口之前先模拟出假数据,测试逻辑层没有问题之后再写接口,可以避免写出的接口不合适。
  • 善于写伪代码,将程序需要实现的每个步骤先用抽象的伪代码写出来。具体实现时再将伪代码细化。
  • 写代码之前先编写测试用例,将你期望的输入输出写在测试用例中

大胆重构

开发者应该保持爱折腾的习惯,不安于现状,才能做到与时俱进。软件之所以叫软件,正是因为它是“软”的,需求随时在更新,上星期的代码放在今天也许就不再合适。也正因为软件是软的,我们可以很方便的通过重构改进它。只要有良好的测试用例,就大胆的重构吧!这里列出一些应该重构的时机:

  • 当你需要添加一个新功能,突然发现程序耦合严重,导致新功能不是那么好添加,那就先将程序重构到可以方便的添加新功能。
  • 当你阅读代码时,发现程序可读性低,导致理解上的困难,显然代码还不够清晰,先将其重构到一眼能够看出结构。
  • 你找到一种更好的实现方式,千万不要因为现有的代码仍然可用就置之不理。尝试将你的想法实现出来。即使失败了,你也会更能理解为什么代码是现在这个样子。

PS:关于重构的更多知识可以阅读 Martin Fowler 所著的《重构改善既有代码的设计》,软件开发不朽的经典。

定时备份

年轻时,我曾在网上问一个命令行怎么写,有人教我 rm -rf / ...

如果程序中用到数据库操作,一定要记得定时备份。数据库备份有诸多好处:可以防止数据丢失,可以在程序出错时方便数据回滚。而且它并不需要太多的成本,只需要写个脚本完成定时自动备份,并删除过老的备份数据即可。如果数据库没有做备份,而数据库又被误操作删除了的话,那就等同于爆炸。

同样,代码也需要及时备份,使用版本管理系统可以解决这个问题。用上 Git,随时 commit,丢失代码的情况几乎不可能发生。

写一份完善的 README

GitHub 上有非常多的好项目,无一例外,他们都有一份完善的 README。 README 是程序的门面,有助于别人及时发现你写的好项目(不要奢望每个人都有闲情逸致来阅读你的源码)。况且 README 文档的好处不止于此,它还可以帮助自己梳理逻辑,理清思路。

写好 README 之后,随着项目的演进及时更新它,不会花太多时间,但能让你随时都对项目有个整体的把握。绝对值得一试。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • TrueSTUDIO for stm32配置小技巧

    最近一直在使用STM32CubeMX和TrueSTUDIO进行STM32的程序开发,用起来已经是得心应手了。使用TrueSTUDIO的过程中知道了一些环境设置的...

    用户4645519
  • 自己常用的vscode的插件备忘录

    1、42header、koroFileHeader、psioniq File Header这三个是由于插入文件说明,函数说明的。我在编写c语言的时候经常用到的。...

    用户4645519
  • 如果简化stm32中printf函数的使用——首先重定向

    https://blog.csdn.net/dream_feng/article/details/83504862按照这个方式,添加成功。

    用户4645519
  • 自下向上的编写容易阅读的代码(上)

    我在 关于极简编程的思考 中曾提到要编写可阅读的代码。因为代码是编写一次,阅读多次。 阅读者包括代码编写者,以及后来的维护人员。能让阅读代码更轻松,有利于增强项...

    java思维导图
  • 程序员请改掉影响你升职加薪的36个坏习惯!

    IT行业的科技公司们一直苦苦追寻传说中以一当十的超级程序员,最新的研究表明确实存在这样一小撮效率奇高的“程序金刚”,但是一位普通程序猿如何能够蜕变成代码金刚呢?

    Java后端技术
  • 高级Python工程师教你如何正确写代码

    我接手的第一样东西就是React UI。我们有一个主要组件,它容纳了其他所有组件。我喜欢在代码中加入一点幽默感,我想把它命名为GodComponent。在cod...

    小小科
  • Dead Code为什么能在代码库中永生?

    在一些遗留系统中,经常会看到大片大片灰掉的代码(被注释掉了),这种代码是死代码吗?如果要我下定义,我认为这些不是死代码,因为它们连代码都称不上,如何又能叫死代码...

    袁慎建@ThoughtWorks
  • JS逆向时碰到了恶心的死代码怎么办?手把手教你解决!

    你是否也曾有过「跟着代码跳了很久之后,才发现那一大坨代码其实没有任何作用」的惨痛经历?

    青南
  • JS逆向时碰到了恶心的死代码怎么办?手把手教你解决!

    你是否也曾有过「跟着代码跳了很久之后,才发现那一大坨代码其实没有任何作用」的惨痛经历?

    崔庆才
  • 代码能写多少写多少 No.187

    有个朋友说,他十天写了 20000 行代码,当时我的膝盖就直接给它了,怎么会有这么强的选手??!!

    大蕉

扫码关注云+社区

领取腾讯云代金券