Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: question about linker
Date: Tue, 3 Dec 2024 19:09:35 -0600
Organization: A noiseless patient Spider
Lines: 117
Message-ID: <vioa4r$f5tr$1@dont-email.me>
References: <vi54e9$3ie0o$1@dont-email.me> <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>
 <vin6em$49d1$1@dont-email.me> <glF3P.41974$tKZd.29258@fx18.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 04 Dec 2024 02:09:48 +0100 (CET)
Injection-Info: dont-email.me; posting-host="9d2238367fe0774028fdf52449d01a5f";
	logging-data="497595"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+O5DdXo1RFRwoA5uIdNTiYJnQ832iXVbw="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:kEudf0cRiJqTVrTPdspZP1UP1cs=
In-Reply-To: <glF3P.41974$tKZd.29258@fx18.iad>
Content-Language: en-US
Bytes: 5317

On 12/3/2024 9:20 AM, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 03/12/2024 02:23, Tim Rentsch wrote:
>>> scott@slp53.sl.home (Scott Lurndal) writes:
> 
>>
>>> 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!
> 
> I agree with both of these.   In addition, when processing
> character strings, I'll often use 'cp' as a character pointer.
> 

Often cs/ct in my case:
   cs: source pointer
   ct: destination pointer
But, sometimes:
   cs: source 1
   ct: source 2

Usually in this case, for pointers that are being used to step over a 
buffer.

May often be used alone, but sometimes with a name suffix:
   csBits, ctBits.

I don't often use underscores in local variables, but are pretty much 
standard in global variable and function naming:


foolib_variableName  //global variables (generic).

foolib_functionName  //private functions (usually DLL/EXE local).
FOOLIB_FunctionName  //semi-public functions (usually DLL/EXE local).
fooFunctionName      //public, part of a formal API (DLL exports).
FooFunctionName      //part of a private API (DLL exports).

Sometimes divided:
   FOOLIB_SubSys_FunctionName: Function belongs to something specific.



Often times, camelCase or first_second is used for things like struct 
members, or a mix of these two.

Except for widely standardized structs like BITMAPINFOHEADER or 
WAVEFORMATEX.

Like, try to rename a member like biCompression or wBitsPerSample or 
similar and see how well that goes...


>>
>> But I dislike it when people use things like "indx" for "index" or "cnt"
>> for "count".
> 
> The use by programmers of the variable name 'index' has, in the past,
> caused issues (primarily due to conflicts with the BSD 'index' function).

We all know it should be 'ix' and 'n'...


Where, except in BGBCC's parser where 'n' was often a prefix for AST nodes:
   nl: Node-Left
   nr: Node-Right
   nv: Node-Value
   nt: Node-Type or Node-Temp
   nc: Node-Current (when walking a node list)
   ...

But, local-variable naming conventions differ notably in BGBCC's 
frontend vs much of the rest of my code.


In most other contexts, 'n' was a prefix that means one is counting 
something, though often with the following character capitalized:
   nElem: number of elements
   ...

And, 'ix' as an index into something.


In a similar way, cs/ct may sometimes be used as prefixes:
   csData, ctImage, ...
When the idea is that one is walking along a data buffer or image.

Then, 'sz' for when specifying the size of something, or 'p' when a 
pointer (that doesn't fit the cs/ct pattern).
   szData
   pData
   ...

Then:
   'l' for a 64-bit long
   'e'/'f'/'g' for scalar floating-point values
   'i'/'j'/'k' for integer counting variables
   's' for strings (eg: "sName")
   ...

Sometimes the suffix is a number (such as 's0'/'s1' for first and second 
string), or (usually in smaller functions) these are used as plain 
identifiers (don't need a suffix on 'n' if there is only a single thing 
being counted).