吐槽一下同事的函数接口，C语言传参数的问题，有一个既是输入，又是输入出的参数?

quietwave 2016-05-18 11:14:04

同事写了一个函数，就是算一个文件的hash值。函数体是这样的
int calcHash(unsigned char* data,int dataLen, unsigned char hash[], int *hashLen)；
然后，我照着以前他写的一个调用方法调，总是不对。最后发现，他说那个hashLen必须赋初值。
初值为要计算的hash值长度，初值是多少，他才知道hash[]数组分配的空间跟算法的是否匹配？因为有多种算法，算出的hash值长度可能不一样，虽然我们常用的都是32位的。

但是，我就很纳闷，这参数，int*不就是一个输出参数吗？怎么还对初值有要求呀？你要有几组算法，算不同的hash长度，那你多写几个函数呀
calcHash32
calcHash64
这多清楚呀！

大家说说，是我少见多怪，还是同事写得不规范呀

...全文

406 17 打赏收藏转发到动态举报

写回复

用AI写文章

17 条回复

切换为时间正序

请发表友善的回复…

发表回复

renwotao2009 2016-05-19

打赏
举报

最好做出标注

Saleayas 2016-05-19

打赏
举报

她不是接口定义的不规范。而是他的接口的文档没有。接口文档应该仔细说明函数的呼叫契约。详细说明每一个参数的定义。详细说明返回值。详细说明函数调用的时候的其他情况。看看 MSDN中的 CreateFile 函数。

xigua1102 2016-05-19

打赏
举报

你要知道，在c里面，这种用法非常普遍能不能这么用，只能看公司对代码规范如何他这么写也没啥问题，唯一的问题可能就是，他没有写注释。。。

珍惜生命远离CPP 2016-05-19

打赏
举报

按照你同事的设计 hashLen应该是传指针进去,你传入hash的长度，hashLen传出结果的长度。

用户　昵称 2016-05-19

打赏
举报

引用 8 楼 zhao4zhong1 的回复:

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

赵4老师 2016-05-19

打赏
举报

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

quietwave 2016-05-19

打赏
举报

謝谢诸位的回答,除了那个刷屏的,其他的回答都非常好,让我很有启发.分少了点,给大家散了

lm_whales 2016-05-19

打赏
举报

嗯，应该写 int calcHash(unsigned char* OUT data,int IN dataLen, unsigned char OUT hash[], int * IN OUT hashLen)；这样可能清晰一些

renwotao2009 2016-05-19

打赏
举报


#define IN
#define OUT
int fun(OUT int *p, IN int i);

renwotao2009 2016-05-19

打赏
举报

引用 4 楼 quietwave 的回复:

[quote=引用 2 楼 renwotao2009 的回复:] 最好做出标注

顶一个，确实是标注不清楚的问题。见过以前别人写的库，.h文件每个函数头，都加了参数是I还是O或者I/O 不过，话又说回来了，直观的理解，一般一个参数既是I又是O的情况还是比较少吧。真是不符合人类思维的习惯。。。。[/quote] #define IN #define OUT

用户　昵称 2016-05-19

打赏
举报

同时in和out的参数挺多的，你同事的意思是你传了16，他就调用md5，你传了20就是sha1，不过32的时候，是sha256还是sm3，这就分不清了吧。

quietwave 2016-05-19

打赏
举报

引用 2 楼 renwotao2009 的回复:

最好做出标注

顶一个，确实是标注不清楚的问题。见过以前别人写的库，.h文件每个函数头，都加了参数是I还是O或者I/O 不过，话又说回来了，直观的理解，一般一个参数既是I又是O的情况还是比较少吧。真是不符合人类思维的习惯。。。。

quietwave 2016-05-19

打赏
举报

引用 1 楼 u010370871 的回复:

既是输入又是输出不就是指针跟引用么

引用也一般是用来做输出的吧。你见过调一个函数，对作为输出参数引用的初值还有要求吗？系统库里面有这种用法吗？

ForestDB 2016-05-19

打赏
举报

还真有这样的API： man 2 accept The addrlen argument is a value-result argument: it should initially contain the size of the structure pointed to by addr; on return it will contain the actual length (in bytes) of the address returned.