środa, 2 sierpnia 2023 o 18:23:38 UTC+2 fir napisał(a):
> ś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 )

i mean bad as general naming sometimes in special cirricumstance maybe could be used (but more like 'local' handy function and c dont much support that) (i mean theoretically some may divide code on small compilation units but i dont find it handy)

środa, 2 sierpnia 2023 o 18:30:47 UTC+2 Malcolm McLean napisał(a):
> 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.

dont belive such researches...problem with that is many of thiose researchers study one or few aspects of given thing and things in reality have often whole pack of aspects and somme need to just try to study it in real...
this is btw also pony curse they belive soem aspect of c++ is better then fall into a 10 pits of other aspects they ignored

środa, 2 sierpnia 2023 o 19:05:09 UTC+2 fir napisał(a):
> środa, 2 sierpnia 2023 o 18:30:47 UTC+2 Malcolm McLean napisał(a):
> > 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.
> dont belive such researches...problem with that is many of thiose researchers study one or few aspects of given thing and things in reality have often whole pack of aspects and somme need to just try to study it in real...
> this is btw also pony curse they belive soem aspect of c++ is better then fall into a 10 pits of other aspects they ignored

wel in fact thsi is every bodys curse, i could say i also see soem aspects and dont know a lot other..hovever at least i do not take this kind of 'separate aspect' researches too serious

On 8/2/23 12:26, David Brown wrote:
> 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?
>
​I believe what they are referring to is situations of _linking_, not
compilation.
--
⚗︎ | /blu.mɛin.dʰak/ | shortens to "Hawk" | he/him/his/himself/Mr.
bluemanedhawk.github.io
Bitches stole my whole ass ␔🭖᷿᪳𝼗᷍⏧𒒫𐻾ࣛ↉�⃣ quoted-printable, can't
have shit in Thunderbird 😩

sobota, 29 lipca 2023 o 16:21:43 UTC+2 fir napisał(a):
> 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

this code distribution' or how to call it that also enums make makes them almost not-usable imo (maybe depending on situalion, but when i was using it it was deadly for me and not use it for years, none of my few projects like furia, org-asm, green.fire uses even one enum)

this problem is partially also with structure i guess..you need to jum to definition - hovever its much less for some reason - dont know why, maybe you mat treat structure definition just as a pieco of code, coz structure definition is somewhat like a code.. other thing it is hard to make ad hoc structure (when with enum its natural to have ad hoc enum)

one could define

open struct ship;

and allow to define hields 'adhoc' liek

void foo()
{ ship.x =100;
}

and here you got structure disytibuted but im not sureif this is usable idea...maybe beter is not to define structure at all allowing dods in names and put mehanism to adress groups of varliables like

int ship.x = 10;
int ship.y = 110;
int ship.z = 310;

int ship2.x = 10;
int ship2.y = 110;
int ship2.z = 310;

float dist = distance(ship, ship2); //build structures ad hoc

for longer time i was thinking on this solution but have no final opinion on this its rather good maybe this adhoc building and classic struictures can go in parallel

On 02/08/2023 19:34, Blue-Maned_Hawk wrote:
> On 8/2/23 12:26, David Brown wrote:
>> 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?
>>
>
> ​I believe what they are referring to is situations of _linking_, not
> compilation.
>

Linking comes after compilation. Get the compilation right, then link.
The guy is inventing nonsense problems.

On 02/08/2023 18:30, Malcolm McLean wrote:
> 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.
>

I don't believe you. (I'm not saying you are lying, merely mistaken or
misremembering.)

It is, at best, conceivable that this applies to people whose native
language makes heavy use of concatenation, such as German. And
linguistic studies show that such languages are often harder for
non-native speakers to learn, as well as causing reading and writing
challenges to those that have difficulties already (such as dyslexia,
poor site, low intelligence, etc.).

On 02/08/2023 22:54, David Brown wrote:
> On 02/08/2023 18:30, Malcolm McLean wrote:
>> 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.
>>
>
> I don't believe you.  (I'm not saying you are lying, merely mistaken or
> misremembering.)
>
> It is, at best, conceivable that this applies to people whose native
> language makes heavy use of concatenation, such as German.  And
> linguistic studies show that such languages are often harder for
> non-native speakers to learn, as well as causing reading and writing
> challenges to those that have difficulties already (such as dyslexia,
> poor site, low intelligence, etc.).
>

It's certainly not my experience, and I've never seen a coding standard
that suggests it.

Compare

loadasutf8wthknownformat

with
LoadAsUtf8WithKnownFormat (or loadAsUtf8WithKnownFormat)

or
load_as_utf8_with_known_format

And also think would you spot loadasutf8wthunknownformat?

(I go back far enough to have been stuck with 6 letter uppercase
variables. I never wrote enough ANSI Basic (single letter, or letter
plus 1 digit) for it to matter.)

Andy

Vir Campestris <vir.campestris@invalid.invalid> writes:

> On 02/08/2023 22:54, David Brown wrote:
>
>> On 02/08/2023 18:30, Malcolm McLean wrote:
>>
>>> 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.
>>
>> I don't believe you. (I'm not saying you are lying, merely
>> mistaken or misremembering.) [...]
>
> It's certainly not my experience, and I've never seen a coding
> standard that suggests it.
>
> Compare
>
> loadasutf8wthknownformat
>
> with
> LoadAsUtf8WithKnownFormat (or loadAsUtf8WithKnownFormat)
>
> or
> load_as_utf8_with_known_format
>
> And also think would you spot loadasutf8wthunknownformat?

The idea that the just-concatenate style is widely preferred or
easier to read is completely deranged. And, I am confident, easy
to debunk through objective experimentation.