You can merge this Pull Request by running:
git pull https://github.com/mehlis/RIOT master
Or you can view, comment on it, or merge it online at:
https://github.com/RIOT-OS/RIOT/pull/67
-- Commit Summary --
* removed redefined ENABLE_DEBUG
* fixed printf patterns
* remove static flag, it's not static
-- File Changes --
M core/kernel_init.c (1)
M core/msg.c (3)
M core/mutex.c (2)
M core/oneway_malloc.c (1)
M cpu/native/hwtimer_cpu.c (2)
M sys/auto_init/auto_init.c (1)
M sys/vtimer/vtimer.c (22)
-- Patch Links --
https://github.com/RIOT-OS/RIOT/pull/67.patch
https://github.com/RIOT-OS/RIOT/pull/67.diff
Well, of course it saves a few keystrokes, but // hurts the coding conventions - enabling /* #define ENABLE_DEBUG */ saves even less keystrokes 
Either way - in cleaned up code vs. ease of typing I tend to prefer tidier code. To me this case appears to be a matter of personal preference and I don’t feel strongly about it.
Since the request has already been merged … do you want the commits to be reverted?
Or, should we add something like commented out debugging code and/or ENABLE_DEBUG does not count as clutter to our guidelines and just leave the defines/comments the next time they are reintroduced?
+1 for tidier code, no need to revert. Could we globally define DEBUG(…) as empty and so get rid of the debug.h include as well?
or better, globally define DEBUG as something like do { if (ENABLE_DEBUG) printf(fmt, __VA_ARGS__); } while (0) and have ENABLE_DEBUG default to 0.
That way the compiler always checks the validity of the debug code.
Hmm, basically a good idea, but that means that we rely on every compiler for every obscure MCU to be smart enough to remove the if-condition. I guess that’s ok?
It would also compile in the check when using -O0, which might be a problem even on the newest compilers.
But who would compile the code with -O0 and care about performance?
But what about this solution: ca75d3c