[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Is there a POSIX compliant way of turning a "HH:MM:SS" formatted string to seconds? ...



On 2025-07-21 at 08:04, Greg Wooledge wrote:

> On Mon, Jul 21, 2025 at 13:37:33 +0200, Michael wrote:
> 
>> iirc, i think i have read in your wiki to NOT have variable names
>> with leading underscores...
> 
> If you restrict yourself to never using variable names beginning with
> _ in normal situations, then that gives you the opportunity to use
> it as a pseudo-namespace delimiter in this unusual situation.
> 
> I'm not sure which page you're referring to specifically, but
> generally the convention is that if you begin a variable name with _
> then it has some special meaning or significance, which is up to you
> to define. The basic idea is that if you create a variable name of
> this form, you can be fairly confident that it doesn't collide with
> anything, but this only works if you follow a consistent convention.
> 
> If *all* your variable names begin with _ then you're just a
> lunatic. (Yes, I've seen people do this.  No, I have no clue why.)

I have two potential guesses: one, it provides a type of indication that
this *is* a variable, and two, it provides a visual separation of the
*name* part of the variable from the syntactic $ prefix. The latter can
be valuable for some people's ways of experiencing and interacting with
code.

I gather that some projects name C-preprocessor macros with a leading
underscore for that latter reason, specifically so that when you define
them on the command line it comes out as '-D_MACRO_NAME' rather than
'-DMACRO_NAME'; the former is, at least slightly, more readable than the
latter.

My totally unfounded understanding is that this latter may be where the
use of underscore as a prefix for identifiers comes from in the first
place.


And, of course, in code that might wind up including headers (etc.) from
the Linux kernel, identifiers beginning with *two* underscores are
(officially, AFAIK, or as officially as any of this gets) reserved for
use *by* kernel code; non-kernel code should never try to set one.

I *hope* that doesn't apply for anything shell-based, but at this point
in my experience I'm reluctant to rule anything *out*.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: