#warning notes

Guides | Tutorial By 4 years ago

When coding, personal notes are a good way to make sure you don’t forget anything, and keep track of certain things. I often see people making notes either physically or in a document, however there is a better solution…

Physical notes

Physical notes aren’t very good. For one they are personal, so anybody else on the project will never see your notes unless you tell them about them. Also they may get lost on your desk, or one night when the cleaner comes in they may vanish!

Notes document

Unless you’re committing these to your git, any other developers wont see these either. Even if you do put them on your repo, they can be easily missed and forgotten about.

Comments in code

These have the advantage of being inside your code so hopefully the other devs and even yourself will remember to go back and look over them. Often they begin with something like // TODO:, so they can be searched for easily. As with the alternatives above though, they can be easily overlooked and forgotten.

A better solution

My favourite alternative is using the #warning preprocessor directive. This will create a warning just the same as any other compilation warning, so it’s in your face, and anybody else that opens the project for that matter.

I personally use Xcode, but any C based language in an IDE should show the warnings visually. Even when compiling through the command line, the warnings will show up in the terminal.

This can be done easily by simply typing #warning and then some text.

#warning Clean up this code after testing

These can also be useful when dynamically choosing urls, to ensure you don’t upload to the AppStore (or wherever else) connected to the development server.

#warning Using development server
#define SERVER_URL @"http://dev.b2cloud.com.au/service/v1"
#define SERVER_URL @"http://api.b2cloud.com.au/service/v1"