Patrick Steinhardt <ps@xxxxxx> writes: > One issue I have with the `_f` suffix is that I immediately jumped > to "formatting string". I think in other places we use `_ext` as a > suffix. It stands for "with flags". I've seen _with_options and _extended also used. This is like oid_object_info_extended() that has a variant oid_object_info() that is a simpler and less capable wrapper for common use cases. None of these overly long names are my favourites X-<. With brief inspection, many _ext() in midx.c are more like helpers that deal with a class of files with .$ext for various extensions; they are not the primary interface to external callers, and many are extern only because the code is spread across midx. and midx-write.c instead of being in a single compilation unit. >> diff --git a/string-list.h b/string-list.h >> index 6c8650efde..ee9922af67 100644 >> --- a/string-list.h >> +++ b/string-list.h >> @@ -281,4 +281,14 @@ int string_list_split(struct string_list *list, const char *string, >> */ >> int string_list_split_in_place(struct string_list *list, char *string, >> const char *delim, int maxsplit); >> + >> +/* trim() resulting string piece before adding it to the list */ >> +#define STRING_LIST_SPLIT_TRIM 01 > > Another nit: I think nowadays we more often use enums to introduce such > flags, where the benefit is improved grouping. Also, I think having > `(1 << 0)` as value is slightly more readable. OK, let's update that. Thanks.
