Once we have created code, we can evaluate how it was done. We can use various tools to check our creation among other activities. To do standard checks, we can use style checkers, static checkers, unit testing suites and the most important one, the human code review.
We can use Python as example language, or even Java. To check the Python style, we can use the pep8 style checker, which is based on the PEP8 Python Style Guide. To make lightweight Python correctness checks, we can use PyLint and PyFlakes, which are static checkers. To build unit test suites, we can use PyUnit. All those tools will help us in our coding tasks, so we can create a better and clean code. Very close to the required standards cited by the PEP8 and The Zen of Python. I have modified a script that runs all those checkers in one command to be integrated under Emacs, and you can download it here. To integrate that script on your Emacs editor, you can use the following settings:
(defun my-python-mode-hook ()
(setq py-indent-offset 4
py-smart-indentation nil
py-continuation-offset 4
indent-tabs-mode nil
py-pychecker-command "pycheckers.py"
py-pychecker-command-args (quote ("")))
(setq interpreter-mode-alist(cons '("python" . python-mode)
interpreter-mode-alist))
(eldoc-mode 1)
(define-key py-mode-map "C-cC-w" (lambda ()
(interactive)
(command-execute 'py-pychecker-run)))
(message ">>> done my-python-mode-hook..."))
(add-hook 'python-mode-hook 'my-python-mode-hook)
On the Java side, we have CheckStyle as style checker. As static checker, we have PMD and FindBugs. To build unit testing suites, we can use the well known JUnit. All of those tools can be integrated in your favourite Java IDE, like Eclipse or NetBeans, since you can integrate them on those IDEs using plug-ins. Java is quite different from Python, because it has several coding styles, among a wide variety of FOSS projects and company standards, so you need to choose between those styles.
Among other tasks, the code review matters. Static analysis tools and style checkers are not enough to ensure that your code is clean. You can use code hardening techniques to make safer code. But that requires that you must stay a little bit paranoid with your code, checking every execution path on it. There are some good books on code hardening techniques like “GNU/Linux Application Programming”, which explains some techniques and “Secure Coding Principles & Practice”.
You can integrate those techniques in your evolutionary testing process. Debugging tests is not a ridiculous task, I think that it is a good approach to make better code, assuming that you will modify the program variables enough to make your unit tests fail, and then refactor the code, repair possible failure and fix a harder execution path. But those activities requires the proper time assignment, so your project manager must include enough time to test and prove that your code will work well, even if the environment fails.
I hope that you will enjoy changing your mind about thinking that the code that just works is fine, switching a little and make sure that your code will work always.
Entries 