Re: question about linker

On 03/12/2024 02:23, Tim Rentsch wrote:

scott@slp53.sl.home (Scott Lurndal) writes:
 

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>

On 01.12.2024 17:42, Bart wrote:
>

On 01/12/2024 15:08, Janis Papanagnou wrote:
>

On 01.12.2024 12:52, Bart wrote:

>
makes typing easier because it is case-insensitive,

>
I don't think that case-insensitivity is a Good Thing.  (I also don't
think it's a Bad Thing.)

>
I think it's a _real bad thing_ in almost every context related
to programming.

 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.
 

I would agree on that.
I would not say that it is often a good idea to have identifiers which differ only in letter case - but it is not entirely unreasonable if a particular coding standard and naming convention supports it (such as naming your types "Foo" and allowing local declarations "Foo foo;").
On the other hand, I would say it is very definitely a bad idea if different capitalisation is used for the same identifier in different parts of the code - it makes it a lot harder to read and easier to get wrong.  I am happy that most of the languages I use are case-sensitive.

But I want my software maintainable and readable.  So my experience
is that I want some lexical "accentuation";  common answers to that
are for identifiers (for example) Camel-Case (that I used in C++),
underscores (that I use in Unix shell, Awk, etc.), or spaces (like
in Algol 68, but which is practically irrelevant for me).

>
CamelCase reduced typing speed and adds little benefit when compared
with the alternatives (rational abbreviations, or even underscores).

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

I use camelCase sometimes, but I find myself using underscores a lot more in recent times.  It is, I think, an eye thing - strangely, my eyes have got older over time, and the legibility of identifiers has become more important to me!

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

A general guideline followed by most people is to have the length of identifiers (or their semantic content) increase with larger scope of the identifier.  "i" is fine as a counter of a small loop, but you would not want to use it for a file-scope static.
Which abbreviations are appropriate is often context-dependent.  As long as the context is clear, they can be very helpful - in a genetics program, you would definitely want to use "DNA_string" in preference to "deoxyribonucleic_acid_string" as an identifier!
But I dislike it when people use things like "indx" for "index" or "cnt" for "count".