git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 0/11] renaming argv_array

From
Eric Sunshine <sunshine@sunshineco.com>
Date
Jul 29, 2020, 13:32 UTC
Message-ID
<CAPig+cQEqhpu3-_wXUFjfokSuesu2a5QdiaT8ks4kPiYkUsOvw@mail.gmail.com>
In-Reply-To
<CAP8UFD26J6W50SeQqJiG0y04kcdNzr6RRT7ZeJmrQ2V-QTS3Lg@mail.gmail.com>

On Wed, Jul 29, 2020 at 2:16 AM Christian Couder <christian.couder@gmail.com> wrote:

Show 13 quoted lines
> I would expect after the above sentence that you would rename it to
> "string_array" or "str_array".
> [...]
> Also we still use "array" in "oid_array" which is very similar to
> this. And the implementation is based on the ALLOC_GROW macro which
> uses the REALLOC_ARRAY macro.
>
> We also use ALLOC_ARRAY, FLEX_ARRAY, CALLOC_ARRAY, COPY_ARRAY and
> MOVE_ARRAY macros.
> [...]
> If you want to change only "argv_array" (and not also "oid_array",
> "REALLOC_ARRAY" and perhaps other *_ARRAY macros) into something else,
> then I think it would be better to be consistent with them.
Dipping my toe into the bikeshed paint bucket...

Naming consistency is certainly a valid concern, and if this was a public API I might agree that such consistency should outweigh some other concerns, however, this is a private, project-specific API in which convenience and concision weigh more heavily in my opinion. There is value in succinctness, not just when writing code (by having to type less), but also when reading it, for the same reason that we use short and sweet variable and function names. To wit: short, well chosen, idiomatic names let the structure of the code show through (often) at-a-glance, whereas long names force us to laboriously read code, making it harder to discern the overall structure and logic.

There is also value[1] in having "vec" (or "v") in the name as opposed to "array", specifically because this isn't just an array of strings; it is a NULL-terminated vector of strings. Thus, it is suitable for functions which accept such a datatype, which often have "v" in their names, as well (for instance, execv()).

On the topic of a "terminated array": As a NULL-terminated array of strings, the name "strvec" provides naming consistency and fits nicely alongside the name "strbuf", a NUL-terminated array of characters, while also sharing the relative concision of that name.

In my opinion, the name "strvec" is a good and reasonably succinct compromise between other names, such as "strv"[2] and "strs"[3], proposed previously. It gets my "+1".

[1]: https://lore.kernel.org/git/20180227221808.GE11187@sigill.intra.peff.net/ [2]: https://lore.kernel.org/git/20180227220443.GB11187@sigill.intra.peff.net/ [3]: https://lore.kernel.org/git/CAPig+cS+G-xC51n-Ud0Wbmcc-zeHBM3-5WQQAFm9gwm9LNk3Gg@mail.gmail.com/

Previous: Christian CouderNext: Jeff King
Message 33 of 46 in “renaming argv_array”
  1. 0/11 renaming argv_arrayJeff King, Jul 28, 2020
  2. 01/11 argv-array: use size_t for count and allocJeff King, Jul 28, 2020
  3. 02/11 argv-array: rename to strvecJeff King, Jul 28, 2020
  4. 03/11 strvec: rename files from argv-array to strvecJeff King, Jul 28, 2020
  5. 04/11 quote: rename sq_dequote_to_argv_array to mention strvecJeff King, Jul 28, 2020
  6. 05/11 strvec: convert builtin/ callers away from argv_array nameJeff King, Jul 28, 2020
  7. 06/11 strvec: convert more callers away from argv_array nameJeff King, Jul 28, 2020
  8. 07/11 strvec: convert remaining callers away from argv_array nameJeff King, Jul 28, 2020
  9. 08/11 strvec: fix indentation in renamed callsJeff King, Jul 28, 2020
  10. Jacob KellerJul 28, 2020
  11. Junio C HamanoJul 28, 2020
  12. 09/11 strvec: update documention to avoid argv_arrayJeff King, Jul 28, 2020
  13. 10/11 strvec: drop argv_array compatibility layerJeff King, Jul 28, 2020
  14. Junio C HamanoJul 28, 2020
  15. Jeff KingJul 29, 2020
  16. Jeff KingJul 29, 2020
  17. Jeff KingJul 29, 2020
  18. Junio C HamanoJul 29, 2020
  19. Derrick StoleeJul 29, 2020
  20. Junio C HamanoJul 29, 2020
  21. Jeff KingJul 29, 2020
  22. 11/11 strvec: rename struct fieldsJeff King, Jul 28, 2020
  23. Junio C HamanoJul 28, 2020
  24. Junio C HamanoJul 28, 2020
  25. Christian CouderJul 29, 2020
  26. Jeff KingJul 29, 2020
  27. Junio C HamanoJul 29, 2020
  28. Jeff KingJul 28, 2020
  29. Jacob KellerJul 28, 2020
  30. Jeff KingJul 29, 2020
  31. Christian CouderJul 29, 2020
  32. Christian CouderJul 29, 2020
  33. Eric SunshineJul 29, 2020
  34. Jeff KingJul 29, 2020
  35. René ScharfeAug 11, 2020
  36. Taylor BlauAug 11, 2020
  37. Junio C HamanoAug 11, 2020
  38. Jacob KellerAug 11, 2020
  39. Junio C HamanoAug 11, 2020
  40. Johannes SchindelinAug 12, 2020
  41. Jeff KingAug 12, 2020
  42. Jeff KingAug 12, 2020
  43. René ScharfeAug 12, 2020
  44. Jeff KingAug 12, 2020
  45. René ScharfeAug 12, 2020
  46. Jeff KingAug 12, 2020

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.