I personally don't because I'm the only one in my household that uses linux and the only one that uses the scripts. Since I wrote them, I know what each statement does.

How about you?

No-one else will be looking at my scripts either so I don't use many comments. I do use them from time to time though because I know an older version of me will be looking at the scripts, a version of me who might not quite remember how some of the more logically obtuse code came about. So I do add some comments to help the future me.

1 members found this post helpful.

Yes, but I write fewer comments when they are my own scripts and more when I write scripts for others. Usually I try to answer why something is done a particular way or what the overall goal is. I figure months down the road I will have forgotten. When writing scripts for the others, I usually explain more decisions.

2 members found this post helpful.

Comment the whys not the whats. You can usually see the whats by reading the code. Whys tend to be less obvious, especially with the passing of time as hydrurga as already pointed out.

Only comment the whats if it adds value. No need to be Captain Obvious.

1 members found this post helpful.

No comment, if I no longer understand the code, I rewrite the script

Yeah, I write comments.

Sometimes they're temporary. I often write out what I want in text, then fill in the program with code. Sometimes my comment looks like a Haskell type signature, because that can be a useful tool. I usually delete these little notes later after they've served their purpose. It's "Comment-Driven Development" to go along with my testing practices.

Sometimes they describe some set of things I'm likely to forget. I can't keep much Bash or sh syntax in my head, so I'll comment it with something a little more descriptive. Writing things out helps me remember things better, so it's a positive practice in either case. I have a script in which I do something that's sort of "bad" shell practice, and the linter I like picks it out right away, so I've got it commented why I did that particular part so I don't later fix and/or break my own program.

And sometimes they record the frustrations of the moment.

Considering how hard-to-read BASH string manipulation and regular expressions are? Absolutely.

1 members found this post helpful.

Almost always. At a minimum, I'll add a "header" with create date -- or update date-- and a one-liner describing the function or change.

I once worked in a shop that required a comment on every line of code (this wasn't bash,tho):
Something broke, and the junior programmer couldn't figure out what was wrong. When I got back from vacation, we discovered that he'd been reviewing the comments, not the code, so he couldn't see the bug in the code...the comment was correct.

Oh, yes!

The other day I found a bug in a program (not bash) I'd written about 30 years ago: thousands of lines and not one comment.
Faced with things in the offending procedure like
I was left muttering "53? What the %#@&?" I fixed it eventually, but I really wish I'd had a time machine that day!

1 members found this post helpful.

If it's worth writing, it's worth commenting.

Daniel B. Martin

.

1 members found this post helpful.

Like Myk267 I write in the comments what I want to achieve, why and how and then I code. If I have to think 20 minutes about how to write something less obvious, I am sure I have to spend that 20 minutes again one or two years later and try to understand what I did.

Disposing of code and re-writing it is just plain stupid. It means that the first time you spend thinking about it, and the debugging time is lost. And you have to spend again that time thinking and debugging.

This is, of course, not true if you inherit some non-documented bash scripts. You could better rewrite because there is always the risk you misunderstand non-documented code.

And the power of bash code obfuscation approaches that of C.

jlinkels

20 minutes to write bash code?
At this point, I'd switch to another language, there is no need to spend lifetime to write scripts imho.
Bash is cool but if script uses too much workarounds to acheive something, I am sure there is another language better suited for the task

i comment.
http://www.catb.org/esr/writings/uni...s/prodigy.html

3 members found this post helpful.

While I understand what "if statements", etc do and are for; I'm for all intensive purposes quite a n00bie when it comes to coding (be that bash scripts, C, what-ever), and given I've very recently started trying to learn C, then yes, comments at this point really help. Otherwise unless it's just a simple list of commands, I'm likely to forgot what each line actually does exactly.

So yeah, the more code, the more I need to comment about it.

Yes, I do. Not in every case. If a script truly is simple, and likely also a one-shot, I probably won't. But something I intend to keep around? Absolutely.


Probably because you're the only Linux user, is a better reason to comment them, and especially if they get more complex. But ... it's your choice.