In last week’s post I wrote about adding a scripting language to our toolset. I focused on the benefits a scripting language like e.g. Python can bring, especially when it is combined with C++ code. There are a few more things that should be kept in mind, especially for those who like me are just starting out. 

Scripting languages are just another tool

I may not have stressed it enough: Scripting languages are by no means a suitable replacement for C++ or any other compiled language of your choice. Like every language, they are far from perfect. As we saw this week, that can be very far, if you consider the ecosystem that has been built around them.

Scripting languages are really just another tool, as is C++. We have to choose the right language for any task at hand, like we have to choose the right platform, architecture and libraries used for our applications. Knowing more languages just means we have more freedom to choose a language better suited to the problem we are trying to solve.

That especially means, that while it’s nice to be fond of a specific language, e.g. C++, we should be careful about getting dogmatic and religious about when to use it. Instead of blindly picking the language we know and like best, we should be sensible and pragmatic and acknowledge its weaknesses as well as the strengths of other languages.

Having said that, it’s equally important  to avoid the other extreme. A new language can feel like a new toy – we’re excited about learning to use it. Once we get the hang of it, suddenly JavaScript looks like the solution to everything.

Scripting languages are code, too

Well, I could hardly state anything more obvious. However, there are things that apply to any code which might not be associated with scripting languages in our minds.

When everything I knew was C++ and a bit of Pascal, the concept of scripting was something quick and short for me. Write a few lines of shell code for one time use, fire and forget. I projected that feeling on scripting languages, too, and I have seen the same attitude among other developers.

However, like build scripts, any code written in a scripting language deserves the same attention as our beloved C++ code. That means automated testing, version control, clean code principles and refactoring should be applied to scripts of any flavor.

Version control usually is a no-brainer. Never the less I have seen people, including myself, not using it for programs they wrote in a new language for the first days or weeks. I don’t say you should publish your first steps with Ruby on GitHub for everyone to see (though you could gather of helping comments that way). But in the first days with a new language we play around a lot an make errors, so having the possibility to roll back our changes is priceless.

What is and what is not clean code in a scripting language may differ from what we know from other languages. For example, there are functions in JavaScript that span hundreds of lines, because they contain object definitions which in turn contain lots of smaller functions – everything defined inline.

Nevertheless there is always something like clean and readable code in any language (okay, almost any language). The saying that code lives longer than initially intended is as true for scripts as it is for compiled code. Therefore the same need for maintainability arises.

Given the lack of static checking by the compiler, we should even more strive for readability and simplicity in our scripts, so that errors become more obvious. Naming conventions can also go a long way there, since without static typing there is no way to know if a variable named `foo` contains a number, a string, or an array of complex objects.

Also, if we want to improve our code as we are learning new language constructs, we will want to refactor our existing code. The first Python script I have written started out as a bunch of functions. When I learned how to use classes and other more features of the language, I refactored the whole thing over and over – it has a rather long history of commits for a few hundred lines of code.

Extensive refactoring of course needs thorough testing. Unit test frameworks may not be the first you read about in the book or tutorial of your new favorite language, so it seems usual to go with manual tests for the first few lines of code in a scripting language. Never the less, the unit testing frameworks usually are out there, and we should use them. (Note to self: bring that Python module under automated tests already!)

Conclusion

Don’t treat scripting languages different than any other language – they are all just tools to get the job done, and the code deserves the same care as any code.