大家来说说这两种思路

辛昕

大家来说说这两种思路 [复制链接]

今儿和同事讨论一个我写的小代码段。

某个子函数里，要实现一个功能，把一个超过10的数一点一点减小到零，减小规律很简单：
比如说，超过1000分，则100为单位减，超过100分，则10为单位减，以此类推。
PS：这个数字最大不会超过50万。

我最初的写法如下

//num :待减数
//power:权，或者说 位数
while(num)
{
     num /= 10;
     power++;
}

for(i = 0;i <= power;i++)
{
     if(i == 2)
       unit = 1;
     else
       unit *= 10;
}

然而，同事认为这种写法很诡异，很别扭，他说，还不如直接if-else呢......

这个当然很好理解......

if(num >= 100000)
   unit = 10000;
else if(num >= 10000)
   unit = 1000;
else if(num >= 1000)
   unit = 100;
。。。。。。。。。。。。。。。。。。

好吧，写到这里，我突然发现我原来的写法真的是一无是处。
只不过我习惯性地采用这种除10的方法取得高位，用模10的方法取得最低位.....

别的不说
最初，我评论一种思路的优劣时，经常没有太多考虑别的，只是考虑这种写法本身是否潜在危险，如果没有，我就很放肆地使用。

所以当时，我并不服气，但是，回头想想。
别的不说，首先，我的做法就很别扭，先求位数，又再反过来算出单位。
然后这个速度肯定慢了许多.

我第一个为自己辩驳的理由是，通用。
因为我不在乎这个数字到底有多大，不管多大，我这个代码段都是通用的，不用改动一点。

可是，我故意在最开始的描述里特别强调，这个数字最大不会超过50万，这个描述对我是不利的，但我仍然觉得完全说出使用环境，更为公平。

-----------------------------------------------------------------
事实上，这个简单的讨论，醉翁之意不在酒。
只是有时觉得，习惯性占了主导性，有时候自己深陷其中仍然浑然不知。
想想都可怕。

chenzhufly

  简单就是美

zca123

嗯，不错

jinkaiuse

楼主，我一看见你的题目思路跟你很像，再一看你同事的，感觉他的代码更好理解，这个的确很纠结

dontium

不能仅为了好看而不讲代码质量

辛昕

其实也不是为了好看。
只是习惯性觉得，这样做通用，对数字大小没要求

gispx_01

不能仅为了好看而不讲代码质量

dontium

原帖由 辛昕 于 2012-4-3 23:05 发表 其实也不是为了好看。只是习惯性觉得，这样做通用，对数字大小没要求

 

哦，我原来的没有说清楚，本来是想对原来的楼上所说的。

你的这种思路很好。

 

我觉得，if--else用得多的时候，必须考虑用其它办法才行。写“一”、“二”、“三”的时候，可以画横，写四的时候，再画四个横就不妥了。

辛昕

哦，这样。

其实是这样的。

我见过好些程序——因为我是做单片机嵌入式这一块的，所以我说的基本上都是跑单片机的设备上的程序，比如一些什么机械手简单控制程序啊，比如一些什么读卡设备一类的。
当然这些代码本身来源大多是网络啊或者其他类似于（卖机械手的）厂商提供，我不知道这些代码本身质量如何。
但就我个人看到的想法是，这些代码大多数时候滥用一些语法结构：
比方说 switch
比方说函数基本上不带参，也就基本没通用性，我觉得，那压根就是纯粹压缩主调函数的长度而已。
更有甚者，最近看到的那个机械手程序，有让我更加发指的是  把一些非常简单的操作，比如位判断逐个逐个做成 带参宏，而且命名方式更是乱七八糟.....

当然，那是一个 学生参加比赛，他们辅导老师让他们背（！！！吃惊）的程序，可能就是个非常恶心的程序，我个人的观点是，这家伙压根不是在写C代码，它是在用C写汇编。

还有一些常见的，用起死循环等待跟不要钱似的.....

诸如此类。

当然，这些似乎看起来非常明显是不对的做法，不在本帖讨论范围。
但有一些则不同，比如switch。
这个回帖有点长了，怕丢了，我接个帖子再写

辛昕

接着说switch。
switch这个结构和goto这些东西一样，似乎被某些程序员视为雷池不可越近，也有被迷恋的不行，动辄就是一个长到一个屏幕还看不完的switch结构。

对于这类雷池的说法，我曾经有过，但哪只是针对goto，而switch并不十分回避。
当然，我现在对于goto在内的所谓雷池，也是抱着一定的使用原则，不回避使用。因为毕竟有其方便之处。

然而对于switch则不好说了。
switch这个结构有一个if-else所没有的好处。
那就是在处理类似状态机思想的程序结构时，天然有一种 条理清晰 的 优势。
然而，有时我却实在觉得它也是一个大麻烦。
比如，我见过一位朋友写的一个代码，他也是采用状态机思想，但是，他的switch居然有两个嵌套，而且彼此之间并不完全独立（这种潜在的危险导致他的这个程序惹出不少乱子，当然我也被波及了......因为我们是联调的......）

说句公道话，这个程序因为涉及的状态比较复杂，即使不用switch写，也很容易陷入这种因嵌套混乱引起的乱子，但是，据我所观察到的情形是，比如我这位朋友。
他并不是善于使用switch，他只是单纯认为，switch有助于条理清晰，因此，用起来也是跟不要钱似的。

但是，switch的确有这样的好处。
所以，有时我也非常蛋疼，我是否该坚持自己的if做法。
我习惯性采用while里加if条件判断，配合continue return break等各种循环控制语句跳转。
尽可能避免switch。

这种写出来的程序，我自己而言，很少遇到流程上的麻烦，只是我的同事看起来则非常痛苦，以至于我经常思考如何调和，又该不该调和？
我并不是顽固地坚持自己的风格，只是用一种自己不熟悉不习惯使用的手法，而且只是为了调和——但我有时甚至觉得他们对switch的依赖有点不可思议。
我并不知道我该不该这样放弃自己擅长和熟悉的方式。

嘿嘿，当然这也是一个编程中的个案，和主题贴一样
醉翁之意不在酒，或至少，不止如此。

希望大家多多讨论，给我这样的后生更多指点

guangod

意味深长！

辛昕

?

小小白

第一个思路是我们学习c的时候一直用到的，第二个有点小白，，但是谁都能理解

小小白

其实每个人看别人的程序都是很痛苦的，除非那个人写的程序的注释比较多，最近我是在看我的学长写的智能车的程序，发现他的宏定义等诡异的很，各种的怪异，但是等到自己看懂了之后觉得还是有一定的妙处的。

辛昕

不是一般的痛苦

一朵时光

楼主分析很透彻很有心 问题能够洞明了讲 。