Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #171393 > unrolled thread

strings or enums?

Back to article view | Back to comp.lang.c

Contents

  strings or enums? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-29 03:20 -0700
    Re: strings or enums? fir <profesor.fir@gmail.com> - 2023-07-29 06:43 -0700
      Re: strings or enums? fir <profesor.fir@gmail.com> - 2023-07-29 07:21 -0700
        Re: strings or enums? fir <profesor.fir@gmail.com> - 2023-08-02 13:45 -0700
    Re: strings or enums? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-29 21:35 +0100
      Re: strings or enums? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-30 08:28 -0700
        Re: strings or enums? Richard Damon <Richard@Damon-Family.org> - 2023-07-30 12:19 -0400
        Re: strings or enums? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-30 18:09 +0100
          Re: strings or enums? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-30 11:00 -0700
            Re: strings or enums? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-30 20:15 +0100
              Re: strings or enums? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-31 04:23 -0700
    Re: strings or enums? David Brown <david.brown@hesbynett.no> - 2023-08-01 20:16 +0200
      Re: strings or enums? Paul N <gw7rib@aol.com> - 2023-08-02 06:30 -0700
        Re: strings or enums? David Brown <david.brown@hesbynett.no> - 2023-08-02 18:26 +0200
          Re: strings or enums? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2023-08-02 13:34 -0400
            Re: strings or enums? David Brown <david.brown@hesbynett.no> - 2023-08-02 23:50 +0200
      Re: strings or enums? fir <profesor.fir@gmail.com> - 2023-08-02 08:40 -0700
        Re: strings or enums? fir <profesor.fir@gmail.com> - 2023-08-02 08:54 -0700
          Re: strings or enums? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-02 09:00 -0700
            Re: strings or enums? fir <profesor.fir@gmail.com> - 2023-08-02 09:14 -0700
              Re: strings or enums? scott@slp53.sl.home (Scott Lurndal) - 2023-08-02 16:21 +0000
                Re: strings or enums? fir <profesor.fir@gmail.com> - 2023-08-02 09:23 -0700
                  Re: strings or enums? fir <profesor.fir@gmail.com> - 2023-08-02 10:00 -0700
                Re: strings or enums? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-02 09:28 -0700
              Re: strings or enums? fir <profesor.fir@gmail.com> - 2023-08-02 09:22 -0700
            Re: strings or enums? David Brown <david.brown@hesbynett.no> - 2023-08-02 18:28 +0200
              Re: strings or enums? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-02 09:30 -0700
                Re: strings or enums? fir <profesor.fir@gmail.com> - 2023-08-02 10:04 -0700
                  Re: strings or enums? fir <profesor.fir@gmail.com> - 2023-08-02 10:07 -0700
                Re: strings or enums? David Brown <david.brown@hesbynett.no> - 2023-08-02 23:54 +0200
                  Re: strings or enums? Vir Campestris <vir.campestris@invalid.invalid> - 2023-08-05 11:47 +0100
                    Re: strings or enums? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-05 09:45 -0700
      Re: strings or enums? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-02 08:52 -0700
        Re: strings or enums? David Brown <david.brown@hesbynett.no> - 2023-08-02 18:29 +0200

Page 2 of 2 — ← Prev page 1 [2]

#171536

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;
   }

[toc] | [prev] | [next] | [standalone]

#171538

ś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 )

[toc] | [prev] | [next] | [standalone]

#171545

ś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)

[toc] | [prev] | [next] | [standalone]

#171542

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.

[toc] | [prev] | [next] | [standalone]

#171537

ś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

[toc] | [prev] | [next] | [standalone]

#171541

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.

[toc] | [prev] | [next] | [standalone]

#171544

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. 

[toc] | [prev] | [next] | [standalone]

#171546

ś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

[toc] | [prev] | [next] | [standalone]

#171547

ś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

[toc] | [prev] | [next] | [standalone]

#171556

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.).

[toc] | [prev] | [next] | [standalone]

#171669

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

[toc] | [prev] | [next] | [standalone]

#171687

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.

[toc] | [prev] | [next] | [standalone]

#171528

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.

[toc] | [prev] | [next] | [standalone]

#171543

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.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web