代码整洁之道札记:函数

前言:随着对《clean code》的不断深入研读,我越发对自己以前编写的代码感到厌烦,我开始着手去做一些改变,让我不再是一个傻瓜,我想让别人去读懂我的代码,因为我记得这样一句话:“任何傻瓜都能编写计算机看懂的代码,而好的程序员能够编写人看懂的代码”。

短小

前两天,在百度首页上看到这样一张照片,手枪还没有巴掌大,我觉得非常适合Robert的这个主题。

函数是要足够的短小精致。那么具体应该短小到什么程度呢?

  • 函数20行封顶最佳。
  • 每个函数都依序把你带到下一个函数。
  • 函数的缩进层级不该多于一层或者两层。

只做一件事

函数应该只做一件事,并且做好这件事。

判断函数只做一件事的准则就是不能再将该函数再细化。

每个函数一个抽象层级

这个意思就是说,在国家这个层级下面就是省份,省份下面为市级,这样一层层关系明确,类似树形结构。

这样就确保从上向下的一种设计观点,在《人月神话》中也看到这样的观点,自上而下的设计会带来诸多好处,减少bug量的发生等。

switch语句

按照Robert的观点的话,switch语句写起来太过不容易,那么切容我们暂时逃避过去这个小节。

使用描述性的名称

的确好的函数名称,能够让我们很快的了解到函数内部要做的事情,不过这通常很困难。

不要害怕长名称。使用恰如其当的长名称来描述函数内部要做的事情能够让我们一睹为快。那种“犹抱琵琶半遮面”的名称让人费解,也让人难受。

void updateTotalmoneyForTransfermoneyIn(Map usermoney);

曾经我很讨厌这样的长名称,他让代码不易于在一行之内读完,但是这样的名称先让不需要注释就能读懂在干什么(修改总资金为了入金)。

命名方式要一致。如果你有几个功能类似的函数,自然在名称上要保持一致性。

public void sendToQuotationServerStatus() {
public void sendToQuotationJadeQuotations(String scode) {

以上名称就要比下面的好很多,保持步调一致让人舒服多了

public void noticQuotationServerSendQuotationData(String scode) {
public void sendToQuotationServerStatus() {

函数参数

最理想的参数数量是0,其次是1,再次是2,尽量避免3.

我也非常同意Robert的观点:

多参让测试更难执行。

输出参数比输入参数难以理解。

我之前写了这样的函数

private void appendIdToResultAndUpdateMessage(String id, StringBuilder result) {
   moneyTransfer.setReturnMessage(MoneyTransfer.MESSAGE_BEFORE_SEND_BANK);
   result.append(id);
   result.append(",");
 }

看着以上的方式和下面的方式,我在犹豫哪一种方式更好?

private StringBuilder getUsefulIdAndUpdateMessage(String id) {
  StringBuilder result = new StringBuilder();
   moneyTransfer.setReturnMessage(MoneyTransfer.MESSAGE_BEFORE_SEND_BANK);

   result.append(id);
   result.append(",");

  return result;
 }

关于标识参数、二元函数、三元函数,我没有找到更好的实践内容?????????????

参数对象。

见Robert给出例子,足以说明问题。

makeCircle(double x, double y, double radius);
makeCircle(Point center, double radius);

很显然,谁都愿意用第二种方式。

参数列表

这个很有意思,见如下代码

System.out.println(String.format("%s月 %s号是 %s的生日", 5, 1, "千千"));// 5月 1号是 千千的生日

无副作用

太多太多时候,我们经常向贪吃蛇一样,咬住了自己的尾巴。如果函数只在某种特殊条件下执行,那么名称最好能标有其环境条件。

public static String getTimeStr(Date date) {
  return getDateStr(date, "HH:mm:ss");
 }

这样的函数你能吃得消吗?它误导我们可以把日期转换为时间字符串,但是内容却限定了,只能是“HH:mm:ss”,而不能是“HHmmss”,那么最好把该函数重命名。

输出参数

再回头来看看appendIdToResultAndUpdateMessage()这个方法,显然我更应该使用getUsefulIdAndUpdateMessage(),然后这样调用

result.append(getUsefulIdAndUpdateMessage(manyid));

分割指令与询问

函数要么做什么事,要么回答什么事,来看看这样的函数

public void resume() {
  if (isAction())
   return;

private boolean isAction() {
  logger.info("节假日信息:" + ISHOLIDAY + " | " + HASTRADINGJADE);
  return ISHOLIDAY || !HASTRADINGJADE;
 }

isAction的作用是判断节假日的,如果是节假日,就不再做其他处理,那么这个函数其实不应该有返回值,改造一下

public void resume() {
  logger.info("白盘连续竞价恢复...");

  checkServerAction();

private void checkServerAction() {
  logger.info("节假日信息:" + (ISHOLIDAY ? "是节假日" : "不是节假日") + " | " + (HASTRADINGJADE ? "有商品" : "无商品"));

  if (ISHOLIDAY || !HASTRADINGJADE) {
   return;
  }
 }

这样肯定会好一些。

使用异常代替返回错误码

使用错误码的确让人感觉没有使用try catch让人舒服。

try {
   message = service.addOrder(orderFromClient, actionType);

  } catch (OrderException e) {
   logger.warn(e.getMessage());
   message = MessageUtils.getFailureMsg(e.getMessage());

本节的其他观点我没有很好的认同感。

别重复自己

这个其实很能体现程序员的水平高低,好的程序员善于把那些重复的代码进行简化做成。

总结:Robert说他自己在一开始写出的函数也曾经冗长,没有人从一开始就能遵守这些规则,那样代码就无法进行下去了。只有在不断的重构优化,才能有更好的代码。

我对这样的自己不感觉到讨厌。

最后附上自己按照作者的观点重构的一部分代码:

public void dailyUpdateSystemData() {
  // 每日更新时进行一次会员信息更新
  AllMembercoes.init();

  checkPrivilege();

  // 交易所手动不可操作限制
  setSYS_HAND_STATUS(Constants.OTHER_STATUS_END);

  updateReloadStatusTrue();

  initConfig();

  initJadeInfo();

  initQuotation();

  initUserMoney();

  // 刷新一次行情信息
  sendToQuotationJadeQuotations();

我觉得突然很欣赏自己。

时间: 2024-10-08 21:03:42

代码整洁之道札记:函数的相关文章

代码整洁之道札记:格式

前言:东汉大臣陈蕃有一则这样的故事,"一屋不扫何以扫天下",寓意来表明一个大丈夫,如果连自己的居室都不能打扫干净,怎么胸怀天下.<代码整洁之道>就是来劝诫我们程序员写出更优秀的代码,而"格式"一章也恰巧给我们举出了很多原则,以供我们写出更加规整的代码. 格式的目的 好的代码格式,让人赏心悦目,并且随着版本的更迭,让你能够随心所欲的进行变更,而不是每次都痛苦不堪. 垂直格式 类文件的行不应该成千上万行,应尽量保持短小,当然这点很难做到,我们习惯于在一个类中

代码整洁之道札记之整洁代码

前言:一直以来,我都非常喜欢整洁规则的代码,我痛恶那些杂乱不堪的代码,然而<代码整洁之道>将要告诉我的远不止这些,那么,我希望将自己欣赏的.能够给我帮助的.指引我前进的方案记录下来,以用来我日后翻看. 要有代码 将需求明确到机器可以执行的细节程度,是编程要做的事.一个好的产品,显然其最精髓的不应该是外观,而是诸如Java编译后的class文件. 糟糕的代码 看到"糟糕"这个词就觉得可怕,我之前接手的一个web项目,最初打包完成后,足足有48M,里面充斥着大量的垃圾代码,糟糕

代码整洁之道札记:有意义的命名

前言:英语虽然才3级,奈何却阻止不了我征服英语的勇气,哈哈,有意义的命名,那必须要倾尽我的所有英语才华,去实现代码的整洁啊. 名副其实 这个说起来容易,做起来难,我们的母语是汉语,最熟悉的是汉语拼音,所以我们在新建一个类名.方法.变量时,第一刻的印象是由拼音组成的:另外由于项目参与者的英语水平又参差不齐,又会产生混乱. public class Time { private long time1; private long time2; private long time3; private l

代码整洁之道札记:注释

前言:曾经我对"一份好的代码里注释至少要占到一半的份量"这样话深信不疑,我也不厌其烦的给每一个函数都加上javadoc,对此,我深感自豪:而对于别人写代码不加注释的"坏习惯",我深表遗憾.然而当我读完Robert的"注释"一节,我已经懊恼不已,并且我已经开始对我的代码进行审核,再次优化.我已经开始遵守"别给糟糕的代码加注释–重新写吧"这条准则. 也许你是一个好人,会对代码进行不断的优化改进,然而你经常会把注释忽略掉,就如同下面

《代码整洁之道》读后感

众所周知,软件质量,不但依赖于架构及项目管理,而且与代码质量紧密相关.这一点,无论是敏捷开发派还是传统开发派,都不得不承认.<代码整洁之道>提出一种观念:代码质量与其整洁度成正比.干净的代码,既在质量上较为可靠,也为后期维护.升级奠定了良好的基础.作为编程领域的佼佼者,这些实践在<代码整洁之道>中体现为一条条规则(或称“启示”),并辅以来自现实项目的正.反两面的范例.只要遵循这些规则,就能编写出干净的代码,从而有效提升代码质量.以上便是<代码整洁之道>这本书的内容简介,

《代码整洁之道》精读与演绎】之四 优秀代码的格式准则

本系列文章由@浅墨_毛星云 出品,转载请注明出处.  文章链接:http://blog.csdn.net/poem_qianmo/article/details/52268975 作者:毛星云(浅墨)    微博:http://weibo.com/u/1723155442 这篇文章将与大家一起聊一聊,书写代码过程中一些良好的格式规范. 一.引言 以下引言的内容,有必要伴随这个系列的每一次更新,这次也不例外. <代码整洁之道>这本书提出了一个观点:代码质量与其整洁度成正比,干净的代码,既在质量上

&lt;代码整洁之道&gt;、&lt;java与模式&gt;、&lt;head first设计模式&gt;读书笔记集合

一.前言                                                                                       几个月前的看书笔记,内容全部都是摘自书中比较精辟的句子.笔记都是一段一段的句子,故没有文章的篇幅概念,仅供温习之用,更多详细内容请看原书!!! <代码整洁之道>里面有很多前人编写简洁.漂亮代码的经验.当然书中作者的经验并不100%适合每个人,但大部分都是可借鉴的! <java与模式>这本书内容太多了,我

【读书笔记】--代码整洁之道

“相对于任何宏伟景愿,对细节的关注甚至是更为关键的专业性基础.首先,开发者通过小型实践获得可用于大型实践的技能和信用度.其次,宏伟建筑中最细小的部分,比如关不紧的门,有点儿没有铺平的地板,甚至是凌乱的桌面,都会将整个大局的魅力毁灭殆尽.这就是整洁代码之所系”----没有比书中的这段话更能说明这本书的意义了. <代码整洁之道>是第1期书山有路活动选出的读本.相对于记住那些如何写出整洁代码的那些法则,养成保持代码整洁.提高代码质量的习惯和思维更为重要.全书大致分为三个部分,第一部分1-10章都是介

代码整洁之道

命名,多花些时间推敲命名, 有意义的命名非常重要. 接口的命名,不使用"I"开头比较简洁,加上I以后是比较规范,但是比较繁琐以及废话.如果想区别接口和实现,不如在实现类中进行编码,比如添加后缀"Imp",android以及jdk中的大多数接口都没有使用I. 取名字带有简写要慎重, 比如"人事系统"的类, 前面都是"RSXT..",除了让快捷按钮找不到类以外,没有啥意义了,用包吧. 函数,函数要短小,要职责明确,最好功能单一,参