当前位置:  开发笔记 > 编程语言 > 正文

魔数与命名常数

如何解决《魔数与命名常数》经验,为你挑选了4个好方法。

在编写代码时,特别是在处理日期和时间时,您必须使用大量特定数字,例如:一分钟60秒,一小时3600秒.

有些人坚持使用其中许多原始值,而其他人则将它们放入常量以提高可读性.

例如:

$x = time() + 3600;
$y = time() + 86400;
$z = time() + 604800;

// vs

define('MINUTE', 60);
define('HOUR',   60 * MINUTE);   // 3600
define('DAY',    24 * HOUR);     // 86400
define('WEEK',    7 * DAY);      // 604800

$x = time() + HOUR;
$y = time() + DAY;
$z = time() + WEEK;

当然,第二个更容易阅读,但对于一些较低的值略微OTT,那么你究竟在哪里画线?就个人而言,我认为86400的可读性没有问题(在我的脑海中,我自动将其视为"24小时"),但是会在WEEK常数处绘制线条.



1> Pyrolistical..:

86400不行,因为您可以轻松将其输入为84600,88400等

错误的常量将是编译错误



2> Craig S..:

我的一位教授曾告诉我们不要在我们的代码中添加任何魔法数字,除了1,-1和0.这有点极端,但它仍然在我的脑海中,但仍指导着我,尽管我并不完全坚持.

在您的示例中,我更喜欢所有情况下的符号名称.



3> womble..:

15.minutes到处都是常数(或者像Rails 惯例那样可爱的衍生物).对我而言,它是关于简化所有人的"打字"; 如果我在一条线上的某个地方看到"10*MINUTES",我知道我正在处理时间(或者是某人正在进行屁股踢).如果我看到10*60或600,我完全有可能不会理解我们处理时间非常容易.



4> Scott Fergus..:

有一个相对好的参数,那么除零或一个以外的任何数字都应该是一个命名常量.即使在您断言您对86400的可读性没有任何问题的示例中,您的度量单位仍然存在一些模糊性.

如果我维护你的代码,我宁愿看到命名常量,如:

const int secondsInDay = 86400;

..那里没有太多的含糊之处.:)取决于是否有人(包括你自己......我的意思是,我很难记住我上周写的内容,更别说去年!)将需要在某个阶段维护你的代码.

推荐阅读
135369一生真爱_890
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有