Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: question about linker Date: Mon, 02 Dec 2024 17:23:29 -0800 Organization: A noiseless patient Spider Lines: 49 Message-ID: <86v7w1muem.fsf@linuxsc.com> References: <87mshhsrr0.fsf@nosuchdomain.example.com> <8734j9sj0f.fsf@nosuchdomain.example.com> <87ttbpqzm1.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Tue, 03 Dec 2024 02:23:33 +0100 (CET) Injection-Info: dont-email.me; posting-host="6df3ea726b10ab0f3de7a160d28b993d"; logging-data="3871784"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19Z5uTTNc15KOtJo/VfCBW2QvMNFofatyY=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:cXHY7eI4VqJCrogpkvyMf4V+3PI= sha1:jm+h2MNALh+n//6o1ECfbbmpons= Bytes: 3715 scott@slp53.sl.home (Scott Lurndal) writes: > Janis Papanagnou 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. >> 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. 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).