Syntax Tricks: TODO Statement

I’ve always been fascinated by the brilliant simplicity of the Perl ellipsis statement (colloquially known as the “yada-yada” statement). Python has a similar construct in the pass statement. These statements provide a means to mark unimplemented functionality in their respective languages.

For C-based languages, we can achieve a similar effect using clever syntax. In C, C++, and JavaScript, we can mark a function or area of code as being “to do” for later by using semicolons like so:


This is syntactically valid; they are just three empty statements.

Here’s an illustration of how this can be used in C:

[c]void doStuff() {

Likewise, in JavaScript:

[js]function doStuff() {

This is very useful for defining functions/methods you want to write later. However, it can be used beyond functions, and you can use it anywhere a statement would be valid. For example, in a video game, you might want to use a makeshift loading screen and develop a more detailed loading screen when more important functionality has been finished (or when the artwork for the loading screen finally becomes available). Most commonly, I use TODO statements to mark unimplemented functionality.

I also like to combine the TODO statement with comments for additional clarity:

[c]void renderLoadingScreen() {

// TODO: Add progress bar to loading screen

If you are in a *nix environment, you can grep through your code to find all matches for TODO statements using this command:

$ grep -slR “;;;” *

Semantic Inference for Succinctness

While working on JavaScript++, it occurred to me the programs were becoming verbose a la Java. For example, to define a pure function, we might write:

pure function foo(int bar, int baz) {
    // ...

While JavaScript++ will infer whether or not a function is pure, I could not find it in my heart to do away with the “pure” keyword. Why? Because, in large-scale applications, it is important to be able to apply explicit restrictions. If it is desired for a function to be pure, we do not want a team member accidentally introducing side effects later on.

Continue reading Semantic Inference for Succinctness