(I think this is my first post on meta, please excuse me while I proudly step on other people's toes.)
Am I wasting my time writing detailed explanations?
I'd like to say no, since explanations are obviously a good thing in general and I like to believe that I usually explain things in great detail as well... but I also understand the other side, that sometimes, maybe it's just too much.
Allow me to elaborate a little.
When I see shrubbery like "\""
or spaceship like /,",\
, then yes, it takes me a bit to parse that, despite knowing what $
, /
, &
mean. The lack of syntax highlighting doesn't help much either, it's all a single shell string in the end — someone please come up with a way to highlight such encapsulated codes anyway.
So yes, this may be a little difficult to understand at a glance. Some explanation would probably be nice. But is it mandatory? And which level of detail would be appropriate?
How deep down the rabbit hole do you go when trying to explain every little thing? Do you have to explain that .
matches any character every single time you do anything remotely related to regular expressions? I think that might be what Ed Morton was referring to with the $1+1
example. If you even explain that $1
is the first field, you might just be overdoing it a little. By the way, you forgot to explain why the ,
had to be added back - of course, it's because the -F,
ate it. Although it's great to explain such things down to the smallest detail, just where does it end?
For an explanation, the general idea should be enough (and too much detail might even distract from it). Quote the first argument ($1="\""$1"\""
), quote each letter of the second argument (gsub(/./,",\"&\"",$2)
). End of story. No need to be long-winded and probably no one cares about how exactly it does that anyway (and they could research, or ask a dedicated question about it, where rabbit-hole level of detail is expected).
All answers here are given for free and you can't force other people to change their style to yours. I see the answer got downvoted already and I think it's a bit unfair.
Given a choice between a good answer with no explanation whatsoever, and no good answer at all, I'll take the good answer and thank you very much. Demonstrating input and output is already very good, and is also part of documentation - some of the others didn't even do that. Additional explanation would be the cherry on top, sure, but in the context of this question it's not mandatory.
If people started adding things to my answers (in a way that does not agree with my own style, and the way I explain and demonstrate things), I might feel inclined to remove it as well and feel in my rights to do so. You can always post your own answer, after all.
awk '{print $1+1}'
and that causing the "possibly low quality" tool to flag it as such for being code only and then some queue-jockey (not you) with no idea about the domain coming along and saying "your answer could be greatly improved if you comment it..." and then it initially getting downvotes from the other queue-jockeys. Meanwhile someone else writes an answer that's war-and-peace but complete nonsense and it doesn't get any negative responses.&
does in the second argument togsub
. And don't say it's easy to look up, special characters are notoriously hideous to search for in manuals.)@
,i
and tab should make it much easier to enter my nick correctly, and entering it correctly would have the advantage that it would actually ping me, which is pretty much the main point of using @ + usernameI can only agree that you seem to care very little about others
- as you know, that's not what I said. I won't be responding further.