Re: question about linker

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