Programming as an Artform

This is a response to the excellent post by Jani Gorše, titled Why is Programming an Art?

Ever since I began studying Computer Engineering at university back in 1995 I have struggled to find the “proper” ways to format my code, name functions and variables appropriately, structure functions into files and files into directories with Makefiles and Makefile snippets, using both recursive and non-recursive make. Formatting of code, for instance, was for a while a bit of an obsession of mine, and it sort of is still. But today I am more concerned with the overall structure and how components interact. Even though I can still get very annoyed at people naming their local variables obtrusively.

I still do most of my work, professional and hobby, using plain old C. I’ve read many books and style guides on the subject and the one that really stood out as being extremely helpful, apart from reading a LOT of code, is The Practice of Programming by Kernighan and Pike! The book is crammed full with tons of neat advice and best practises that simly just make sense. Stuff like “name your local variables i, j, k for counters and loop variables”, which is basically what most of us do already. Just read it and you’ll see what I mean – spot on!

Spot on? Why should you read something that seemingly doesn’t tell you anything you already know? Well, even the most evident practises often come under scrutiny when programmers from different schools meet. At my job we have Microsoft, Bombardier, and ABB programmers. All of which have little to no experience with UNIX, Linux or any Free/Open Source software development. They are used to more cumbersome practises, like “Hungarian Style Notation”, usually very inflexible corporate styles which nobody can explain anymore, and so on.

It is difficult to teach the way of Free/Open Source software, but I think the most important message is: keep it simple, maintain the same style as used in the rest of the project, and if you comment then write what you mean with a piece of code, not what it does. And, in the true style of UNIX, write one program that does its job well.

The beuty in software comes from structure, the flow, the similarities and how the modules fit together. The absence of duplication, and the readability.

Visit the homepage for the book and download the source code to have a look for yourself. Enjoy!