Tag Archive: Programming


To do lists are wonderful things. When you have a lot of things to do they help you to organise and prioritise all those things, they give you satisfaction when you cross something off your list, and they give you feedback on how you’re doing and whether you need to put some things on the back burner for a while.

Visual studio offers a built in task list to which you can add user tasks, assign priorities and tick off completed tasks.

User Task List – I wish my real to do list was this empty ๐Ÿ˜ฆ

There’s more though, the Task List will also scan your code for token comments – which are special comments containing specific strings.


// TODO: Refactor constructors to use constructor chaining

#region Constructors

#endregion

// HACK this works but it is bad practice to make this method public
 public int GetNextAccountNumber()
 {
return m_NextAccountNumber;
 }

By looking at the comments section you can see a TODO comment and a HACK comment that have been picked up automatically by the task list which read the comments in the code. Once the task is done the comment is deleted.

These tasks have been generated by reading comments in the code

You can even specify your own tokens. They say that you shouldn’t worry about making code more efficient until efficiency actually becomes a problem.

Adding a new INEFFICIENT token – it’s low priority though because efficiency isn’t an issue yet

You can add your own tokens by selecting Tools ->Options -> Environment -> Task List. Here I’ve created an INEFFICIENT token, so that if I write code that I know could be more efficient I can give it the INEFFICIENT token, and if I have to look for ways to speed up code later I can look for all the pieces of code that have been given this token.

Now if I ever want to speed up my code I’ll know just where to look!

Advertisements

Good students will often seek feedback – or validation that what they are doing is right. This is especially true when they are just starting to learn programming (in fact, it’s probably true of everybody on some level, but that is a whole different post).

As a result, often students will ask whether they are doing something the right way, or the best way, and in programming that’s a very difficult question to answer and depends on the problem that you are trying to solve.

The answer is usually "it depends"

as the problems that we give students are usually, to some extent, artificial and contrived in some cases the answer could be “it doesn’t matter”, or the same as that answer to the question “does it work?”, but that doesn’t really help the student, especially given that the question raises an interesting point. In my opinion a far better answer is “it depends – specifically on what the meaning of ‘best’ is”.

Often programming comes down to compromises. There are a number of qualities that we would like to be associated with our code, fast, efficient, reliable, readable, maintainable, finished on time and so on. Quite often though these concepts are in conflict. One example is that you could cache some results, which might make your program faster, but would use more memory. Making code faster often goes hand in hand with making it more readable.

To combat this whenever I start a significant project I always try to define what the meaning of best is. I pick some aspects that I care about, and discard things I don’t care about. This keeps the concept of what I’m trying to achieve in focus and should stop me getting distracted.

Another thing that I think is worth noting is that in my list of qualities, although I’m really interested in clever ways to make code fast the size and scope of the projects I’m usually involved in means that speed is never an issue. Usually the issues are reliable, readable and maintainable, which begs the question what have I still not learnt to comment my own code?

Recently whilst helping students in the labs I found one student who was compiling directly onto a memory stick.

This is bad for a three reasons.

One is that memory sticks have a “life” in terms of the number of times you can write to them, and compiling a project in visual studio does a lot of writing, so the student was shortening the life of his memory stick. Additionally, the memory stick will likely not be backed up in the same way that a students networked storage.

Reason number two is that there is no real reason for a student to be using a memory stick to move code around. All our students have a source code repository which will look after versioning for them as well as providing access to their code anywhere that there is a network connection.

The third reason is writing to a memory stick takes significantly longer that writing to the local hard disk, which meant that he was wasting time waiting for his code to compile.

Compiling: time waiting is time wasted

Waiting for code to compile is waste of time. You should do anything that you can to minimize it, because the more iterations you can get into any allocated amount of time the better the result will be. This is true in industry, where they try to make their tool chain as efficient and intuitive as possible to get more iterations out of their workers. Some game engines use scripting languages like Lua to control game objects. That’s because even though it looks like code, scripts are data. A change in a script doesn’t require any code to be compiled. That means that you can make and test more changes to scripts in a day than you can changes to code.

I used to have this T-shirt, but then my ego outgrew it ๐Ÿ˜‰

Learning is no different. There are lots of competing models of learning, but probably the most prevalent is Kolb’s learning cycle, which involves some thinking, some experimentation, some observation and some reflection. In the context of programming every hit of the compile button begins a trip round Kolb’s learning cycle. Each time you make a change, observe the results and modify or verify your mental model of the problem you’ve done some learning. The faster you can iterate the faster you can learn.

Be yourself – iterate until awesome.