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:

[c];;;[/c]

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() {
;;;
}[/c]

Likewise, in JavaScript:

[js]function doStuff() {
;;;
}[/js]

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() {
doStuff();
doStuff2();

// TODO: Add progress bar to loading screen
;;;
}[/c]

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 “;;;” *

Bitmasks in JavaScript

A lot of JavaScript developers will use objects as hash maps. They might take this further and set/unset flags and options for a function. For example:

[js]
function eat(foods) {
if (foods.chicken) { /* … */ }
if (foods.pork) { /* … */ }
if (foods.beef) { /* … */ }
}
[/js]

Unfortunately, objects in JavaScript are not necessarily “hash maps” (even if they’ve been implemented using hash maps). Objects are subject to the rules of prototypical inheritance. Therefore, in order to make the above code safe, we may need to add extra checks:

[js]
function eat(foods) {
if (Object.prototype.toString.call(food) !== "[object Object]") {
return false;
}

if (Object.prototype.hasOwnProperty.call(foods, chicken)) { /* … */ }
if (Object.prototype.hasOwnProperty.call(foods, pork)) { /* … */ }
if (Object.prototype.hasOwnProperty.call(foods, beef)) { /* … */ }
}
[/js]

Assuming you are writing safe code and not leaving things up to chance, you can see how this can quickly become messy.

In my previous blog post, I detailed the JavaScript Enum Pattern. We can combine enumerations with bitmasks to create flags that are faster, less memory-intensive, and easier to write. Due to the prevalence of objects, bitmasking is a technique more common in languages like C++, but they can actually be used in JavaScript.

Continue reading Bitmasks in JavaScript

Syntax Tricks: Region Blocks

One thing I really miss from Visual Studio is the ability to fold entire regions of code under a meaningful description. This allowed developers to hide code they weren’t particularly concerned with at a given moment. I work on several large projects, and the lack of regions has been driving me nuts, but I think I’ve stumbled on a clever way to organise JavaScript code…

Most IDEs and text editors support code folding. The detection algorithm for code folding usually comes down to “blocks” which are defined with curly braces: { … }. For example, a multi-line if statement requires a block to be defined:

[js]
if (true) {
doStuff();
doMoreStuff();
}
[/js]

Most editors will allow you to “fold” the if statement’s block here. However, it’s perfectly legal to define arbitrary blocks almost anywhere else in your code where a statement is typically valid:

[js]
var foo = 1;
{ // start block
doStuff();
} // end block
doMoreStuff();
[/js]

We can now “fold” the block and hide doStuff();

Finally, we’re now able to hide arbitrary pieces of code in JavaScript! However, we can go even further…

Continue reading Syntax Tricks: Region Blocks

Prototypal Inheritance: One Size Does NOT Fit All

There is the prevailing attitude within the JavaScript community that prototypal inheritance will fit for all use cases where object-oriented design is required. However, in real world application development, this isn’t quite so ideal. First, let’s examine the history.

JavaScript, as a language, was designed by Brendan Eich for Netscape back in 1995. He was tasked to design a language that looked like Java, the popular programming language of that time with its promise of cross-platform compatibility. Thus, JavaScript was born… in just ten days. However, there was one problem with Java: classes. Why buck the trend and omit classes if one was trying to emulate the most popular programming language of the time? Why, when tasked with creating a familiar language, would one opt for a design that was alien to contemporary programmers?

Continue reading Prototypal Inheritance: One Size Does NOT Fit All