Scripting for the corporate environment.
At work, scripting takes a big part of my time and when you script for a mixed Unix and Linux environment there are a couple of tricks here and there to help you in deploying, debugging ad expanding scripts with the least pain possible.
– Keep a good documentation
This is simply common sense. The great difference between scripting and programming is that you spend less time with the first option. For this reason is easier to forget what you have done.
A good documentation has easy to read comments with general instructions of which module does what and where to customize option.
Not less important is to include a comment header with information like: version, usage, options, author, company and license, known issues, etc.
Good documentation will really help you when troubleshooting or when upgrading the script. Never underestimate this power.
– Make it look good
There is an important reason behind making a script look good: it is easier to read when you go back and review it.
- Keep a proper indentation (camel indentation is good to read loops)
- Use variable names that make sense.
- Limit your abstraction! There is many people who script with the maximum abstraction possible and later they find their scripts difficult to read. Abstract your script to the point is still legible at least by you.
– Variables are everything
Make everything a variable. Nowadays memory is not as scarce and making everything a variable will facilitate customization and legibility.
– Segment into modules.
Dividing your script into modules will turn debugging into a much easier task and over the time you will discover gold nuggets in functions you have developed before, therefore the only thing you will have to do is to go back to your script and simply extract and customize that specific piece of code.
– Standardize your input and output
This one is really a life saver. Create a single format for all the input and output files whenever is possible.
In my case I use space separated document for configuration files; for output files I always have XML documents. This makes it much easier to interact with other scripts an applications
– Define a standard for filenames
This is probably the most common problem in my working place. There is no convention for filenames an everyone end of using a very generic filenames such as [server-name].[date]
Whatever your convention is, make sure it implies the contents of the
file, the format, if it is required also the date or range.
– Script for everyone and for everything
Always remember that when you develop a script, in most cases you will be responsible and the main point of contact in case it fails. I strongly recommend you spend time in evaluation.
Evaluation is very important to prevent human errors during user input and it also plays a very important roll when the script will be ported to a distributed environment.
In my company I am responsible for more than a hundred servers including Linux, Solaris, AIX and HP-UX. I develop dozens of scripts to perform administration and data mining tasks and I learned from the first implementations that the file locations are not standard in all these servers.
Evaluating for the existence and versions of the file I use increasingly reduces the chance of bugs and the requirement to re-implement a new script version or a hotfix.
- Evaluate every file you will use: ensure it exists and that it has the right permissions to interact with your script.
- Evaluate EVERY user input.
- Evaluate your running processes. Estimate their maximum execution time and kill the process if they take longer. This will prevent infinite loops to fill the memory.
- Evaluate script requirements.
- Evaluate communication channels if you script connects to a network.
– Throw exceptions
The last recommendation for today is to throw exceptions. Include a verbose mode of your script which provide useful information for troubleshooting.
If this is a scheduled script (e.g. running from Cron), make sure to save a log with the exceptions thrown and a timestamp. This will prove incredible useful when you want to identify problems in scripts that have to execute only on certain timings.
– Conclusion
These recommendation are just some best practices and common sense.
I would like to add that if you have other colleagues developing scripts in the same environment as you do, organize yourselves. Create a convention for variable names, modules usability, file input and output and documentation. If it’s possible, create a development API (like I do) to perform common scripting tasks like specific database queries, file transfers, user input validation and whatever else you require. If you really think about it, this is a life saver.
Let’s say that you find a vulnerability in a module or the database port changes, in these cases you will only need to update that specific module rather than identifying all the dependent scripts.
Best wishes and happy coding.
Victor.
