Considering alternative / better ways of naming function arguments #22317
Replies: 6 comments 3 replies
-
Ping @openssl/otc |
Beta Was this translation helpful? Give feedback.
-
My preference would be for the third option from above. The question is where to apply it. To all arguments with names matching well-known libc functions? Or everywhere? Or just when we encounter a bug report like #22296? I'd vote for the 3rd or 1st option from these, against the second. |
Beta Was this translation helpful? Give feedback.
-
I'm thinking "everywhere" in the same way as we apply our function name prefix "everywhere". In other words, primarily in new function declarations, but also allowing for refactoring for any reason. Reasons to refactor could be quite broadly specified, including "I felt like it", but otherwise as response to all sort of findings. Do note that an argument name change isn't an API change, 'cause it doesn't matter at all to the compiler (apart from clashes), which allows us to be quite frivolous with this sort of change. |
Beta Was this translation helpful? Give feedback.
-
Surely this is similar to "don't use reserved words as variable names"? It has happened before, and might happen again, but is it serious enough to require a prefix to all function names? In this instance, |
Beta Was this translation helpful? Give feedback.
-
see #22316 (review). |
Beta Was this translation helpful? Give feedback.
-
I am fine with not using But I don't see that this is a big enough or likely enough issue to warrant a change in the way function parameters are named. |
Beta Was this translation helpful? Give feedback.
-
#22296 was an issue that demonstrated a clash between argument names we use in OpenSSL public headers and other headers (in this case, the clash is with the name
gets
). This is not the first time that we've had that happen, and it's potential if not likely that this will happen again.It might be time to consider a standard for naming arguments, or not naming them at all (which is permitted in C standards), and to apply it broadly.
Possible variants, taking the example from #22296:
This could ultimately lead to a technical policy along side the coding style, or an amendment of the coding style.
Beta Was this translation helpful? Give feedback.
All reactions