Why Python is like C++

[Roy Smith]

In article <mailman.4462.1387614224.18130.python-list at python.org>,
 Dan Stromberg <drsalists at gmail.com> wrote:

> On Fri, Dec 20, 2013 at 9:34 PM, Mark Lawrence <breamoreboy at yahoo.co.uk> 
> wrote:
> > On 20/12/2013 14:19, Roy Smith wrote:
> >>
> >> http://xkcd.com/1306/
> >>
> >
> > I believe that to be a very superficial like.  They're unlike in that once
> > C++ people have compiled their code they can head down to the pub, but
> > Python people have to stay at work testing because the compiler hasn't
> > caught all potential errors.
> 
> Python should be used with static analysis (EG pylint), IMO, for
> reliability.  Python should also be used, IMO, with a good set of
> automated unit, integration and system tests.
> 
> C++ should use automated tests too, but is often used without because
> the compilers make it almost reasonable to do without.  The compilers
> tend to make it so you don't need static analysis, but it's so cheap
> to use static analysis that it's a good idea to do so.

On the last large C++ project I worked on, we decided (i.e. obeyed a 
corporate mandate) to start using Coverity's static analysis tool on our 
15 year old codebase.  I learned a few things about static analysis then.

1) It finds bugs you would never find yourself.

2) If your code does tricky things, you can fool the static analyzer, 
leading to false positives.  Presumably, it also leads to false 
negatives, but you don't know about those :-(

3) If you're going to use static analysis, probably the best way is to 
start using it from day one.  Trying to duct-tape a static analysis step 
into your development process for a legacy codebase is probably more 
effort than it's worth.

4) I suspect static analysis does a lot better on a language like Java 
(which has introspection) than it does on C++.  One of the biggest 
problems is that the preprocessor means the code that compiles is not 
the code that you look at.