4

Due to the inherent risks associated with using dynamic languages (e.g. Python, Ruby) carelessly, what (if any) standards should be imposed on production code written in these languages?

rdasxy
  • 3,323
  • 7
  • 29
  • 41
  • It depends on the language. For example, in JavaScript you have JSLint and JSHint to validate the code and ensure that the language dynamic features don't break the code... –  Mar 19 '12 at 01:15

4 Answers4

9

Your question contains two contradictory elements:

  1. that someone would use the language carelessly, and

  2. that they would follow standards for the production code.

Any programmer that is part of a team that has standards for production code should not use a language, dynamic or not, carelessly. There is a lot of experience with writing code in dynamic language, starting with Lisp many, many years before Java was even thought of.

While non-dynamic languages can catch some errors at compile time, they would not catch mistakes like erroneous conversion from SI to English units, etc. As far as I know (and I would love to be proven wrong...) there does not exist any study that has shown that using dynamic languages to write programs leads to more errors.

Many programmers writing on this, and other forums, express strong opinions one way or another but I suspect (no proof, sorry...) that there is a lot more variation in programmer's skills and proficiency in using good tests than there is coming from the use of language X over language Y. (with the possible exception of Ada...)

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
André
  • 205
  • 1
  • 3
  • It is quite a lot of work to make Ada catch erroneous physical unit conversion at compile time. A type has to be explicitly defined to hold every possible combination of quantities that can arise: meters, kilogram-meters, kilogram-meters/second, etc. It gets quite tedious. – kevin cline Dec 07 '12 at 00:01
  • Well, F# does have units as a first-class feature of the language. – Robert Harvey Dec 12 '12 at 00:14
5

Coding standards should be a simple as possible and hopefully restricted to avoiding language features and idioms which are known to be problematic or broken.

Too many rules in program standards can lead programmers to code sub-optimal and unreadable code because the best solution has been declared "bad" in the standards doc.

What dynamic languages really require are higher testing standards. As there are more run time errors possible, and, the forgiving nature of the languages means simple coding errors can cause weird behavior in seemingly unrelated components. You really need a good set of unit tests for every single component, plus a comprehensive set of integration tests which should be run every-time any piece of code has changed.

James Anderson
  • 18,049
  • 1
  • 42
  • 72
  • Why test when you can make software correct by design? – ThomasX Mar 19 '12 at 11:32
  • 3
    @ThomasX: Because, in strongly-typed languages, the compiler catches many errors at compile time that would otherwise be overlooked at run time, so you need additional testing to catch those cases in dynamic languages. Testing is the way you *verify* that your software is correct. – Robert Harvey Dec 06 '12 at 20:10
2

Not so much a coding standard as a good practice, I would say aggressive testing.

As you said, there are inherent risks with dynamic languages. Issues that would never even exist in a static language can and will crop up in poorly designed or written code in a dynamic language. Applying comprehensive, well-written unit tests as a part of your process will help ensure your code is correct and error free.

1

What "inherent risks" are you thinking of? I can't think of any run-time error that can occur in Python or Ruby that can't occur in C# or Java. Null pointer exceptions, missing method exceptions, and type conversion errors are all possible in C# and Java. In Java, we add back all the missing dynamic behavior through Spring and other packages layered on reflection. This enables all the run-time errors inherent in dynamically typed languages, except that to fix them you have to sift through seventeen layers of XML configuration files.

Connecting strongly typed languages to the untyped HTTP protocol, and the differently-typed SQL database in any reasonable way requires type conversions that cannot be validated at compile time. I don't believe that dynamically typed languages require special care. No matter the language, delivering reliable code will require extensive testing.

kevin cline
  • 33,608
  • 3
  • 71
  • 142