Do people prefer string or enum arguments to functions taking one of a restricted list of options?
The function I'm writing is

char *loadasutf8wthknownformat(const char *filename, format, int *error);

If format is an enum, I'd have to create an enum with a list of formats supported. If it's a string, the caller has to pass one of a restricted set of formats.

Advantages to the enum
It's a lot harder to pass a typo or an ill- formed format.
Caller has a list of allowed formats which automatically update.
It's more machine efficent (but won't matter for this function)

Advantages to the string
Several functions might operate on text file formats. Strings don't
pollute the namespace.
It's easier to print out a human-readable diagnostic at runtime.
It's slightly more natural if the origin of the value is an input string
anyway and not a hard-coded constant.
If an exponential combination problem starts, the string can solve it
by parsing. e.g the suffix "le" or "be" could always mean "big-endian"
or "little-endian" . With enums you would have to double the length of the
list.

The hybrid compromise which we often use at work is to #define
string constants.

sobota, 29 lipca 2023 o 12:20:47 UTC+2 Malcolm McLean napisał(a):
> Do people prefer string or enum arguments to functions taking one of a restricted list of options?
> The function I'm writing is
>
> char *loadasutf8wthknownformat(const char *filename, format, int *error);
>
> If format is an enum, I'd have to create an enum with a list of formats supported. If it's a string, the caller has to pass one of a restricted set of formats.
>
> Advantages to the enum
> It's a lot harder to pass a typo or an ill- formed format.
> Caller has a list of allowed formats which automatically update.
> It's more machine efficent (but won't matter for this function)
>
> Advantages to the string
> Several functions might operate on text file formats. Strings don't
> pollute the namespace.
> It's easier to print out a human-readable diagnostic at runtime.
> It's slightly more natural if the origin of the value is an input string
> anyway and not a hard-coded constant.
> If an exponential combination problem starts, the string can solve it
> by parsing. e.g the suffix "le" or "be" could always mean "big-endian"
> or "little-endian" . With enums you would have to double the length of the
> list.
>
> The hybrid compromise which we often use at work is to #define
> string constants.

i use what i call signetuires (it is 'this like things')

its becouse probably the demon of coding i recently wrote about "distributed code"
i mean code you need to jump on many places when you write - this jumping kills productivity
- thus classical enums are last of use for me now (c lack ad hoc enums idea i mean anums that you write lik 'that' but that are mapped to integers or somethig liek that this way you can have milions of them and each one noc ocupy more than word of cpu

sobota, 29 lipca 2023 o 15:43:30 UTC+2 fir napisał(a):
> sobota, 29 lipca 2023 o 12:20:47 UTC+2 Malcolm McLean napisał(a):
> > Do people prefer string or enum arguments to functions taking one of a restricted list of options?
> > The function I'm writing is
> >
> > char *loadasutf8wthknownformat(const char *filename, format, int *error);
> >
> > If format is an enum, I'd have to create an enum with a list of formats supported. If it's a string, the caller has to pass one of a restricted set of formats.
> >
> > Advantages to the enum
> > It's a lot harder to pass a typo or an ill- formed format.
> > Caller has a list of allowed formats which automatically update.
> > It's more machine efficent (but won't matter for this function)
> >
> > Advantages to the string
> > Several functions might operate on text file formats. Strings don't
> > pollute the namespace.
> > It's easier to print out a human-readable diagnostic at runtime.
> > It's slightly more natural if the origin of the value is an input string
> > anyway and not a hard-coded constant.
> > If an exponential combination problem starts, the string can solve it
> > by parsing. e.g the suffix "le" or "be" could always mean "big-endian"
> > or "little-endian" . With enums you would have to double the length of the
> > list.
> >
> > The hybrid compromise which we often use at work is to #define
> > string constants.
> i use what i call signetuires (it is 'this like things')
>
> its becouse probably the demon of coding i recently wrote about "distributed code"
> i mean code you need to jump on many places when you write - this jumping kills productivity
> - thus classical enums are last of use for me now (c lack ad hoc enums idea i mean anums that you write lik 'that' but that are mapped to integers or somethig liek that this way you can have milions of them and each one noc ocupy more than word of cpu

probably one could even say that this code distribution (multiply of places) is dodays tiem goto/global variavles - code distribution is evil

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> Do people prefer string or enum arguments to functions taking one of a
> restricted list of options? The function I'm writing is
>
> char *loadasutf8wthknownformat(const char *filename, format, int *error);
>
> If format is an enum, I'd have to create an enum with a list of
> formats supported. If it's a string, the caller has to pass one of a
> restricted set of formats.

I think I'd #define the formats (as you suggest later on).

> Advantages to the enum
> It's a lot harder to pass a typo or an ill- formed format.
> Caller has a list of allowed formats which automatically update.
> It's more machine efficent (but won't matter for this function)
>
> Advantages to the string
> Several functions might operate on text file formats. Strings don't
> pollute the namespace.
> It's easier to print out a human-readable diagnostic at runtime.
> It's slightly more natural if the origin of the value is an input string
> anyway and not a hard-coded constant.

When I first learned Lisp, I could not work out what symbols were
supposed to be. They were "things" whose only purposes appeared to be
to different from other symbols, but they all sorts of uses, and this is
one other them: they are intrinsically human-readable distinct values.

> If an exponential combination problem starts, the string can solve it
> by parsing. e.g the suffix "le" or "be" could always mean "big-endian"
> or "little-endian" . With enums you would have to double the length of the
> list.
>
> The hybrid compromise which we often use at work is to #define
> string constants.

And you can combine them:

decode(filename, ENCODING_UTF_16 | ENCODING_BIG_ENDIAN);

--
Ben.

On Saturday, 29 July 2023 at 21:36:04 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > Do people prefer string or enum arguments to functions taking one of a
> > restricted list of options? The function I'm writing is
> >
> > char *loadasutf8wthknownformat(const char *filename, format, int *error);
> >
> > If format is an enum, I'd have to create an enum with a list of
> > formats supported. If it's a string, the caller has to pass one of a
> > restricted set of formats.
> I think I'd #define the formats (as you suggest later on).
> > Advantages to the enum
> > It's a lot harder to pass a typo or an ill- formed format.
> > Caller has a list of allowed formats which automatically update.
> > It's more machine efficent (but won't matter for this function)
> >
> > Advantages to the string
> > Several functions might operate on text file formats. Strings don't
> > pollute the namespace.
> > It's easier to print out a human-readable diagnostic at runtime.
> > It's slightly more natural if the origin of the value is an input string
> > anyway and not a hard-coded constant.
> When I first learned Lisp, I could not work out what symbols were
> supposed to be. They were "things" whose only purposes appeared to be
> to different from other symbols, but they all sorts of uses, and this is
> one other them: they are intrinsically human-readable distinct values.
> > If an exponential combination problem starts, the string can solve it
> > by parsing. e.g the suffix "le" or "be" could always mean "big-endian"
> > or "little-endian" . With enums you would have to double the length of the
> > list.
> >
> > The hybrid compromise which we often use at work is to #define
> > string constants.
> And you can combine them:
>
> decode(filename, ENCODING_UTF_16 | ENCODING_BIG_ENDIAN);
>
I've realised there's another flag. Sometimes the user will want to accept
UTF-16 with surrogate pairs, sometimes he'll want to reject it (because
his program can't handle the situation where one 16 bit value doesn't represent
one character). So the feared combinatorial explosion is starting.

On 7/30/23 11:28 AM, Malcolm McLean wrote:
> On Saturday, 29 July 2023 at 21:36:04 UTC+1, Ben Bacarisse wrote:
>> And you can combine them:
>>
>> decode(filename, ENCODING_UTF_16 | ENCODING_BIG_ENDIAN);
>>
> I've realised there's another flag. Sometimes the user will want to accept
> UTF-16 with surrogate pairs, sometimes he'll want to reject it (because
> his program can't handle the situation where one 16 bit value doesn't represent
> one character). So the feared combinatorial explosion is starting.

No, UTF-16 means you can have surrogate pairs representing the 21 bit
character.

If you don't want any values outside the 16 bit BMP, you want to use
UCS-2 not UTF-16

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Saturday, 29 July 2023 at 21:36:04 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>> > Do people prefer string or enum arguments to functions taking one of a
>> > restricted list of options? The function I'm writing is
>> >
>> > char *loadasutf8wthknownformat(const char *filename, format, int *error);
>> >
>> > If format is an enum, I'd have to create an enum with a list of
>> > formats supported. If it's a string, the caller has to pass one of a
>> > restricted set of formats.
>> I think I'd #define the formats (as you suggest later on).
>> > Advantages to the enum
>> > It's a lot harder to pass a typo or an ill- formed format.
>> > Caller has a list of allowed formats which automatically update.
>> > It's more machine efficent (but won't matter for this function)
>> >
>> > Advantages to the string
>> > Several functions might operate on text file formats. Strings don't
>> > pollute the namespace.
>> > It's easier to print out a human-readable diagnostic at runtime.
>> > It's slightly more natural if the origin of the value is an input string
>> > anyway and not a hard-coded constant.
>> When I first learned Lisp, I could not work out what symbols were
>> supposed to be. They were "things" whose only purposes appeared to be
>> to different from other symbols, but they all sorts of uses, and this is
>> one other them: they are intrinsically human-readable distinct values.
>> > If an exponential combination problem starts, the string can solve it
>> > by parsing. e.g the suffix "le" or "be" could always mean "big-endian"
>> > or "little-endian" . With enums you would have to double the length of the
>> > list.
>> >
>> > The hybrid compromise which we often use at work is to #define
>> > string constants.
>> And you can combine them:
>>
>> decode(filename, ENCODING_UTF_16 | ENCODING_BIG_ENDIAN);
>>
> I've realised there's another flag. Sometimes the user will want to
> accept UTF-16 with surrogate pairs, sometimes he'll want to reject it
> (because his program can't handle the situation where one 16 bit value
> doesn't represent one character). So the feared combinatorial
> explosion is starting.

No, that's not a flag, that's another encoding altogether called UCS-16.
UTF-16 implies the use of surrogates.

--
Ben.

On Sunday, 30 July 2023 at 18:09:57 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > On Saturday, 29 July 2023 at 21:36:04 UTC+1, Ben Bacarisse wrote:
> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>
> >> > Do people prefer string or enum arguments to functions taking one of a
> >> > restricted list of options? The function I'm writing is
> >> >
> >> > char *loadasutf8wthknownformat(const char *filename, format, int *error);
> >> >
> >> > If format is an enum, I'd have to create an enum with a list of
> >> > formats supported. If it's a string, the caller has to pass one of a
> >> > restricted set of formats.
> >> I think I'd #define the formats (as you suggest later on).
> >> > Advantages to the enum
> >> > It's a lot harder to pass a typo or an ill- formed format.
> >> > Caller has a list of allowed formats which automatically update.
> >> > It's more machine efficent (but won't matter for this function)
> >> >
> >> > Advantages to the string
> >> > Several functions might operate on text file formats. Strings don't
> >> > pollute the namespace.
> >> > It's easier to print out a human-readable diagnostic at runtime.
> >> > It's slightly more natural if the origin of the value is an input string
> >> > anyway and not a hard-coded constant.
> >> When I first learned Lisp, I could not work out what symbols were
> >> supposed to be. They were "things" whose only purposes appeared to be
> >> to different from other symbols, but they all sorts of uses, and this is
> >> one other them: they are intrinsically human-readable distinct values.
> >> > If an exponential combination problem starts, the string can solve it
> >> > by parsing. e.g the suffix "le" or "be" could always mean "big-endian"
> >> > or "little-endian" . With enums you would have to double the length of the
> >> > list.
> >> >
> >> > The hybrid compromise which we often use at work is to #define
> >> > string constants.
> >> And you can combine them:
> >>
> >> decode(filename, ENCODING_UTF_16 | ENCODING_BIG_ENDIAN);
> >>
> > I've realised there's another flag. Sometimes the user will want to
> > accept UTF-16 with surrogate pairs, sometimes he'll want to reject it
> > (because his program can't handle the situation where one 16 bit value
> > doesn't represent one character). So the feared combinatorial
> > explosion is starting.
> No, that's not a flag, that's another encoding altogether called UCS-16.
> UTF-16 implies the use of surrogates.
>
The Baby X resource compiler is primarily a utility to help build Baby X programs..
Baby X treats all string data as UTF-8, and if a string is passed to a non-UTF-8
compatible function then that should be considered a bug. So the utf16 tag
(input is in any text format, output is in UTF-16) doesn't really have a place in
Baby X programs.
However I decided to include it, somewhat reluctantly, to support non-Baby X
users of the resource compiler. But the only real reason for using UTF-16,
apart from the obvious one, which is to pass to third party libaries expecting
UTF-16, is to have "wide characters", where one "wide character" represents one
glyph. If you allow surrogate pairs, most of the advantges of UTF-16 over UTF-8
disappear.
So if someone uses the utf16 tag, they probably want to ensure that the data
contains no surrogate pairs. But not always.

The default behaviour of the Baby X resource compiler is to auto-detect the
format of text input files. However it's impossible to write an infallible detector.
So my current idea is to provide an optional attribute which gives the file format
and forces the system to load the data in that format. Adding surrogate pair
rejection to that format specification seems to be a simple way of achieving
utf16 tags free of surrogate pairs. There are also some near UTF-16 formats.
Which is one reason UTF-16 is undesireable. But you don't want to terrorise
the user. If it's 16 bit Unicode, then in most people's eyes, it's UTF-16.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Sunday, 30 July 2023 at 18:09:57 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>> > On Saturday, 29 July 2023 at 21:36:04 UTC+1, Ben Bacarisse wrote:
>> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>> >>
>> >> > Do people prefer string or enum arguments to functions taking one of a
>> >> > restricted list of options? The function I'm writing is
>> >> >
>> >> > char *loadasutf8wthknownformat(const char *filename, format, int *error);
>> >> >
>> >> > If format is an enum, I'd have to create an enum with a list of
>> >> > formats supported. If it's a string, the caller has to pass one of a
>> >> > restricted set of formats.
>> >> I think I'd #define the formats (as you suggest later on).
>> >> > Advantages to the enum
>> >> > It's a lot harder to pass a typo or an ill- formed format.
>> >> > Caller has a list of allowed formats which automatically update.
>> >> > It's more machine efficent (but won't matter for this function)
>> >> >
>> >> > Advantages to the string
>> >> > Several functions might operate on text file formats. Strings don't
>> >> > pollute the namespace.
>> >> > It's easier to print out a human-readable diagnostic at runtime.
>> >> > It's slightly more natural if the origin of the value is an input string
>> >> > anyway and not a hard-coded constant.
>> >> When I first learned Lisp, I could not work out what symbols were
>> >> supposed to be. They were "things" whose only purposes appeared to be
>> >> to different from other symbols, but they all sorts of uses, and this is
>> >> one other them: they are intrinsically human-readable distinct values.
>> >> > If an exponential combination problem starts, the string can solve it
>> >> > by parsing. e.g the suffix "le" or "be" could always mean "big-endian"
>> >> > or "little-endian" . With enums you would have to double the length of the
>> >> > list.
>> >> >
>> >> > The hybrid compromise which we often use at work is to #define
>> >> > string constants.
>> >> And you can combine them:
>> >>
>> >> decode(filename, ENCODING_UTF_16 | ENCODING_BIG_ENDIAN);
>> >>
>> > I've realised there's another flag. Sometimes the user will want to
>> > accept UTF-16 with surrogate pairs, sometimes he'll want to reject it
>> > (because his program can't handle the situation where one 16 bit value
>> > doesn't represent one character). So the feared combinatorial
>> > explosion is starting.
>> No, that's not a flag, that's another encoding altogether called UCS-16.
>> UTF-16 implies the use of surrogates.

<typo, it's called UCS-2. I was typing too many 16s.>

> The Baby X resource compiler is primarily a utility to help build Baby
> X programs.. Baby X treats all string data as UTF-8, and if a string
> is passed to a non-UTF-8 compatible function then that should be
> considered a bug. So the utf16 tag (input is in any text format,
> output is in UTF-16) doesn't really have a place in Baby X programs.
>
> However I decided to include it, somewhat reluctantly, to support
> non-Baby X users of the resource compiler. But the only real reason
> for using UTF-16, apart from the obvious one, which is to pass to
> third party libaries expecting UTF-16, is to have "wide characters",
> where one "wide character" represents one glyph. If you allow
> surrogate pairs, most of the advantges of UTF-16 over UTF-8 disappear.
>
> So if someone uses the utf16 tag, they probably want to ensure that the data
> contains no surrogate pairs. But not always.

I think you are saying you want to support UTF-16 (as specified --
surrogate pairs and all) but also something you call UTF-16 disallowing
surrogates. Why? The only difference between "UTF-16 disallowing
surrogates" and UCS-2 is the name. The result will most likely just be
confusing to users. It's like offering UTF-8 without multi-byte
characters. That's just called 7-bit ASCII.

--
Ben.

On Sunday, 30 July 2023 at 20:15:31 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > On Sunday, 30 July 2023 at 18:09:57 UTC+1, Ben Bacarisse wrote:
> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>
> >> > On Saturday, 29 July 2023 at 21:36:04 UTC+1, Ben Bacarisse wrote:
> >> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >> >>
> >> >> > Do people prefer string or enum arguments to functions taking one of a
> >> >> > restricted list of options? The function I'm writing is
> >> >> >
> >> >> > char *loadasutf8wthknownformat(const char *filename, format, int *error);
> >> >> >
> >> >> > If format is an enum, I'd have to create an enum with a list of
> >> >> > formats supported. If it's a string, the caller has to pass one of a
> >> >> > restricted set of formats.
> >> >> I think I'd #define the formats (as you suggest later on).
> >> >> > Advantages to the enum
> >> >> > It's a lot harder to pass a typo or an ill- formed format.
> >> >> > Caller has a list of allowed formats which automatically update.
> >> >> > It's more machine efficent (but won't matter for this function)
> >> >> >
> >> >> > Advantages to the string
> >> >> > Several functions might operate on text file formats. Strings don't
> >> >> > pollute the namespace.
> >> >> > It's easier to print out a human-readable diagnostic at runtime.
> >> >> > It's slightly more natural if the origin of the value is an input string
> >> >> > anyway and not a hard-coded constant.
> >> >> When I first learned Lisp, I could not work out what symbols were
> >> >> supposed to be. They were "things" whose only purposes appeared to be
> >> >> to different from other symbols, but they all sorts of uses, and this is
> >> >> one other them: they are intrinsically human-readable distinct values.
> >> >> > If an exponential combination problem starts, the string can solve it
> >> >> > by parsing. e.g the suffix "le" or "be" could always mean "big-endian"
> >> >> > or "little-endian" . With enums you would have to double the length of the
> >> >> > list.
> >> >> >
> >> >> > The hybrid compromise which we often use at work is to #define
> >> >> > string constants.
> >> >> And you can combine them:
> >> >>
> >> >> decode(filename, ENCODING_UTF_16 | ENCODING_BIG_ENDIAN);
> >> >>
> >> > I've realised there's another flag. Sometimes the user will want to
> >> > accept UTF-16 with surrogate pairs, sometimes he'll want to reject it
> >> > (because his program can't handle the situation where one 16 bit value
> >> > doesn't represent one character). So the feared combinatorial
> >> > explosion is starting.
> >> No, that's not a flag, that's another encoding altogether called UCS-16.
> >> UTF-16 implies the use of surrogates.
> <typo, it's called UCS-2. I was typing too many 16s.>
> > The Baby X resource compiler is primarily a utility to help build Baby
> > X programs.. Baby X treats all string data as UTF-8, and if a string
> > is passed to a non-UTF-8 compatible function then that should be
> > considered a bug. So the utf16 tag (input is in any text format,
> > output is in UTF-16) doesn't really have a place in Baby X programs.
> >
> > However I decided to include it, somewhat reluctantly, to support
> > non-Baby X users of the resource compiler. But the only real reason
> > for using UTF-16, apart from the obvious one, which is to pass to
> > third party libaries expecting UTF-16, is to have "wide characters",
> > where one "wide character" represents one glyph. If you allow
> > surrogate pairs, most of the advantges of UTF-16 over UTF-8 disappear.
> >
> > So if someone uses the utf16 tag, they probably want to ensure that the data
> > contains no surrogate pairs. But not always.
> I think you are saying you want to support UTF-16 (as specified --
> surrogate pairs and all) but also something you call UTF-16 disallowing
> surrogates. Why? The only difference between "UTF-16 disallowing
> surrogates" and UCS-2 is the name. The result will most likely just be
> confusing to users. It's like offering UTF-8 without multi-byte
> characters. That's just called 7-bit ASCII.
>
The <string> tag is designed to export human-readable ASCII (technically
the execution character set of whatever platform the resouce compiler is
running on). the <utf8> tag exports non-human readable UTF-8 as ACSCII-
encoded binary data. If the execution set is EBCDIC, it will still export UTF-8.

The <utf16> tag exports UTF-16 data, encoded as unsigned shorts. But there's
not much point in using this tag if the data contains surrogate pairs (it would
be just as easy to use UTF-8). However yes, you're right. I'm confusing the
import format, which could have surrogate pairs, with the export format, which
should reject them by default. So the <utf8> tag needs a flag to allow surrogate
pairs.

On 29/07/2023 12:20, Malcolm McLean wrote:
> Do people prefer string or enum arguments to functions taking one of a restricted list of options?
> The function I'm writing is
>
> char *loadasutf8wthknownformat(const char *filename, format, int *error);
>

If that is a typical example of your function names, then I recommend
you specify the format in Greek but written using the ancient Mongolian
writing system, in order to maintain consistency in the legibility of
the code. Maybe get your cat to type it in.

Alternatively, learn to use capitals or underscore to give the reader a
fighting chance to interpret such names. (The program writer is a lost
cause here.) And /why/, in that 25 character monstrosity, would you
abbreviate "with" to "wth" ?

> If format is an enum, I'd have to create an enum with a list of formats supported. If it's a string, the caller has to pass one of a restricted set of formats.
>

I'd use enums.

> Advantages to the enum
> It's a lot harder to pass a typo or an ill- formed format.
> Caller has a list of allowed formats which automatically update.
> It's more machine efficent (but won't matter for this function)
>
> Advantages to the string
> Several functions might operate on text file formats. Strings don't
> pollute the namespace.

That makes no sense.

> It's easier to print out a human-readable diagnostic at runtime.

That makes no sense. Just have a const array of strings indexed by your
enumeration. (It's a little more complex if you allow combinations of
enum flags.)

> It's slightly more natural if the origin of the value is an input string
> anyway and not a hard-coded constant.

Code has to parse such strings somewhere. Do it earlier, not later.

> If an exponential combination problem starts, the string can solve it
> by parsing. e.g the suffix "le" or "be" could always mean "big-endian"
> or "little-endian" . With enums you would have to double the length of the
> list.
>

Enumeration flags that are all powers of two, combined with |, are a
common and simple solution.

> The hybrid compromise which we often use at work is to #define
> string constants.
>

That combines the worst of all worlds, polluting your namespace (which
you dislike) while allowing typos inside strings.

On Tuesday, August 1, 2023 at 7:17:10 PM UTC+1, David Brown wrote:
> On 29/07/2023 12:20, Malcolm McLean wrote:
> > Do people prefer string or enum arguments to functions taking one of a restricted list of options?

> > It's easier to print out a human-readable diagnostic at runtime.

> That makes no sense. Just have a const array of strings indexed by your
> enumeration. (It's a little more complex if you allow combinations of
> enum flags.)

I beg to differ. Suppose you are accidentally using an older version of the function than you think you are. If you pass in an enum which is out of range, all the function can do is say what the value of the enum is, which the user may not immediately recognise. On the contrary, if you pass in a string saying the option, the function can print the string and say it is not a recognised option. Of course there are pros and cons to both approaches, but Malcolm's point makes sense.

wtorek, 1 sierpnia 2023 o 20:17:10 UTC+2 David Brown napisał(a):
> On 29/07/2023 12:20, Malcolm McLean wrote:
> > Do people prefer string or enum arguments to functions taking one of a restricted list of options?
> > The function I'm writing is
> >
> > char *loadasutf8wthknownformat(const char *filename, format, int *error);
> >
> If that is a typical example of your function names, then I recommend
> you specify the format in Greek but written using the ancient Mongolian
> writing system, in order to maintain consistency in the legibility of
> the code. Maybe get your cat to type it in.
>
its not so bad its a mattar of style but the abbreviations
are problem - abbreviations simply are nonesense to remember
as you wold need to remember it all and say use one scheme
globally amnog people but its rather nonsense (unless say
special ciricumstances, for exampel you erallny need that)

using strightforward kinda heavy/primitive names as i do
may look heavy and primitive but 'deburdens' you and imo yur
productivity increase..they are also raw good imo..coz they
'infiormational ratio' is simply high

hovever i would not say i have something seriously against
'code stylist' who wrote fancy names.. such names give even
wuite good feeling but the problems are sometimes some other
'gothic' flops, mainly those abbreviations and things resembling macroprocessor

On Tuesday, 1 August 2023 at 19:17:10 UTC+1, David Brown wrote:
> On 29/07/2023 12:20, Malcolm McLean wrote:
> > Do people prefer string or enum arguments to functions taking one of a restricted list of options?
> > The function I'm writing is
> >
> > char *loadasutf8wthknownformat(const char *filename, format, int *error);
> >
> If that is a typical example of your function names, then I recommend
> you specify the format in Greek but written using the ancient Mongolian
> writing system, in order to maintain consistency in the legibility of
> the code. Maybe get your cat to type it in.
>
There's a case for folding it into loadasutf8() and passing in a null or "automatic"
format parameter to indicate that the function should resort to automatic
detection. However once we have the "load with known format" function,
we can write loadasutf8(), unknown format, on top of it, which might be more
logical.

środa, 2 sierpnia 2023 o 17:41:00 UTC+2 fir napisał(a):
> wtorek, 1 sierpnia 2023 o 20:17:10 UTC+2 David Brown napisał(a):
> > On 29/07/2023 12:20, Malcolm McLean wrote:
> > > Do people prefer string or enum arguments to functions taking one of a restricted list of options?
> > > The function I'm writing is
> > >
> > > char *loadasutf8wthknownformat(const char *filename, format, int *error);
> > >
> > If that is a typical example of your function names, then I recommend
> > you specify the format in Greek but written using the ancient Mongolian
> > writing system, in order to maintain consistency in the legibility of
> > the code. Maybe get your cat to type it in.
> >
> its not so bad its a mattar of style but the abbreviations
> are problem - abbreviations simply are nonesense to remember
> as you wold need to remember it all and say use one scheme
> globally amnog people but its rather nonsense (unless say
> special ciricumstances, for exampel you erallny need that)
>
> using strightforward kinda heavy/primitive names as i do
> may look heavy and primitive but 'deburdens' you and imo yur
> productivity increase..they are also raw good imo..coz they
> 'infiormational ratio' is simply high
>
> hovever i would not say i have something seriously against
> 'code stylist' who wrote fancy names.. such names give even
> wuite good feeling but the problems are sometimes some other
> 'gothic' flops, mainly those abbreviations and things resembling macroprocessor

some could say that my 'mixed' approach (as i use pascal for functions and c shorts (no 'skipspaces' though) and lowcase_underscores for locals and variables its not stylistically to much good as its mixed and sometimes looks liek a salad with a lot of green peas - but it work well, so maybe i chosen it more by experimentation how it work than how it look

c overally has two styles of code itself imo, one is humanistical creative (and here you got a lot of pascal function names) and the second is more optimistation and ram related - on variables with underscores) and it is also seen here as lots of my code are lot of pascal and few optimisation routines are lot of underscores.. you maty say its uncoherent but those two types of codes are uncoherent with each other..writing humnistic code with underscores im not sure as to this, writing opt-code with camels more ok but underscores fit

On Wednesday, 2 August 2023 at 16:54:21 UTC+1, fir wrote:
> środa, 2 sierpnia 2023 o 17:41:00 UTC+2 fir napisał(a):
> > wtorek, 1 sierpnia 2023 o 20:17:10 UTC+2 David Brown napisał(a):
> > > On 29/07/2023 12:20, Malcolm McLean wrote:
> > > > Do people prefer string or enum arguments to functions taking one of a restricted list of options?
> > > > The function I'm writing is
> > > >
> > > > char *loadasutf8wthknownformat(const char *filename, format, int *error);
> > > >
> > > If that is a typical example of your function names, then I recommend
> > > you specify the format in Greek but written using the ancient Mongolian
> > > writing system, in order to maintain consistency in the legibility of
> > > the code. Maybe get your cat to type it in.
> > >
> > its not so bad its a mattar of style but the abbreviations
> > are problem - abbreviations simply are nonesense to remember
> > as you wold need to remember it all and say use one scheme
> > globally amnog people but its rather nonsense (unless say
> > special ciricumstances, for exampel you erallny need that)
> >
> > using strightforward kinda heavy/primitive names as i do
> > may look heavy and primitive but 'deburdens' you and imo yur
> > productivity increase..they are also raw good imo..coz they
> > 'infiormational ratio' is simply high
> >
> > hovever i would not say i have something seriously against
> > 'code stylist' who wrote fancy names.. such names give even
> > wuite good feeling but the problems are sometimes some other
> > 'gothic' flops, mainly those abbreviations and things resembling macroprocessor
> some could say that my 'mixed' approach (as i use pascal for functions and c shorts (no 'skipspaces' though) and lowcase_underscores for locals and variables its not stylistically to much good as its mixed and sometimes looks liek a salad with a lot of green peas - but it work well, so maybe i chosen it more by experimentation how it work than how it look
>
> c overally has two styles of code itself imo, one is humanistical creative (and here you got a lot of pascal function names) and the second is more optimistation and ram related - on variables with underscores) and it is also seen here as lots of my code are lot of pascal and few optimisation routines are lot of underscores.. you maty say its uncoherent but those two types of codes are uncoherent with each other..writing humnistic code with underscores im not sure as to this, writing opt-code with camels more ok but underscores fit
>
If whitespace is disallowed, humans prefer names which are simply concatenated. Computers find
it easier to deal with underscores.

środa, 2 sierpnia 2023 o 18:00:20 UTC+2 Malcolm McLean napisał(a):
> On Wednesday, 2 August 2023 at 16:54:21 UTC+1, fir wrote:
> > środa, 2 sierpnia 2023 o 17:41:00 UTC+2 fir napisał(a):
> > > wtorek, 1 sierpnia 2023 o 20:17:10 UTC+2 David Brown napisał(a):
> > > > On 29/07/2023 12:20, Malcolm McLean wrote:
> > > > > Do people prefer string or enum arguments to functions taking one of a restricted list of options?
> > > > > The function I'm writing is
> > > > >
> > > > > char *loadasutf8wthknownformat(const char *filename, format, int *error);
> > > > >
> > > > If that is a typical example of your function names, then I recommend
> > > > you specify the format in Greek but written using the ancient Mongolian
> > > > writing system, in order to maintain consistency in the legibility of
> > > > the code. Maybe get your cat to type it in.
> > > >
> > > its not so bad its a mattar of style but the abbreviations
> > > are problem - abbreviations simply are nonesense to remember
> > > as you wold need to remember it all and say use one scheme
> > > globally amnog people but its rather nonsense (unless say
> > > special ciricumstances, for exampel you erallny need that)
> > >
> > > using strightforward kinda heavy/primitive names as i do
> > > may look heavy and primitive but 'deburdens' you and imo yur
> > > productivity increase..they are also raw good imo..coz they
> > > 'infiormational ratio' is simply high
> > >
> > > hovever i would not say i have something seriously against
> > > 'code stylist' who wrote fancy names.. such names give even
> > > wuite good feeling but the problems are sometimes some other
> > > 'gothic' flops, mainly those abbreviations and things resembling macroprocessor
> > some could say that my 'mixed' approach (as i use pascal for functions and c shorts (no 'skipspaces' though) and lowcase_underscores for locals and variables its not stylistically to much good as its mixed and sometimes looks liek a salad with a lot of green peas - but it work well, so maybe i chosen it more by experimentation how it work than how it look
> >
> > c overally has two styles of code itself imo, one is humanistical creative (and here you got a lot of pascal function names) and the second is more optimistation and ram related - on variables with underscores) and it is also seen here as lots of my code are lot of pascal and few optimisation routines are lot of underscores.. you maty say its uncoherent but those two types of codes are uncoherent with each other..writing humnistic code with underscores im not sure as to this, writing opt-code with camels more ok but underscores fit
> >
> If whitespace is disallowed, humans prefer names which are simply concatenated. Computers find
> it easier to deal with underscores.

you mean humens prefer
char *loadasutf8wthknownformat(const char *filename, format, int *error);

? i dont think so.. (i name it 'skipspaces' style and never use it)

char *load_as_utf8_with_known_format(const char *filename, format, int *error);

lowcase underscore - betetr but imo nut much suitable for function names (unles maybe those who are terrubly optimisation related)
(skiping the sentence itself is maybe not much best, as those names with with are wierd imo.. it rather should have noun to make proper sentence non load but not specified what which is 'form' sentence not a sentence )
char *LoadAsUtf8WithKnownFormat(const char *filename, format, int *error);

char *LoadFileAsUtf8WithKnownFormat(const char *filename, format, int *error);
//better...thsi "WithKnown" could be rewritten for something more informative but i dont know what it exactly means in context of the code (and names shoudl say on the context not just as separate function) (hovever this "with known" in fact says something on context but it could bereohrased better i guess - and it is really important to sometimes think 10 seconds on exact name

i somethimes think...(in fact i always think - but sometimes if i cant find the godo name fast i write worse intentionally not to stop productivity.. but i think each time)

fir <profesor.fir@gmail.com> writes:
>=C5=9Broda, 2 sierpnia 2023 o=C2=A018:00:20 UTC+2 Malcolm McLean napisa=C5=
>=82(a):
>> On Wednesday, 2 August 2023 at 16:54:21 UTC+1, fir wrote:=20
>> > =C5=9Broda, 2 sierpnia 2023 o 17:41:00 UTC+2 fir napisa=C5=82(a):=20
>> > > wtorek, 1 sierpnia 2023 o 20:17:10 UTC+2 David Brown napisa=C5=82(a):=
>=20
>> > > > On 29/07/2023 12:20, Malcolm McLean wrote:=20
>> > > > > Do people prefer string or enum arguments to functions taking one=
> of a restricted list of options?=20
>> > > > > The function I'm writing is=20
>> > > > >=20
>> > > > > char *loadasutf8wthknownformat(const char *filename, format, int =
>*error);=20
>> > > > >=20
>> > > > If that is a typical example of your function names, then I recomme=
>nd=20
>> > > > you specify the format in Greek but written using the ancient Mongo=
>lian=20
>> > > > writing system, in order to maintain consistency in the legibility =
>of=20
>> > > > the code. Maybe get your cat to type it in.=20
>> > > >=20
>> > > its not so bad its a mattar of style but the abbreviations=20
>> > > are problem - abbreviations simply are nonesense to remember=20
>> > > as you wold need to remember it all and say use one scheme=20
>> > > globally amnog people but its rather nonsense (unless say=20
>> > > special ciricumstances, for exampel you erallny need that)=20
>> > >=20
>> > > using strightforward kinda heavy/primitive names as i do=20
>> > > may look heavy and primitive but 'deburdens' you and imo yur=20
>> > > productivity increase..they are also raw good imo..coz they=20
>> > > 'infiormational ratio' is simply high=20
>> > >=20
>> > > hovever i would not say i have something seriously against=20
>> > > 'code stylist' who wrote fancy names.. such names give even=20
>> > > wuite good feeling but the problems are sometimes some other=20
>> > > 'gothic' flops, mainly those abbreviations and things resembling macr=
>oprocessor=20
>> > some could say that my 'mixed' approach (as i use pascal for functions =
>and c shorts (no 'skipspaces' though) and lowcase_underscores for locals an=
>d variables its not stylistically to much good as its mixed and sometimes l=
>ooks liek a salad with a lot of green peas - but it work well, so maybe i c=
>hosen it more by experimentation how it work than how it look=20
>> >=20
>> > c overally has two styles of code itself imo, one is humanistical creat=
>ive (and here you got a lot of pascal function names) and the second is mor=
>e optimistation and ram related - on variables with underscores) and it is =
>also seen here as lots of my code are lot of pascal and few optimisation ro=
>utines are lot of underscores.. you maty say its uncoherent but those two t=
>ypes of codes are uncoherent with each other..writing humnistic code with u=
>nderscores im not sure as to this, writing opt-code with camels more ok but=
> underscores fit=20
>> >
>> If whitespace is disallowed, humans prefer names which are simply concate=
>nated. Computers find=20
>> it easier to deal with underscores.
>
>you mean humens prefer
> char *loadasutf8wthknownformat(const char *filename, format, int *error);

I prefer

char *load(const char *filename, format_t input format, error_t *error);

char *result = load(argv[1], F_UTF8, &error);
if (error != SUCCESS) {
fprintf(stderr, "Unable to load '%s' when interpreting as UTF-8", argv[1]);
return LOAD_FORMAT_FAILURE;
}

środa, 2 sierpnia 2023 o 18:14:22 UTC+2 fir napisał(a):
> środa, 2 sierpnia 2023 o 18:00:20 UTC+2 Malcolm McLean napisał(a):
> > On Wednesday, 2 August 2023 at 16:54:21 UTC+1, fir wrote:
> > > środa, 2 sierpnia 2023 o 17:41:00 UTC+2 fir napisał(a):
> > > > wtorek, 1 sierpnia 2023 o 20:17:10 UTC+2 David Brown napisał(a):
> > > > > On 29/07/2023 12:20, Malcolm McLean wrote:
> > > > > > Do people prefer string or enum arguments to functions taking one of a restricted list of options?
> > > > > > The function I'm writing is
> > > > > >
> > > > > > char *loadasutf8wthknownformat(const char *filename, format, int *error);
> > > > > >
> > > > > If that is a typical example of your function names, then I recommend
> > > > > you specify the format in Greek but written using the ancient Mongolian
> > > > > writing system, in order to maintain consistency in the legibility of
> > > > > the code. Maybe get your cat to type it in.
> > > > >
> > > > its not so bad its a mattar of style but the abbreviations
> > > > are problem - abbreviations simply are nonesense to remember
> > > > as you wold need to remember it all and say use one scheme
> > > > globally amnog people but its rather nonsense (unless say
> > > > special ciricumstances, for exampel you erallny need that)
> > > >
> > > > using strightforward kinda heavy/primitive names as i do
> > > > may look heavy and primitive but 'deburdens' you and imo yur
> > > > productivity increase..they are also raw good imo..coz they
> > > > 'infiormational ratio' is simply high
> > > >
> > > > hovever i would not say i have something seriously against
> > > > 'code stylist' who wrote fancy names.. such names give even
> > > > wuite good feeling but the problems are sometimes some other
> > > > 'gothic' flops, mainly those abbreviations and things resembling macroprocessor
> > > some could say that my 'mixed' approach (as i use pascal for functions and c shorts (no 'skipspaces' though) and lowcase_underscores for locals and variables its not stylistically to much good as its mixed and sometimes looks liek a salad with a lot of green peas - but it work well, so maybe i chosen it more by experimentation how it work than how it look
> > >
> > > c overally has two styles of code itself imo, one is humanistical creative (and here you got a lot of pascal function names) and the second is more optimistation and ram related - on variables with underscores) and it is also seen here as lots of my code are lot of pascal and few optimisation routines are lot of underscores.. you maty say its uncoherent but those two types of codes are uncoherent with each other..writing humnistic code with underscores im not sure as to this, writing opt-code with camels more ok but underscores fit
> > >
> > If whitespace is disallowed, humans prefer names which are simply concatenated. Computers find
> > it easier to deal with underscores.
> you mean humens prefer
> char *loadasutf8wthknownformat(const char *filename, format, int *error);
> ? i dont think so.. (i name it 'skipspaces' style and never use it)
>
> char *load_as_utf8_with_known_format(const char *filename, format, int *error);
>
> lowcase underscore - betetr but imo nut much suitable for function names (unles maybe those who are terrubly optimisation related)
> (skiping the sentence itself is maybe not much best, as those names with with are wierd imo.. it rather should have noun to make proper sentence non load but not specified what which is 'form' sentence not a sentence )
> char *LoadAsUtf8WithKnownFormat(const char *filename, format, int *error);
>
> char *LoadFileAsUtf8WithKnownFormat(const char *filename, format, int *error);
> //better...thsi "WithKnown" could be rewritten for something more informative but i dont know what it exactly means in context of the code (and names shoudl say on the context not just as separate function) (hovever this "with known" in fact says something on context but it could bereohrased better i guess - and it is really important to sometimes think 10 seconds on exact name
>
> i somethimes think...(in fact i always think - but sometimes if i cant find the godo name fast i write worse intentionally not to stop productivity... but i think each time)

eventually i would turn thiw WithKnown into Knowing
(asumming you rad file into ram file in Utf8 knowing input format which you detected by separate function just before

- i dont write comments (unles rare things i just need to note something special, like wikipedia-like fact) so the proper names takes work

środa, 2 sierpnia 2023 o 18:21:37 UTC+2 Scott Lurndal napisał(a):
> fir <profes...@gmail.com> writes:
> >=C5=9Broda, 2 sierpnia 2023 o=C2=A018:00:20 UTC+2 Malcolm McLean napisa=C5=
> >=82(a):
> >> On Wednesday, 2 August 2023 at 16:54:21 UTC+1, fir wrote:=20
> >> > =C5=9Broda, 2 sierpnia 2023 o 17:41:00 UTC+2 fir napisa=C5=82(a):=20
> >> > > wtorek, 1 sierpnia 2023 o 20:17:10 UTC+2 David Brown napisa=C5=82(a):=
> >=20
> >> > > > On 29/07/2023 12:20, Malcolm McLean wrote:=20
> >> > > > > Do people prefer string or enum arguments to functions taking one=
> > of a restricted list of options?=20
> >> > > > > The function I'm writing is=20
> >> > > > >=20
> >> > > > > char *loadasutf8wthknownformat(const char *filename, format, int =
> >*error);=20
> >> > > > >=20
> >> > > > If that is a typical example of your function names, then I recomme=
> >nd=20
> >> > > > you specify the format in Greek but written using the ancient Mongo=
> >lian=20
> >> > > > writing system, in order to maintain consistency in the legibility =
> >of=20
> >> > > > the code. Maybe get your cat to type it in.=20
> >> > > >=20
> >> > > its not so bad its a mattar of style but the abbreviations=20
> >> > > are problem - abbreviations simply are nonesense to remember=20
> >> > > as you wold need to remember it all and say use one scheme=20
> >> > > globally amnog people but its rather nonsense (unless say=20
> >> > > special ciricumstances, for exampel you erallny need that)=20
> >> > >=20
> >> > > using strightforward kinda heavy/primitive names as i do=20
> >> > > may look heavy and primitive but 'deburdens' you and imo yur=20
> >> > > productivity increase..they are also raw good imo..coz they=20
> >> > > 'infiormational ratio' is simply high=20
> >> > >=20
> >> > > hovever i would not say i have something seriously against=20
> >> > > 'code stylist' who wrote fancy names.. such names give even=20
> >> > > wuite good feeling but the problems are sometimes some other=20
> >> > > 'gothic' flops, mainly those abbreviations and things resembling macr=
> >oprocessor=20
> >> > some could say that my 'mixed' approach (as i use pascal for functions =
> >and c shorts (no 'skipspaces' though) and lowcase_underscores for locals an=
> >d variables its not stylistically to much good as its mixed and sometimes l=
> >ooks liek a salad with a lot of green peas - but it work well, so maybe i c=
> >hosen it more by experimentation how it work than how it look=20
> >> >=20
> >> > c overally has two styles of code itself imo, one is humanistical creat=
> >ive (and here you got a lot of pascal function names) and the second is mor=
> >e optimistation and ram related - on variables with underscores) and it is =
> >also seen here as lots of my code are lot of pascal and few optimisation ro=
> >utines are lot of underscores.. you maty say its uncoherent but those two t=
> >ypes of codes are uncoherent with each other..writing humnistic code with u=
> >nderscores im not sure as to this, writing opt-code with camels more ok but=
> > underscores fit=20
> >> >
> >> If whitespace is disallowed, humans prefer names which are simply concate=
> >nated. Computers find=20
> >> it easier to deal with underscores.
> >
> >you mean humens prefer
> > char *loadasutf8wthknownformat(const char *filename, format, int *error);
> I prefer
>
> char *load(const char *filename, format_t input format, error_t *error);
>
>
> char *result = load(argv[1], F_UTF8, &error);
> if (error != SUCCESS) {
> fprintf(stderr, "Unable to load '%s' when interpreting as UTF-8", argv[1]);
> return LOAD_FORMAT_FAILURE;
> }

bad (..what is wrote is imo the best of what was mentioned )

On 02/08/2023 15:30, Paul N wrote:
> On Tuesday, August 1, 2023 at 7:17:10 PM UTC+1, David Brown wrote:
>> On 29/07/2023 12:20, Malcolm McLean wrote:
>>> Do people prefer string or enum arguments to functions taking one of a restricted list of options?
>
>>> It's easier to print out a human-readable diagnostic at runtime.
>
>> That makes no sense. Just have a const array of strings indexed by your
>> enumeration. (It's a little more complex if you allow combinations of
>> enum flags.)
>
> I beg to differ. Suppose you are accidentally using an older version of the function than you think you are. If you pass in an enum which is out of range, all the function can do is say what the value of the enum is, which the user may not immediately recognise. On the contrary, if you pass in a string saying the option, the function can print the string and say it is not a recognised option. Of course there are pros and cons to both approaches, but Malcolm's point makes sense.
>

If only there were a way to avoid that kind of problem. What we really
need is a way to have a common piece of code - a "header" file, if you
will - where you could put function declarations and enum declarations
all in one place. Then you could "include" that file in C files that
define your functions, and in C files that use the functions, and have
everything automatically consistent!

Maybe we could go even further, and /document/ the functions and types?

On 02/08/2023 18:00, Malcolm McLean wrote:

> If whitespace is disallowed, humans prefer names which are simply concatenated.

You do not speak for humanity.

On Wednesday, 2 August 2023 at 17:21:37 UTC+1, Scott Lurndal wrote:
> fir <profes...@gmail.com> writes:
> >=C5=9Broda, 2 sierpnia 2023 o=C2=A018:00:20 UTC+2 Malcolm McLean napisa=C5=
> >=82(a):
> >> On Wednesday, 2 August 2023 at 16:54:21 UTC+1, fir wrote:=20
> >> > =C5=9Broda, 2 sierpnia 2023 o 17:41:00 UTC+2 fir napisa=C5=82(a):=20
> >> > > wtorek, 1 sierpnia 2023 o 20:17:10 UTC+2 David Brown napisa=C5=82(a):=
> >=20
> >> > > > On 29/07/2023 12:20, Malcolm McLean wrote:=20
> >> > > > > Do people prefer string or enum arguments to functions taking one=
> > of a restricted list of options?=20
> >> > > > > The function I'm writing is=20
> >> > > > >=20
> >> > > > > char *loadasutf8wthknownformat(const char *filename, format, int =
> >*error);=20
> >> > > > >=20
> >> > > > If that is a typical example of your function names, then I recomme=
> >nd=20
> >> > > > you specify the format in Greek but written using the ancient Mongo=
> >lian=20
> >> > > > writing system, in order to maintain consistency in the legibility =
> >of=20
> >> > > > the code. Maybe get your cat to type it in.=20
> >> > > >=20
> >> > > its not so bad its a mattar of style but the abbreviations=20
> >> > > are problem - abbreviations simply are nonesense to remember=20
> >> > > as you wold need to remember it all and say use one scheme=20
> >> > > globally amnog people but its rather nonsense (unless say=20
> >> > > special ciricumstances, for exampel you erallny need that)=20
> >> > >=20
> >> > > using strightforward kinda heavy/primitive names as i do=20
> >> > > may look heavy and primitive but 'deburdens' you and imo yur=20
> >> > > productivity increase..they are also raw good imo..coz they=20
> >> > > 'infiormational ratio' is simply high=20
> >> > >=20
> >> > > hovever i would not say i have something seriously against=20
> >> > > 'code stylist' who wrote fancy names.. such names give even=20
> >> > > wuite good feeling but the problems are sometimes some other=20
> >> > > 'gothic' flops, mainly those abbreviations and things resembling macr=
> >oprocessor=20
> >> > some could say that my 'mixed' approach (as i use pascal for functions =
> >and c shorts (no 'skipspaces' though) and lowcase_underscores for locals an=
> >d variables its not stylistically to much good as its mixed and sometimes l=
> >ooks liek a salad with a lot of green peas - but it work well, so maybe i c=
> >hosen it more by experimentation how it work than how it look=20
> >> >=20
> >> > c overally has two styles of code itself imo, one is humanistical creat=
> >ive (and here you got a lot of pascal function names) and the second is mor=
> >e optimistation and ram related - on variables with underscores) and it is =
> >also seen here as lots of my code are lot of pascal and few optimisation ro=
> >utines are lot of underscores.. you maty say its uncoherent but those two t=
> >ypes of codes are uncoherent with each other..writing humnistic code with u=
> >nderscores im not sure as to this, writing opt-code with camels more ok but=
> > underscores fit=20
> >> >
> >> If whitespace is disallowed, humans prefer names which are simply concate=
> >nated. Computers find=20
> >> it easier to deal with underscores.
> >
> >you mean humens prefer
> > char *loadasutf8wthknownformat(const char *filename, format, int *error);
> I prefer
>
> char *load(const char *filename, format_t input format, error_t *error);
>
>
> char *result = load(argv[1], F_UTF8, &error);
> if (error != SUCCESS) {
> fprintf(stderr, "Unable to load '%s' when interpreting as UTF-8", argv[1]);
> return LOAD_FORMAT_FAILURE;
> }
>
The three errors that are likely are out of memory, IO (usually can't open the file
because it is locked or doesn't exist, but can be a problem with the backing store
device), and parse error. Which is why you need an error parameter. Often just
:failed to load file" isn't informaitve enough for the user.

On 02/08/2023 17:52, Malcolm McLean wrote:
> On Tuesday, 1 August 2023 at 19:17:10 UTC+1, David Brown wrote:
>> On 29/07/2023 12:20, Malcolm McLean wrote:
>>> Do people prefer string or enum arguments to functions taking one of a restricted list of options?
>>> The function I'm writing is
>>>
>>> char *loadasutf8wthknownformat(const char *filename, format, int *error);
>>>
>> If that is a typical example of your function names, then I recommend
>> you specify the format in Greek but written using the ancient Mongolian
>> writing system, in order to maintain consistency in the legibility of
>> the code. Maybe get your cat to type it in.
>>
> There's a case for folding it into loadasutf8() and passing in a null or "automatic"
> format parameter to indicate that the function should resort to automatic
> detection. However once we have the "load with known format" function,
> we can write loadasutf8(), unknown format, on top of it, which might be more
> logical.
>

There are a dozen ways to do better than the monstrosity you have above.
Pick whatever suits you.

On Wednesday, 2 August 2023 at 17:28:39 UTC+1, David Brown wrote:
> On 02/08/2023 18:00, Malcolm McLean wrote:
>
> > If whitespace is disallowed, humans prefer names which are simply concatenated.
> You do not speak for humanity.
Experiments have been done. I can't remember the references off the top of
my head.