Yeah, the regexes are a huge challenge. Basically, what happens is that after you hang out here for a while, you'll see patterns that we use over and over. So you can treat those as templates (either just in your head, or literally with some kind of notepad/userscript/tool) to fill out when needed.
And then, if you really hang out long enough, you'll actually learn what the templates/patterns mean, and you'll end up finding that you've gotten a lot more knowledgeable about regexes.
Generally we try to be rather specific and, ideally, performant because of how many we subject every post that comes in to. We have an absolutely unholy number of them. It's kinda wild.
@Jesse So... the problem with that is that it needs the "@gmail.com" part, otherwise it'd likely result in too many false positives (because it would match anything containing "guru[\W_]*technical"). Since this is a specific email address, they aren't going to be able to mix and match it with different spacings, so there's little benefit in having that variability included.
@Jesse Ah, well, that definitely helps a lot!
We want them to be perfectly specific, so that they match exactly what they're supposed to match, but no more. :-)
If you see another spam post where they've got something like "gurutechnicaly" or "gurutechnicalxy", then the existing regex should be updated to make it less specific and enable it to match those new variations.
@CodyGray I did include the "@gmail.com" part. I know they can't very easily change the email address, but it is gmail so they could very easily create a new one with slight variations. Maybe I'm thinking too far into the future but that's what I was aiming for with that.
@CodyGray To be clear: It's not harmful to do so, but may throw some people for a loop when they go back to look at a particular expression, because what they'll be expecting to see is the i flag being turned off, because that's a common pattern.
@CodyGray Ohh you're saying the expression shouldn't require the "@gmail.com" part. Okay that makes sense.
Right, so the "@gmail.com" part should be optional, but if I were to do that then my expression would result in too many false positives to be viable. I got it. Just had to think about it a bit ;)
Yes, exactly. There are many ways that someone might obfuscate an email address, but most of the time, it won't include obfuscating the name portion. So making the "@gmail.com" part optional would catch the majority of those, without being overly generic and thus too much of a pain to type in or risking too many false positives.
There are, occasionally, cases where someone will show a willingness to obfuscate the heck out of an email address (e.g., guru technical x 'at' g m a i l 'dot' com), so we need to get a more complicated regex to account for that. But we don't usually jump to that unless there's a demonstrated need for it, because keeping things simple is usually better.
But note that even if they do gurutechnicalx 'at' g m a i l 'dot' c o m, we'd still catch that by making the "@gmail.com" part optional. Also, people tend to reuse the same name for other services, so if they happen to have the Twitter handle "gurutechnicalx", then a regex matching that with the "@gmail.com" part optional would catch that, too.
Granted, a lot of it is bordering on pure speculation, but informed by a history of doing this. There's rarely a "right" and "wrong". Sometimes you just have to submit the watch and... watch it a while.
Alright. So to recap: make the expressions very specific and adapt them as needed. Make them performant because there's a lot of them, and if you include platform-specific signatures such as prefixes or postfixes, make them optional.
You shouldn't worry too much about performance. The main thing to keep in mind with respect to performance is not to introduce any extreme pessimizations, like catastrophic backtracking. In general, though, regexes should be written to match what you want them to match, not sacrificing that in the interest of performance.
If there are two equivalent ways (or nearly-equivalent ways) to write an expression, one that is reasonably performant and another that's not, obviously choose the one that's more performant.
But yes, making it specific and adapting it if/when necessary (as more evidence is accumulated) is generally the best strategy, unless you have a specific reason to believe that the additional flexibility is going to be useful.
@Jesse That pattern looks like it's already caught by Potentially bad keyword in body and Potentially bad keyword in answer Append -force to the command word(s) if you really want to add the pattern you provided.
@IanCampbell Would this be considered spam? I personally don't see a reason to consider the included link as undisclosed affiliation. It doesn't quite answer the question, but given that I think it would probably be NAA. What's your thought process here? Just curious.
@Jesse The user disclosed an affiliation in their software recommendations answer. The combination of posts makes it clear they are only interested in promoting the website.
It makes sense, but I thought that possibly SD had been given GH permissions to also reject PRs by other GH users (I have privs to approve/reject PRs, but I wasn't sure if that applied to PRs by other users or just SD)
Oh whoops that's me. Does anyone know why that URL was flagged? I thought it was the official publisher for the manga based on the info in the first link I added to the answer
@Laurel The reason that was caught was "potentially bad ASN for hostname". That detection reason is definitely going to have some false positives. It doesn't necessarily mean that that's not the official publisher. The domain name itself was not watched.
@CodyGray That pattern looks like it's already caught by Potentially bad keyword in body and Potentially bad keyword in answer Append -force to the command word(s) if you really want to add the pattern you provided.
@Mast Yes, I was also able to figure out that the most convenient way for me to find out would be to ask them. However, this is not necessarily the most convenient thing for them, and since it's not really that big of a deal, I decided to do nothing. The watch is valid/correct and should stay in place, so no action is needed.
@tripleee That pattern looks like it's already caught by Potentially bad keyword in answer and Potentially bad keyword in body Append -force to the command word(s) if you really want to add the pattern you provided.
@tripleee That pattern looks like it's already caught by Potentially bad keyword in answer and Potentially bad keyword in body Append -force to the command word(s) if you really want to add the pattern you provided.
@CodyGray That pattern looks like it's already caught by Potentially bad keyword in answer and Potentially bad keyword in body Append -force to the command word(s) if you really want to add the pattern you provided.
@cocomac my recollection is that the Gas Mask script would also block images in FIRE dialogs, if that's what you mean
I don't currently use it and I know some refactoring was done to FIRE in the meantime but AFAICT it should still work the same; after all, the image links are the same
@JiminyCricket. I could be wrong, but I believe that happens when a user gives the first feedback on an MS report, triggering a chat message, they clear the feedback, and then someone else gives feedback on the same report, which triggers it a second time (as the original feedback is cleared)
@CodyGray That pattern may be a North American number. If it is, please use a format which starts with an optional 1 followed by possible separator text and has the main number in the format 998-866-7918 where - could be a single alpha character or any [\W_]*+. Alternately, you can add the comment (?#IS NorAm) to the end of the pattern to force also using the alternate normalized form, or (?#NO NorAm) if it's not a North American phone number and it's incorrectly recognized as one. Perhaps try !!/watch-number 998-866-7918. Append -force to the command word(s) if you really want to add the pattern you provided.
@cocomac That would explain it. We've seen it before, didn't quite know what to make of it so elected to just be watchful. Seems like normal behaviour in that case. No worries, thanks for telling.
[ SmokeDetector | MS ] Bad keyword in body, bad keyword in title, blacklisted website in body, pattern-matching product name in body, pattern-matching website in body, +1 more (483): Prime CBD Gummies Reviews by primecbdgummiesget on stackoverflow.com
[ SmokeDetector | MS ] Bad keyword with email in answer, link at end of answer, potentially bad ns for domain in answer, potentially bad keyword in answer (149): UK postcode validator by Parry on stackoverflow.com
