优先考虑continue，慎用break

ghh_bigpan

         最近，接受了项目组的一项安排，给俺们的终端产品利用USB多映射出一个端口。心中惶惶然~USB技术这辈子还没有接触过，它的技术基础，实现方式等更是一点不懂！但任务在此，还是要赶鸭子上架啦。努力的复制粘贴外加一些小小的创新工作，修改了18个分散的源代码文件之后，代码工作初步完成。调试还算顺利，编译通过。
         狂喜！接下来用PC端串口工具做测试，问题就来了：PC端映射出来的端口只能接受广播来的消息，但不能主动发送消息！先怀疑自己的代码N遍，看了又看，想了又想，没有发现问题。利用usb通信抓取工具，也没有发现任何可疑之处（可能有，不过，我对USB协议一知半解都谈不上）。接近三天极度郁闷的调试工作，让人崩溃，但始终没有找到原因。更变态的是，这个端口偶尔还能正常发送命令。
         Bug必有因，代码里自有其逻辑。只是看你能不能敏锐发现那个藏匿极深能够让你脱离苦海的陷阱。一个原程序中的初始化代码无意中闯入了视野：
  for (iface = FIRST_IFACE;
       iface < MAX_IFACE_NUM;
       iface++)
  {
    if (iface == BREW_NOTIFICATION_IFACE)
      break;
         ……………………
}
     原来代码中，BREW_NOTIFICATION_IFACE接口是在一个枚举中最后的，但这个接口又不需要初始化，所以当初开发的人员冒昧的选择了break，退出循环。而我加的接口在这个接口之后，所以我的接口完全没有初始化。也就没有注册上USB端口的中断。所以造成了产品终端不能检测外来的任何输入！！！
S*H*I*T，在心里尽量文明的狂骂了代码提供商N遍，把break改成了continue，重新编译，下载，验证。一切OK!!!从地狱升入天堂！

这个故事告诉大家：在循环里，要优先考虑continue，慎用break，除非有绝对的理由。

谨以此文，纪念一个break抹杀掉的我的三天青春！！！！！