最近以提问的形式发了几条关于编程思维的微博，有的获得了粉丝的响应，有些却无人问津。今天突然想到可以将我对这些问题的思考整理成一篇博文，以便与大家分享。另外，我计划以“编程思维训练”为名写一些系列文章，希望通过这类文章与读者分享我在编程活动中的一些思考。
问：有一对内存管理函数MemAlloc和MemFree，使用形式分别是：分配时为“void *p = MemAlloc (6)"，释放时为“MemFree (&p)”。你能看出什么问题吗？有什么建议？
答：一谈到内存分配与释放函数，我们很自然地会想到来自C库的malloc和free函数。然而，MemFree与free在入参类型的定义上却存在很大的差别，前者需要传入的是指针的指针，而后者所需的却是指针。由于MemFree函数的入参形式与free存在区别，这就容易造成使用者容易因为忽视这种区别而在初次使用时犯错。
尽管MemFree的函数参数定义成指针的指针存在一定的好处 — 可以在MemFree函数中对所释放内存的指针变量置NULL，但由于它违背了malloc/free的使用常识，因而不可取。我的建议是，定义API名称时，应尽可能符合“常识”。
问：malloc与free是C库中用于从堆中分配和释放内存的函数。这两个函数在命名上有什么问题？如果给你重新命名的机会，你会如何做？
答：很显然，malloc函数是“memory allocate”的简写，那相应的内存释放函数应是“memory free”，如果采用一致的命名，free函数的名称应是mfree。因此，C库中的malloc/free函数存在命名一致性问题。
问：在Linux操作系统中，所有的外设都位于/dev目录之下以文件的形式进行管理的，能否将socket也纳入到/dev目录之下呢？如果是你，你会如何做？为什么要这样做？
答：将外设放入/dev目录，使得在Linux中操作外设（或设备）与操作文件是相似的。这种设计一方面减少了API的数量，另一方面，使得程序员很容易掌握设备的操控编程。然而，Linux中的socket却采用了完全不同的设计实现。
在Linux中如要打开一个socket，则必须调用socket函数，且在函数中指定是流类型（stream），还是数据报类型（datagram），以及所需打开的端口号。然而，从TCP/IP协议的角度来看，我们知道“流”对应的是TCP协议，而“数据报”对应的是UDP协议。这种映射关系尽管简单（但并不易懂），但不可避免的是，它仍然引入了“映射”这一行为（复杂化了）。
如果将socket也按目录的方式进行管理，那么打开一个socket也可以用open函数，且目录结构可以考虑采用协议名进行组织。比如，采用“open (“/net/ipv4/tcp/3344”, O_CREAT)”的形式打开一个端口号为3344的TCP socket，而采用“open (“/net/ipv4/udp/3344”, O_CREAT)”的形式打开一个UDP的socket。很显然，这种方式并不需要引入“流”与“数据报”的概念，且简少了API的数量。总体说来，基于目录结构的socket设计将使得Linux在概念上更加一致。
问：有一对内存管理函数MemAlloc和MemFree，使用形式分别是：分配时为“void *p = MemAlloc (6)"，释放时为“MemFree (&p)”。你能看出什么问题吗？有什么建议？
答：一谈到内存分配与释放函数，我们很自然地会想到来自C库的malloc和free函数。然而，MemFree与free在入参类型的定义上却存在很大的差别，前者需要传入的是指针的指针，而后者所需的却是指针。由于MemFree函数的入参形式与free存在区别，这就容易造成使用者容易因为忽视这种区别而在初次使用时犯错。
尽管MemFree的函数参数定义成指针的指针存在一定的好处 — 可以在MemFree函数中对所释放内存的指针变量置NULL，但由于它违背了malloc/free的使用常识，因而不可取。我的建议是，定义API名称时，应尽可能符合“常识”。
问：malloc与free是C库中用于从堆中分配和释放内存的函数。这两个函数在命名上有什么问题？如果给你重新命名的机会，你会如何做？
答：很显然，malloc函数是“memory allocate”的简写，那相应的内存释放函数应是“memory free”，如果采用一致的命名，free函数的名称应是mfree。因此，C库中的malloc/free函数存在命名一致性问题。
问：在Linux操作系统中，所有的外设都位于/dev目录之下以文件的形式进行管理的，能否将socket也纳入到/dev目录之下呢？如果是你，你会如何做？为什么要这样做？
答：将外设放入/dev目录，使得在Linux中操作外设（或设备）与操作文件是相似的。这种设计一方面减少了API的数量，另一方面，使得程序员很容易掌握设备的操控编程。然而，Linux中的socket却采用了完全不同的设计实现。
在Linux中如要打开一个socket，则必须调用socket函数，且在函数中指定是流类型（stream），还是数据报类型（datagram），以及所需打开的端口号。然而，从TCP/IP协议的角度来看，我们知道“流”对应的是TCP协议，而“数据报”对应的是UDP协议。这种映射关系尽管简单（但并不易懂），但不可避免的是，它仍然引入了“映射”这一行为（复杂化了）。
如果将socket也按目录的方式进行管理，那么打开一个socket也可以用open函数，且目录结构可以考虑采用协议名进行组织。比如，采用“open (“/net/ipv4/tcp/3344”, O_CREAT)”的形式打开一个端口号为3344的TCP socket，而采用“open (“/net/ipv4/udp/3344”, O_CREAT)”的形式打开一个UDP的socket。很显然，这种方式并不需要引入“流”与“数据报”的概念，且简少了API的数量。总体说来，基于目录结构的socket设计将使得Linux在概念上更加一致。
实际上，目前的Linux中socket也是一种类型的fd（file descriptor），尽管造成目前的现状有很多历史原因，但它仍可以向前迈进一步。