Quote:
Originally Posted by TinWalrus
professionally speaking, from a large shop perspective where there are windows and unix admins who cross train - documenting a script is of high importance. a person with limited unix experience (especially one coming from the windows world) will have a difficult time understanding a shell script.
I guess we're way off topic by now, but anyway.
I can certainly understand your reasoning there. I have never come across this situation. I have always worked in environments where one or more people are assigned the task of maintaining a script, but then again I have worked mostly in R&D where the rules about touching code are possibly more restrictive. Having people not familiar with Unix touching the code just wouldn't happen ( unless a trainee under supervision ).
I guess I should clarify my position.
1. I have no objection to the use of && or || in an example like that given by Perderabo, where it is used to perform a compound operations. This should and does read as a single line of code.
I do however have a problem with something like this:
command && { command2; command3 } || { command4; command 5}
Which was what I originally commented on ( the use of braces )
2. I don't have a problem with commenting, I do have a problem with using comments to explain code which which should not need to be explained. If simple logic needs to be explained then the script (or the person reading it
) is in my opinion broken.
Using simple syntax usually means the less commenting is needed, after all an if statement is an if statement irrespective of the syntax of the language used. A person who cannot understand an if/else statement should not be maintaining the code, on the other hand I could forgive someone from having problem understanding the example above. The K.I.S.S. approach has long since proven it's effectiveness.
Quote:
it is also of critical importance to use version control and a central repository, especially if the script is going to be used on multiple systems.
I agree completely, also in support of multi-track development this is essential, changes for one track may not be expected in another.