I posted this answer to a question where someone was trying to use regex to parse Html. The question was "How can I get my regex to work?" and my answer was "Don't use regex, use this instead".
Should I have posted my answer as a comment?
I posted this answer to a question where someone was trying to use regex to parse Html. The question was "How can I get my regex to work?" and my answer was "Don't use regex, use this instead".
Should I have posted my answer as a comment?
IMO, no. You can sometimes best help a user by solving the problem they're trying to solve (parsing HTML) rather than the problem they think they're trying to solve (parsing HTML with regex). Some users get self-righteous about it and downvote your answer, but you're not the asker's slave; you don't need to bow to their every whim, especially if there doesn't seem to be a good reason for needing to use a particular tool or method.
Post what you think is best for the problem at hand. I've found I get rewarded for it more often than I am punished. Just don't come across arrogant, of course! No "That's dumb" or anything :P
Yes, you should have posted your comment as a comment.
Better would be to answering how to solve this the way as the OP asked whenever possible and then at the bottom of the answer subtly remark it as an unrelated note that there are much better alternatives to the solution the OP is trying to use and elaborate it as well.
If it's not possible or not easily possible at all, then you should elaborate that part in detail as well. Just saying "Don't use solution X, you should use solution Y" without further elaboration is IMO not an answer, but more a comment. In your case, try to explain in detail why parsing HTML with regex is an insane solution. Although your answer is understood by the community, it might not be understood by the OP.
Both yes and no answers have already been given to this question; the only thing left to say is, it depends.
It can be either extremely helpful or extremely frustrating to be told, "Don't do it like that; do it like this." It can be liberating to know that there is not only a better clunky way, but a smooth, powerful, easy way. However, sometimes a user is already aware of the better way of doing things, but doesn't have that as a possibility.
For example, where I work, I am not able to install software on my computer; indeed, the computer where I do most of my work is not even connected to the internet. Thus, when I ask Vim questions, for example, answers that tell me to just download and install some plugin are helpful if I ever run into the same issue at home, but don't help me at all at work. I really just do want the quick 'n' dirty solution at work because I don't have another option.
So my advice is, make sure the user is aware of the better way of doing it, but be careful with how you phrase it. This:
If you have the option, doing it like [alternative solution] would be must better than the approach you are heading towards, because of [well-explained reasons]. If there is something that is prohibitive about the better solution in your case, tho, you can do what you are trying to like [explanation].
is a much, much better answer than:
Don't use X. Use Y instead.
I just read Chichiray's answer more carefully and realized that says some very similar things, even though he began by saying "no". I didn't plagiarize, I promise.
Some things to ask yourself:
For 1., you might be able to determine that one of those cases is true.
But for the wider audience (2.), you have to assume that there is a distribution. Perhaps some people have to use regex, whereas others just don't know that there are other options available.
A good answer, imo, addresses both audiences:
Maybe you don't have time or capacity to address the full range of these two aspects, but still want to contribute. I guess it is ok if some people focus on the first aspect, and others focus on the second aspect, so visitors can extract the information they need from different answers.
Still I think an ideal answer would attempt to cover the full range.