Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Newsgroups: comp.lang.c
Subject: Re: question about linker
Date: Tue, 3 Dec 2024 16:09:22 +0100
Organization: A noiseless patient Spider
Lines: 59
Message-ID: <vin6v4$4pqq$1@dont-email.me>
References: <vi54e9$3ie0o$1@dont-email.me> <vicque$15ium$2@dont-email.me>
 <vid110$16hte$1@dont-email.me> <87mshhsrr0.fsf@nosuchdomain.example.com>
 <vidd2a$18k9j$1@dont-email.me> <8734j9sj0f.fsf@nosuchdomain.example.com>
 <vidnuj$1aned$1@dont-email.me> <87ttbpqzm1.fsf@nosuchdomain.example.com>
 <vie0j5$1g968$1@dont-email.me> <vieun5$1mcnr$3@dont-email.me>
 <vihamj$2cflq$1@dont-email.me> <vihili$2f79m$1@dont-email.me>
 <vihu63$2ipg0$1@dont-email.me> <vii3kq$2kmc8$1@dont-email.me>
 <vikqvf$3fhce$1@dont-email.me> <jNm3P.7909$XuU6.3431@fx40.iad>
 <86v7w1muem.fsf@linuxsc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 03 Dec 2024 16:09:25 +0100 (CET)
Injection-Info: dont-email.me; posting-host="5d3fa641c223bbbfa1b3a7c0f166a27c";
	logging-data="157530"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1//6n+ZAN6pQhpoPRoEogZ9"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:B64OvlgxwhAGFF2Bzsf085viqr4=
X-Enigmail-Draft-Status: N1110
In-Reply-To: <86v7w1muem.fsf@linuxsc.com>
Bytes: 4328

On 03.12.2024 02:23, Tim Rentsch wrote:
> 
> In my view case-insensitive matching/lookup is clearly worse than
> case-sensitive matching.  There may be some contexts where a
> case-insensitive rule is tolerable or even preferable, but offhand
> I'm not thinking of one.  Of course sometimes I do want matching
> to allow either case, for which 'grep -i' or some other common
> tool solves the problem;  the key is that it's my choice, not
> a fixed choice imposed by a procrustean software system.

These days, where case-sensitive data is normal, the often seen
case-insensitive default for searching is a pain, IMO.

What I'd prefer is; if I search with mixed case terms I want to
get case sensitivity. Or more generally, a deliberate use of the
shift key should be an indication of a case-sensitive search.
(This of course might not be helpful or even bad for folks who
are used to copy/paste with the mouse, where the first character
might just be capitalized to match the locale/language rules.)

> 
> My complaint about CamelCase (or camelCase, which I put in the same
> category) is that my eyes have to work quite a bit harder compared
> to text using underscores between words.  Reading either form of
> camelCase is slower, and also requires more mental effort, relative
> to using underscores. 

That's certainly true. (This would also be an argument in favor
of Algol 68's "identifiers with spaces" feature.)

> Exception:  CamelCase for a short noun phrase
> (up to perhaps three or four words) seems to work well for type
> names, probably because I can recognize the phrase as a whole
> without needing (most of the time) to look at the individual words.
> That property does not hold for names of variables or functions.

We used (I think it was also a common convention) to start class
and type names with a capital letter, all the rest starting with
lower case, with the exception of C-preprocessor elements that we
wrote in all caps (but that we anyway only rarely used in C++).

> 
> For the most part I don't use abbreviations in the usual sense of
> the word, although I do sometimes use short non-words in a small
> local context (here "short" means usually one or two letters, and
> never more than four or five).

Also sensible (and I think quite typical); to consider local and
global visibility, and differentiate technical and semantical
entities. By abbreviations in the previous post I associated also
common abbreviations (XML, SQL, IP) which in case of camel-case
were written like word components (Xml, Sql, Ip).

But much of all that are personal preferences or conventions that
have to be followed for consistency as part of companies' coding
standards.

Janis