Tag Archive for 'coding'

SCons, SWIG & Python

Published on August 27, 2010 in C++ and Software Development. 0 Comments Tags: , , .

There are some problems that you can only really solve, let alone understand, by diving into code. Lucky enough the Open Source movement has spread like wildfire these days, also for developer tools. So besides that it’s fun and very educating to read someone else’s source code, in come cases it’s also really, really helpful to find out how a program is doing its tricks internally to really understand how to best use it. In particular this problem case that I’ve been investigating including a combination of SCons, SWIG and Python.

It’s a pretty straightforward setup. You’ve got this C++ library which you want to export to Python. You’ve already setup an interface to Lua, using SWIG. Now the cool thing about SWIG1 is, that it’s really easy to export the same interface to different scripting languages, so you want to use SWIG’s power to use your existing setup and extend that from Lua to Python as well. You take your existing .i file, divide it up into two separate files, a general one and a Lua specific one. Say common.i and lua.i where you include common.i in lua.i. Then you can create your new python.i with the Python specific instructions for SWIG, again including common.i. Problem solved.

Well, not if you’re using SCons as your build tool and you put the %module statement in common.i. That does work for Lua, but for Python strange things will happen with SCons’ build dependencies on the .py wrapper file generated by SWIG. I had to go all the way into SCons’ Tool/swig.py to find out what the problem was. While SCons scans for %module statements, which, if found SCons uses to define the .py file build dependencies for Python extensions, %include statements aren’t honored as such. That’s when I undestood that the problem was my Python specific python.i which didn’t have a %module statement! I put that into common.i, reusing it for Lua and Python, thinking that would be ok. However, that setup will mislead SCons to thinking that there are no %module statements at all. So build dependencies will be incorrect, leading to build errors.

Lesson learned: when using SCons, always put the %module statements for SWIG in the .i file that is used to directly generate the scripting language extension from.

  1. Yes I am a fan. [↩]

Some Random Quotes

Published on June 13, 2010 in Software Development. 0 Comments Tags: , , .

Last month I visited silicon valley again. Always nice to be there. Not only for the weather and the surroundings, but also always really good to catch up and work together with my overseas colleagues face to face again. Only the flight from Amsterdam to San Francisco is not a short one, though that leaves you a lot of time for reading. So I took my chance and took with me some various writings, most notably Coders at Work, which I can definitely recommend.

Anyways, all that reading got me to pen down some random but interesting quotes I encountered:

There are two ways to design a system: “One way is to make it so simple that there are obviously no deficiencies and the other ways is to make it so complicated that there are no obvious deficiencies” — C.A.R. Hoare.

“When documents are mostly to enable handoffs, they are evil. When they capture a record that is best not forgotten, they are valuable” —  Tom Poppendieck.

“Its easier to optimize correct code than to correct optimized code” — Joshua Bloch.

“There’s a grand myth about requirements: If you write them down, users will get exactly what they want. That’s not true. At best, users will get exactly what was written down, which may or may not be anything like what they really want.” — Mike Cohn

It’s interesting that only such a small number of words can express such a great deal of experience.

Coding Standards, But Why?

Published on December 21, 2009 in Software Development. 1 Comment Tags: , .

I already had a long standing draft to write something up about coding standards. To be more specific, coding standards about coding style. I’ve had many, no, too many (heated) discussions about coding standards and coding style, so I was — and am — reluctant to say something publicly about the topic. However, sometimes the momentum is just right, and you can’t resist.

As a developer, source code is your deliverable, it is the thing you produce, and you should try to make it look good. But what is good? How should it look? To debate this and find a compromise, you could as well host your own COP15. The results will be as disappointing. There is no such thing as the Best Looking Coding Style.

However, I do firmly believe in uniform coding style. In an independent team, all produced code style should be consistent. At all times. No exceptions. And I mean it: No Exceptions! Use iron fist if needed.

Well that’s what I believe. Do I need arguments? I think not; consistent coding style is intuitively a Good Thing. Unfortunately when talking to other developers, they want arguments. Of course — who doesn’t want arguments when somebody asks you to change habits?

So, to get back to the momentum I started with, while me and a colleague were in an email discussion with a certain module’s author about adapting his code into our team’s code base, the perfect opportunity revealed itself for me to get back to the dust-collecting coding standards post again.

My colleague wrote:

Just let me emphasize that we think style and code readability and consistency really is important, which is different from what a lot of people who write code think: if it works and the design is good, the code is good. This only holds when you’re the only one working on it, as soon as multiple people get involved it’s a very good thing to make all the code look uniformly, and keep the code readable and properly commented.

The main argument is that it helps shared ownership of the code (i.e. other people don’t feel reluctant editing your code to fix bugs, and won’t assume it is crap because it looks messy, to play the broken-window theory: it’s already crap so why should I care fixing it). Having all the code look the same also helps spotting inconsistencies, like parameters or functions that should be private but are public, debug code that is actually not debug code, comments that are misplaced and confusing etc.

It’s all a combination of minor nitpicking, but taking all of it together it definitely adds substantial value to a shared codebase.

Need I say more?