HI guys I am a novice electronics enginner currently working on DFT ans sythesys. When I came in from college the one thing I though would have help me in the industry was some more experience with scripting. I had fed this back to my college juniors and they have started up on that. Recently they ask me if i could document some best practicies for writing scripts in the EDA industry and I came up the the following article. before I send this to my juniors I would be much obliged if you guys could take a look at it and critisize/review it. Please do keep in mind that this is meant for novice engineers like me and other coming in from college. Thanks in advance (This can also be found at my blog at ) http://olympusmons.blogsome.com/2007/03/08/flops-and-scripts/ -------------------------------------------------------------------------------------- Here are some rules that I think make a good script be it in simple shell or perl or other fancy languages. So here goes.... · Be Verbose Internally Usually being loud mouthed and blowing your trumpet is something that is cherished by most nerds but what to do, unfortunately its not considered very professional, so you either wait for some else to realise how ingeniously you have solved a problem or sad for one day at the fact that that's one more piece of sheer brilliance not recognized anf get on with you life. BUT coding lets you do exactly the opposite....Even though it's the most commonly used "yada...yada...yada" about writing any script or program me thinks it's still not emphasized enough......USE COMMENTS! On the other hand you might be a brilliant coder and don't care what other think, and of course you might not want other to use your code >....but think of this, you might need to use/modify after N days....and trust me its work that extra 30% effort in writing comments will help save a 1000% effort that might be needed to understand the script again · ...Externally... Lets face it, command line scripting is not exactly a eye candy for the user but still it is used since it serves purpose but say the script starts executing. It has to execute 10 steps(think as separate tool invocation) each of varying time. Once invoked the script and the shell go into a world their own with out printing out anything while the invoker is biting his nails trying to figure out what the hell is heppening? Did it crash? Has it gone to an infinite loop? ...once done the script may cleanly exit but by that time the invoker could have had a heart attract, that is if he is able to resist the temptation of CTRL-C that is... But if the script would report or just sprout out "Level n complete...." with the odd echo command after each step, with maybe a small statistics/summary of the last step run, we can save some time from the reruns or maybe even some money for the medial insurance company · /dev/null redirection Just like too much of a good dish is poison; similarly it's a good practice to use the /dev/null redirection wisely. There is no use sprouting out 100 lines per second to the screen if the user is not going to be able to read even one line is it? Say the script invokes multiple tools in its flow and you know that the tool anyway saves what ever it prints to a log file which the user can access once the run is finishes then we can safely redirect the tool output to /dev/ null to avoid the user a headache. if the log file is not automatically created, it would be useful r to redirect it to a log file (and not the screen) unless you have specific reasons to keep the log file from being read And if you are one of the perfectionist coders then you can go ahead and grep some of the final results of the log file to the screen while the next process is being done. · Usage Check /function Generally scripts are written to automate tasks, and most scripts do take some arguments to provide some flexibility or extendibility to their usage. 9 times out of 10 the script will be reused by someone else. So if you were to leave the usage information (invocation format ) hidden deep inside the code, the scripts usability is greatly reduced (unless of course you do 24 hour customer service for it) so its advisable to always do some usage checks like for the correct number of arguments, proper switches etc and also a sample usage example to dump out when the usage is wrong. This can be a separate function to not interfere with you "actual code" · Error Warning Of course while running the scripts some errors are bound to happen or you might want to give some info to the user that must be easily filtered out from the rest of the output. Its always better to use a separate function to print the errors and warnings with a Error: Error details Or Info: Info details so that it can easily be searched for in the log file or grep`ed to a separate file. Also using a common function to report errors can help keep a count of the errors and related fail safe mechanisms · Exit function If the script is long and good you might be exiting from different locations under different conditions, so it would be good to have a single exit function which is "aware" of global variable like error count etc and exits using a standard mechanism, generating a small concise report regarding the run · Log file You might for a highly verbose script but it will be useless if the run is too fast or the user is distracted during the run. There needs to be a mechanism to be able to generate a log file of the output during the run. The user can always "tee" the output to a log file but if you can generate a default log file that would be good { #code here } | tee script.log · Modularize If you write a lot of scripts or even not, its always to modularize the code so that it can be 1) Easy to maintain 2) Easy to reuse That's about what I can think of right now... Statutory warning I have written them with a electronic engineer's....hmm no....a EDA tool engineer's perspective. I think that this would be mostly translate to same in other uses of script.These are not exactly hard and fast rules and the relevant would depend on various parameters like functionality, length etc of the script being written. I am greatly indebted by the information that was passed to be by other experienced engineers in my team and hope that this is a good read for any novice writing scripts for the EDA industry. If I have missed out anything please do not hesitate to leave a comment
