代码可读性的改良

首先, 有这样的代码,逻辑是没错的,但是长而且可读性不好:

message = subAction == "add" ?  String.format(format, contentMap.get("owner"), contentMap.get("ownerHomeName"))
         : String.format(format, contentMap.get("ownerHomeName"))

改良版1,代码没那么长了,但是可读性没什么改善:

message = String.format(format, contentMap.get("owner"), contentMap.get("ownerHomeName"))
message = subAction == "add" ? message : String.format(format, contentMap.get("ownerHomeName")) 

改良版2,多一行,看起来可读性就好多了

addMessage = String.format(format, contentMap.get("owner"), contentMap.get("ownerHomeName"))
removeMessage = String.format(format, contentMap.get("ownerHomeName"))
message = subAction == "add" ? addMessage : removeMessage 

朋友给的python版本解决方案,可惜他没看参数个数:

foo = lambda x: String.format( format , contentMap.get( x) )
message = foo( ‘owner‘ ) if subAction is ‘add‘ else foo( ‘ownerHomeName‘ )
时间: 2024-11-08 21:29:23

代码可读性的改良的相关文章

原生 js前端路由系统实现2之代码可读性 和可扩展性

前一篇 尝试着实现了前端路由的部分功能 原生 js前端路由系统实现1 代码可读性 影响代码可读和易于理解的因素 1 代码规范 2缩进空格 3减少函数嵌套层次 4函数单一职责 5.... 以上这些顶多只能在外观上面看起来清晰(也不一定真的清晰),但随着代码量的增大  代码依然非常难读和易于理解 如果给你几十行代码,程序员通过琢磨也能短时间搞清楚,如果给你上万行代码 即便技术大牛也得花大量的时间去阅读和调试才能看懂 影响代码可读性的主要原因是 代码的多少 以下是上次实现路由的代码 去掉兼容AMD等库

代码可读性艺术在Andorid中的体现

前言 最近接手的一些项目,不同的人编码风格迥异,类里的变量.方法的定义穿插,注释极为稀少,更有一些变量和方法的命名非常近似,例如表示播放队列的"playQueue"和表示歌单的"playList",wtf? 这不是一个意思吗?一些回调的时机也不能直观的看出来,通常需要debug调试多次;multi project之间值的传递.广播跨进程的发送.服务的开启和绑定,一句注释都没有,不知道过了这么久, 这些代码的同事,还能很快看懂自己写的东西吗?这简直让人抓狂啊,于是乎,

Unity3d 基本设计开发 原则(提高代码可读性)

参考:http://blog.csdn.net/qq_34134078/article/details/51780356 1.单一原则 即:明确类的定义.通俗来讲,让他们只做一件事,而不是多件事. 提高类的可读性,更加好维护,降低耦合度.当然,方法,变量亦是如此. 2.里氏替换原则 a.子类可以实现父类的抽象方法,但不能覆盖父 类的非抽象方法. b.子类可以增加自己特有的方法. 不遵循的后果:写代码的问题几率大大增大. 3.依赖倒置原则 高层模块不应依赖底层模块,二者应该都依赖抽象.细节依赖抽象

javascript 代码可读性

可读性的大部分内容都是和代码缩进相关的,必须保证代码有良好的格式.可读性的另一方面就是注释,一般而言,有如下一些地方需要进行注释 1.1.1           函数和方法 每个函数或方法都应该包含一个注释,描述其目的和用于完成任务所可能使用的算法,陈述事先的假设也非常重要,如参数代表什么,函数是否有返回值等等 1.1.2           大段代码 用于完成单个任务的多行代码应该在前面放一个描述任务的注释 1.1.3           复杂的算法 如果使用了一个独特的方式解决某个问题,则要

如何提高代码可读性

一.要提高的代码的可读性,可以从以下几方面努力 1. 清晰地表达意图 2.好的变量.方法.类名 3. 一个变量.类.方法只做一件事 4. 同一个方法体内,保持相同的抽象层次 5.一致的缩进,一致的格式 6. 不要重复自己(避免手动的复制与粘贴代码) 7. 减少“语法噪音” 8.减少代码中的嵌套级别 9. 命名时取有意义的名字,避免不规范的缩写 二.具体的提高代码的可读性的做法 1.先写注释,再写代码:理清思路再动手 (1)清晰的思路是编程行动的良好指南 花点时间思考一下,不要一接到任务就动手编代

提高代码可读性的注释技巧 实用型

很多程序员在写代码的时候往往都不注意代码的可读性,让别人在阅读代码时花费更多的时间.其实,只要程序员在写代码的时候,注意为代码加注释,并以合理的格式为代码加注释,这样就方便别人查看代码,也方便自己以后查看了.下面分享十个加注释的技巧:为每个代码块添加注释,并在每一层使用统一的注释方法和风格.例如:· 针对每个类:包括摘要信息.作者信息.以及最近修改日期等;· 针对每个方法:包括用途.功能.参数和返回值等.在团队工作中,采用标准化的注释尤为重要.当然,使用注释规范和工具(例如C#里的XML,Jav

提高 代码 可读性的 一点小建议

3. UI工厂类 与 代码块 UI工厂类: 其实代码很简单,就是把对Label, Button等控件的属性赋值封装一下, 做到一行代码就能创建一个VIew, 如下图, 虽然这一句代码有点长, 但是习惯之后写个View是真心快 UI工厂类.h

某日看代码对代码可读性的思考

缘起 今天去看编译模块的代码,发现实在是看不进去.究其原因,就是设计得有些混乱.这提醒了我,很多时候写代码的时候不会注意到一些设计上的问题.在阅读别人代码的时候会非常清晰地表现出来.其中有一些典型的问题. 命名之设计模式 比如使用了某种设计模式,但是命名却没有符合那个设计模式的规范.导致看了代码许久,才反应过来:"原来这里使用了××设计模式啊". 命名之方法内容 经常有些方法叫:"build××".但是其实里面的内容远多于build一个实体对象.而是包含了很多查询.

编写可读性代码的艺术

在做IT的公司里,尤其是软件开发部门,一般不会要求工程师衣着正式.在我工作过的一些环境相对宽松的公司里,很多程序员的衣着连得体都算不上(搞笑的T恤.短裤.拖鞋或者干脆不穿鞋).我想,我本人也在这个行列里面.虽然我现在改行做软件开发方面的咨询工作,但还是改不了这副德性.衣着体面的其中一个积极方面是它体现了对周围人的尊重,以及对所从事工作的尊重.比如,那些研究市场的人要表现出对客户的尊重.而大多数程序员基本上每天主要的工作就是和其他程序员打交道.那么这说明程序员之间就不用互相尊重吗?而且也不用尊重自