Basic concept: the purpose of regex is to search input text for matching patterns of characters.

Assuming this is correct (including the spaces):

/ ^(\d{3}) - (\d{2}) - (\d{5}) \2 \1$ / g

Then:

/ The first forward slash is the delimiter which tells the code that this is the start of the regex (start interpreting the expression after this).

^ The caret marks the beginning of the text string being searched for a match or the beginning of a line of text, meaning that any matches found by the following regex must begin at the beginning of the input text, or at the beginning of a new line of text, not somewhere in the middle of it.

(\d{3}) This is the first group for matching actual text characters. The \d matches any single digit (0-9). The {3} attached to it means that there must be exactly 3 digits adjacent to each other, no more, no less.

_-_ (underscore indicating that there is a space in the original expression) This must match a [space][dash][space] as literal characters.

(\d{2}) As before, this matches two adjacent digits. This is the second matching group.

_-_ Same as above, [space][dash][space].

(\d{5}) Same as the two patterns before, this matches five adjacent digits. This is the third group.

_\2 The [space] here matters, indicating that there must be a space character between the previously matched group of five digits and the following match group \2, which says to match the same text as the most recently matched 2nd group. In this case the second group would be (\d{2}), so this must match the same two digits as were matched by (\d{2}) in the same order.

_\1 Similar to the above, this must match a [space] and then the same text as the first most recently matched group. In this case that would be the (\d{3}).

$ This is the same as the ^, only it matches the end of the input text or the end of a line of text. This means that there cannot be any more characters in the input text after the last characters that match the specified pattern.

/ g The / is again a delimiter, indicating the end of the regex. The g means "global", which instructs the code to search the entire input text for all possible matches and return all of them at the end of the search (default regex behavior is to search until the first match, then stop and return that result).

So example matches would look like this:
111 - 22 - 33333 22 111
012 - 01 - 01234 01 012
987 - 98 - 98765 98 987

But this would not match:
11 - 222 - 33333 222 11 (incorrect numbers of digits in the first and second groups)
012 - 01 - 01234 10 012 (the second group of 2 digits does not match the first group of 2 digits)
987-98-9876598987 (spaces are missing)
111 22 33333 22 111 (dashes are missing)

Speculation:
The matched string looks like a serial number or part number or something like that, so probably the use case for this regex is to search through a file containing a long list of such numbers all separated on new lines of text, to find specific ones (for some reason). Maybe numbers that match this pattern are invalid, or maybe only numbers that match this pattern are valid and everything else that might be in the file needs to be removed.

Based on this I think the end is actually wrong and should be / gm (m for multi-line) to allow for searching (and returning) multiple lines of input text. Otherwise, this should be part of code which splits the lines of the input text file into individual strings and then feeds them through the regex one at a time - but if that's the case then using the g (global) flag doesn't really make sense.

With thanks to https://regex101.com/

no

this inspired me to make another shitty meme here u go enjoy: https://lemmy.cafe/post/36565281

Is there a version of regex with comments?

I mean one would typically insert it as a literal in another language but if there are flexible macros it could be done without any runtime cost/standard reinventing.

maybe it says “Regex lol”

Are you thinking of lookarounds? Backreferences do have some performance impact but a lookahead or lookbehind much more so. That definitely breaks the regularity, but I'm not sure that applies to backreferences (which may be my own ignorance). Performance wise unmatched lookarounds are the least performant getting worse as the size of the corpus increases. A positive lookahead/lookbehind has to scan all the text before or after the assertion to determine match failure and likewise negatives must do the same to determine match success. Greedier matching also amplifies things here (do you want just the first match or all of them?)

I'm more fluent in regex syntaxes than in the implementation details of any specific regex engine, so please correct me if you know Im wrong, both for my own edification and so that when I share things going forward Im sharing the most accurate information that I can.

This is a cool feature of a lot of regex implementations but I will warn you that reusing capture groups in a match means it's impossible for any regex engine to guarantee a reasonable upper bound (best they can do is O(n!) I think? I'd have to look up the details). In a replacement string this is a non-issue because there's no way they can recurse out of control.

Edit: found the video I originally heard this from: https://www.youtube.com/watch?v=gITmP0IWff0

yay you’re welcome!

That's not a problem at all. Most programmers don't understand regex as well

you will find regex in numerous things that have nothing to do with writing code. i don't even need to leave firefox to find several instances in the addons i have installed.

I just ask an LLM if I ever need to create a regex query. Which is almost never hence I don’t understand regex. Many programmers don’t understand regex. Like when do you ever need regex if you program a game engine.