Naming conventions (was Re: valgrind leak I can't find)

On 22.08.2024 14:01, Annada Behera wrote:

On Thu, 2024-08-22 at 08:18 -0300, Thiago Adams wrote:

On 22/08/2024 08:01, Bart wrote:

On 22/08/2024 09:41, Mark Summerfield wrote:
>

This is the type's struct:
>
typedef struct {
     int _size;
     int _cap;
     char** _values;
} VecStr;

>
What's with the leading underscores for member names?

A convention. (I.e. one convention amongst dozens.)

>
It means ending with ->_ later on, which seems pointless extra
clutter.

>
>
C++ is responsible for this.

I don't think so. I've seen such conventions in many places, also
very often in C contexts. Even standards use naming conventions.
(This is no valuation. I don't give a valuation. Not yet.)

In C++ I've seen all-caps constant names. (Why? Because C didn't
have constants supported, only CPP elements used as constants,
and that got inherited.) Then '_s' suffixes or 's_' prefixes for
structs. '_t' suffixes for types (typedef entities). 'm_' or '_'
prefixes for class attributes ("member variables"). Conventions
to differentiate function parameters from member variables (for
disambiguity on initialization) or for local function variables.

I've got the feeling that (technical) information that has its
definition already at another (appropriate) place gets merged
into the entities (variables, functions, ...) that (IMO) should
have _semantical_ names, and not something that looks like a C++
name-mangled linker-object-name.

>
C++ made the usage of 'this->' optional when calling member
functions.

I don't think this optionality is (per se) a Bad Thing.

But to disambiguate or make intentions clear the use of 'this' is
certainly (IMHO) better than adding technical name components to
semantical names; you already have a language construct you can use
for that.

>
As a result, when C++ programmers encounter 'i' in the middle of a
function, they might not know where it comes from.

In the early 1990's we had coding standards that handles such;
use of semantical names instead of 'i', locality principle (don't
declare entities "far away" so you easier see where it's from), and
use of explicit language features (like 'this') to make it obvious.
(Maybe there were yet more suggestions - memories are faint.)

>
If 'this->' were not optional, 'this->i' would clarify that.

Indeed.

Only that it can (also) be perceived as "clutter" (to use a name
that Bart above associated already with the much terser '_').

Most programmers I've met are reluctant to type more characters
than "necessary", and - in the absence of standards/conventions -
they seem to prefer using '_' or 'm_' or some such.

>
To avoid confusion, many C++ programmers use prefixes like 'm_' that
can't be ignored.
>
Since many C programmers also work in C++, this pattern can sometimes
influence C code as well.

 
Although I think this is stupid thing to do when writing C, the same
convention also exits in Python PEP-8 [1]
 
    _single_leading_underscore: weak “internal use” indicator.
    E.g. from M import * does not import objects whose names start with
    an underscore.
 
[1]: https://peps.python.org/pep-0008/#descriptive-naming-styles

It's a typical document. With valuations "better" (without rationale)
and "ugly!" (which is nothing but a codified opinion).

There's a lot such documents and yet more existing opinions on naming
conventions than options to choose from. I'm sure everyone has one
and it's not really worth to dispute about that. What individuals do
in their private projects' context is their own business and companies
most likely have their conventions documented. - Ah, but there's also
the standards committees...

Janis