I post the origin question in stackoverflow, some people suggest me to post here
I’ve always have trouble with dynamic language like Python.
Several problems:
- Typo error, I can use pylint to reduce some of these errors. But there’s still some errors that pylint can not figure out.
- Object type error, I often forgot what type of the parameter is, int? str? some object? Also, forgot the type of some object in my code.
Unit test might help me sometimes, but I’m not always have enough time to do UT. When I need a script to do a small job, the line of code are 100 – 200 lines, not big, but I don’t have time to do the unit test, because I need to use the script as soon as possible. So, many errors appear.
So, any idea on how to reduce the number of these problems?
4
I’m afraid there’s nothing better than unit tests in this case. Sometimes extensive comments (for every method, and sometimes even for a given line of code) help, but it only postpones the inevitable doom 🙂
Of course good comments are always helpful, no matter the unit tests exist or not.
0
For the object type problem you could use Hungarian Notation. Most programmers I know (including myself) think it’s ugly, but if that’s often recurring problem for you, this would most likely work.
For typo errors a IDE or Texteditor with syntax highlighting, code completion and similar functionality could help if you don’t use this already.
Well, most (but not all) of these problems can and should be managed by the IDE, not by the programmer.
Maybe you are just using an IDE that is not good enough for the task at hand.
Did you try IntelliJ IDEA, for example?
With dynamic languages like Python (or Javascript or Ruby etc.) I have found that the most successful way to work is to write a few lines of code at a time (like five) and test as you go. This works well because the edit test cycle is so short, just a couple of seconds.
Have you ever tried measuring how long it actually takes you to write all the unit tests? My bet is you need less than half the time you’d take to fix all the bugs later.
With practice (and especially with TDD), I’d bet that’s more of a factor of 10.
In other words, skipping unit testing because you have “no time” is actually costing you more time afterwards, when you have to fix the bugs that slipped through and when you don’t remember the code anymore.
So maybe it is better to invest more time in unit testing the code now, before releasing, because even if you let a bug slip, you’ll be sure not to introduce more bugs when trying to fix something, as you’ll have more and more regression safety net.
P.S.: If you feel like you need test this out, try using the Pomodoro Technique to measure how long it takes you to fix bugs when they appear after you’ve released the code without tests, and in the next project, use it to measure how long you take to write the unit tests before releasing.