In most programming languages, null is the most common thing in the world, and every programmer knows that an object can be ‘empty’, or in other words have the value null, nil or undefined depending on the language.
I’ve always lived in Microsofts big IDE Visual Studio, for all my programming
purposes, because I developed .NET. Visual Studio is a monster of an
application - it has its own quircks, but is generally regarded as a pretty good
development tool. Of course all .NET developers swear to Visual Studio, because
they really haven’t got anywhere else to go - leaving Visual Studio would sound
like leaving .NET all together.
And actually the experience in Visual Studio isn’t all that bad. Its got good
code suggestions, great debugging facilities - but 90% of its features I either
don’t know about, or selectively dont use.
In my professional (read “closed-source”) life, the versioning history of any project is a byproduct the coding of the project. What I mean is, there’s not much thought about how the history reads or is structured.
This makes it hard to read and understand the versioning history, which is an important log of whats happened to the code. The following example is XKCD’s brilliant rendition of this.
Every code written in a programming language, is executed in a specific way when run. The executions depends on the language and defines how it interacts with the hardware. This is called an execution model.
I’m no compiler expert, but I do think that all programmers should learn multiple programming languages and along with it, know the basics of the execution models, in which they run.
A year ago I did some Test Driven Development training at work, by doing three two-hour mini code-retreats. The idea was that I would lecture as little as possible, focusing on trying it out instead. TDD is a practical technique, so you will learn quicker, if you practice it it in pairs on a given assignment, rather than following the concept only in slides.
Each session started with some short theory on the given TDD subtopic of the day and then introduced an assignment, which was carried out in pairs in the style of Code retreats (inspired by the work on the subject by Corey Haines and Joe Reinsberger). Before each assignment, I would code a smaller example in the same style as the assignment, on the screen in the room.
The thing I discovered in these sessions, was that using code constrains on top of the normal TDD kata’s, is nice learning tool.
I consider myself a decent object-oriented programmer, in which the keyword static has often annoyed me, because of its general misuse.
I still Often see applications, where almost everything done in static and there are almost no objects in use. This obviously makes for a very inflexible and hard to test application.
But the static keyword holds more problems than this excessive coupling, its also problematic when its used to create static data, especially when your running in a multi-threaded context - which everyone is these days.
Code quality is not only a product of the code you write, but also of how the code is written and put into versioning. The way you tailor the process of writing code, by how you organize, name, review and build versions of your code, has much to do with the quality of the software you produce.
