user-0 提问: 代码里的错误判断，怎么写最简洁啊，感觉好多重复呢

回复:
user: user-1
content: 请牢记：源代码本身的书写是否结构化或面向对象或符合设计模式或敏捷…并不重要，重要的是你是否使用结构化或面向对象或符合设计模式或敏捷…的方法命名标识符、阅读、修改、检查、测试源代码。  意思是你程序结构看上去再合理，再简洁，也不一定比看上去一团乱麻的程序结构在运行或修改时更不易出错，更方便修改，出错了更容易找到哪里出错和具体出错的原因，更容易改正错误。  试对比 图书馆（对图书的分类够结构化了吧） 和 搜索引擎（可看作是扁平化任何结构数据，仅支持全文检索） 哪个处理信息更方便、更高效。  所以 与其费劲去重构代码让其看上去更简洁、更合理 不如费劲学习grep、sed、awk、……这类全文搜索和批处理编辑的工具。  结构越复杂，越难修改，越难除错。 有时（甚至大多数时候），看上去越合理、越简洁的代码，运行起来性能越差，出错时查找原因越难，找到出错原因后改正越费劲。  程序员要做的不是尽力避免错误，而是聚焦在快速发现并改正错误。真正以快速方式轻易解决错误，“快速的失败”远胜过“预防错误”。Fred George  前微软C#编辑器的开发主管Jay Bazuzi列出的一些有助于找到正确方向的问题；他觉得前同事们应该用这些问题来问自己；实际上不管在哪里工作的开发者们都应该经常问问自己这些问题： ◆“要保证这个问题不会再出现，我该怎么做？” ◆“要想少出些Bug，我该怎么做？” ◆“要保证Bug容易被修复，我该怎么做？” ◆“要保持对变化的快速响应，我该怎么做？” ◆“要保证我的软件的运行速度，我该怎么做？” 如果大多数团队都能不时问一下自己，必定会从中得益，因为这些都是真正强而有力的问题。

user: user-2
content: BOOL FUN() {     BOOL retval = FALSE;     WSADATA WSAData;     if (WSAStartup(MAKEWORD(2,0), &WSAData))          return FALSE;     SOCKET sock = socket(AF_INET, SOCK_DGRAM, 0);     if (sock != INVALID_SOCKET)      {         do          {              ......              BOOL bOptVal = TRUE;             if (setsockopt(sock, SOL_SOCKET, SO_BROADCAST, (char*)&bOptVal, sizeof(BOOL)))             {                 break;             }             if (sendto(sock, (const char *)MagicP, sizeof(MagicP), 0, (struct sockaddr *)&RecvAddr, sizeof(RecvAddr)) == SOCKET_ERROR)             {                 break;             }             retval = TRUE;         } while (FALSE);         closesocket(sock);     }     WSACleanup();     return retval; }

user: user-3
content: 谁来说说，LS谁是比较优的代码

user: user-4
content: 1. goto语句 2. 封装类 3. try...catch...

user: user-5
content: 感觉习惯就好

user: user-6
content: 不用goto，这么写试试  BOOL FUN() { 	WSADATA WSAData; 	if (WSAStartup(MAKEWORD(2,0), &WSAData)) return FALSE;  	BOOL bRet = FALSE; 	SOCKET sock = socket(AF_INET, SOCK_DGRAM, 0); 	do  	{ 		if (sock == INVALID_SOCKET)  		{ 			break; 		}  		...... 		BOOL bOptVal = TRUE; 		if (setsockopt(sock, SOL_SOCKET, SO_BROADCAST, (char*)&bOptVal, sizeof(BOOL))) 		{ 			break; 		} 		if (sendto(sock, (const char *)MagicP, sizeof(MagicP), 0, (struct sockaddr *)&RecvAddr, sizeof(RecvAddr)) == SOCKET_ERROR) 		{ 			break; 		} 		bRet = TRUE; 	} while (0);  	closesocket(sock); 	WSACleanup();  	return bRet; }

user: user-7
content: C语言的话，用goto吧，不要迷信有些教科书说goto不好，好不好看你怎么用。

user: user-8
content: 1、如果是C语言，可考虑用goto跳至函数末尾，执行清理操作 2、如果是C++，建议封装成类对象，在析构时会自动释放资源，这样则可直接return就行

user: user-9
content: C++语言用 try 结构也是一个不错的选择 try { } catch() { } finally { }

user: user-10
content: 可以把那几个方法封装一下，比如定义一个MySocket类，里面定义诸如setsockopt这些方法，这些方法的实现就是调真实的setsockopt，然后再析构函数里，加上 closesocket(sock); WSACleanup(); 这两句，这样局部变量在函数退出前，一定会调用析构函数

user: user-1
content: 20%实现功能，80%错误处理。 这很正常！

user: user-1
content: 虎头蛇尾是俗人的习惯， 有始有终是君子的操守。

user: user-11
content: 一个产品中的代码，这些错误判断是必不可少的，不可省略。不过这段代码里return过多，会导致错误处理的遗漏和不统一。而且不易修改。可以修改成这样：  BOOL FUN() {     WSADATA WSAData;     int wsi=-1;          if (wsi=WSAStartup(MAKEWORD(2,0), &WSAData))     {          goto err_exit;     }     SOCKET sock = socket(AF_INET, SOCK_DGRAM, 0);     if (sock == INVALID_SOCKET)      {         goto err_exit;     }           ......       BOOL bOptVal = TRUE;     if (setsockopt(sock, SOL_SOCKET, SO_BROADCAST, (char*)&bOptVal, sizeof(BOOL)))     {         goto err_exit;     }     if (sendto(sock, (const char *)MagicP, sizeof(MagicP), 0, (struct sockaddr *)&RecvAddr, sizeof(RecvAddr)) == SOCKET_ERROR)     {         goto err_exit;     }     closesocket(sock);     WSACleanup();     return TRUE; err_exit:     if (sock != INVALID_SOCKET)    closesocket(sock);     if (!wsi)        WSACleanup();      return FALSE; }   如果不想用goto 跳转，也可以把错误处理这几条定义成宏，在出错处理的地方调用宏ERR_EXIT      :  #define ERR_EXIT      if (sock != INVALID_SOCKET)    closesocket(sock); \     if (!wsi)        WSACleanup(); \      return FALSE;

user: user-1
content: 请牢记：源代码本身的书写是否结构化或面向对象或符合设计模式或敏捷…并不重要，重要的是你是否使用结构化或面向对象或符合设计模式或敏捷…的方法命名标识符、阅读、修改、检查、测试源代码。  意思是你程序结构看上去再合理，再简洁，也不一定比看上去一团乱麻的程序结构在运行或修改时更不易出错，更方便修改，出错了更容易找到哪里出错和具体出错的原因，更容易改正错误。  试对比 图书馆（对图书的分类够结构化了吧） 和 搜索引擎（可看作是扁平化任何结构数据，仅支持全文检索） 哪个处理信息更方便、更高效。  所以 与其费劲去重构代码让其看上去更简洁、更合理 不如费劲学习grep、sed、awk、……这类全文搜索和批处理编辑的工具。  结构越复杂，越难修改，越难除错。 有时（甚至大多数时候），看上去越合理、越简洁的代码，运行起来性能越差，出错时查找原因越难，找到出错原因后改正越费劲。  程序员要做的不是尽力避免错误，而是聚焦在快速发现并改正错误。真正以快速方式轻易解决错误，“快速的失败”远胜过“预防错误”。Fred George  前微软C#编辑器的开发主管Jay Bazuzi列出的一些有助于找到正确方向的问题；他觉得前同事们应该用这些问题来问自己；实际上不管在哪里工作的开发者们都应该经常问问自己这些问题： ◆“要保证这个问题不会再出现，我该怎么做？” ◆“要想少出些Bug，我该怎么做？” ◆“要保证Bug容易被修复，我该怎么做？” ◆“要保持对变化的快速响应，我该怎么做？” ◆“要保证我的软件的运行速度，我该怎么做？” 如果大多数团队都能不时问一下自己，必定会从中得益，因为这些都是真正强而有力的问题。

user: user-12
content: goto

user: user-13
content: 楼主，把重复的代码，放到函数FUN外面，通过FUN返回值，再做相关处理~~~这样可以否？？