Sure, since Dijkstra’s letter outlining the harmful aspects of the goto statement, few have voiced even modest amounts of tolerance for the statement, let alone condoned it’s use. Even those who’ve described practical uses of the goto statement have questioned its existence in higher level languages (e.g., although Donald Knuth noted some utility for goto, he also suggested that he would likely never use it in a language that had sufficiently capable iteration and event constructs.)

Today you can find a myriad of online resources that set the goto statement ablaze. The 5.3 release of PHP provided a unique look at the perception of the goto statement, as prior to that release, PHP lacked the statement. It’s one thing to work with languages that have grandfathered in the statement but deprecated its use, but adding goto to a language that lacked the construct fueled the flames of a thousand suns.

However, even Dijkstra was careful to limit his critique to the basic form of the goto statement prevalent during that era of programming:

The go to statement as it stands is just too primitive, it is too much an invitation to make a mess of one’s program.

So, what could the goto statement possibly do to benefit today’s programmers? Even though we don’t need the goto statement to implement our programs, does that mean we can’t benefit from its thoughtful use?

Hypothesis: GOTO Can Be the Right Tool

Let me state a bold, audacious hypothesis: The goto statement can significantly facilitate the creation of new code and the readability/editability of existing code whilst maintaining a high level of performance.

Problem: Deeply Nested Logic

When writing new code, a programmer works from a mental model of a problem, and the mental model drives the code generation. In contrast, when reading or editing existing code, the programmer attempts to synthesize a mental model from existing code, and the code facilitates generation of the mental model. The differences between these two underlying processes are significant, and they can lead to code that was easily written, but proves very difficult to read.

Deeply nested conditionals, a code structure some refer to as arrow code (see Arrow Anti Pattern, Flattening Arrow Code), provide an example of code that suffers from poor readability. When crafting new code, I’ve whipped out five levels of nested conditionals without breaking a sweat. Such is the power of working from a comprehensive mental model. However, returning to deeply-nested code (even after a short break) has often lead to hours of exasperating re-learning and refactoring.

Fortunately, there are techniques that can be used to limit the depth of the conditionals, including:

• Using guard clauses.
• Grouping conditions and pushing them towards the top level.
• Pulling out code blocks into functions.

These techniques can be very effective, as they all help flatten the display of the program flow and limit the levels of nesting. However, these techniques are not without their own potential issues, as they can hurt readability (proximity of relevant factors can be hampered, the flow of operations might not match the natural mental schema), complicate maintainability, and degrade performance (e.g., adding function calls to the stack.)

Example: Deeply Nested Value Store Function

Let’s look at an example of some code that’s deeply nested. We’re going to use PHP to craft our example because PHP offers a form of the goto statement that significantly restricts its use:

• Goto targets must point somewhere within the same file and context, so goto cannot jump out of the current function/method.
• Goto targets cannot be used to jump into a control structure, so goto cannot jump into a loop or switch statement.

function val_nested($name = null, $value = null, $is_mutable = false)
{
	static $values = array();
	static $mutables = array();

	if ($name === null) {
		return $values;
	} else {
		if ($value === null) {
			if (isset($values[$name])) {
				return $values[$name];
			} else {
				return null;
			}
		} else {
			if (isset($values[$name])) {
				if (!$val_is_mutable = in_array($name, $mutables)) {
					throw new Exception('The value "' . $name . '" is immutable and has already been set to '.$values[$name].'.');
				} else {
					return $values[$name] = $value;
				}
			} else {
				if ($is_mutable) {
					$mutables[] = $name;
				} 

				$values[$name] = $value;
				return $value;
			}
		}
	}
}

Refactored Example: Nesting Reduced Using Standard Practices

Below, I’ve provided a refactored version of the value store function that utilizes a combination of the refactoring approaches outlined earlier. Guard clauses have been utilized to bail out as early as possible in the function. The get and set operations have been pulled out into separate functions. And, conditions have been grouped to avoid nesting conditionals. The result is code that requires no more than one level of if-blocks.

My concerns with the refactored version include:

• The flow of the code neither matches the mental model I have when writing new code nor promotes the acquisition of a mental model when I’m reading existing code.
• The proximity of relevant information seems to suffer.
• Adding functions merely for organization (i.e., the functions are unlikely to be reused) degrades performance solely for the sake of organization. Some may say that this concern is tantamount to premature optimization. I disagree, as we’re talking about the techniques that will be used to organize every single function/method block in the code base, and doubling the function calls used in any code base (which in this example roughly doubles the execution time of the refactored function) is a meaningful performance concern.

function val_refactor_get($name, $values)
{
	if (isset($values[$name])) {
		return $values[$name];
	} else {
		return null;
	}
}

function val_refactor_set($name, $value, $is_mutable, &$values, &$mutables)
{
	$val_already_set = isset($values[$name]);

	if (!$val_already_set && $is_mutable) {
		$mutables[] = $name;
		return $values[$name] = $value;
	}

	if (!$val_already_set && !$is_mutable) {
		return $values[$name] = $value;
	}

	$stored_val_is_mutable = in_array($name, $mutables);

	if (!$stored_val_is_mutable) {
		throw new Exception('The value "' . $name . '" is immutable and has already been set to '.$values[$name].'.');
	}

	return $values[$name] = $value;
}

function val_refactor($name = null, $value = null, $is_mutable = false)
{
	static $values = array();
	static $mutables = array();

	if ($name === null) {
		return $values;
	}

	if ($value === null) {
		return val_refactor_get($name, $values);
	}

	return val_refactor_set($name, $value, $is_mutable, $values, $mutables);
}

GOTO Example: A New (Old) Hope

The last code example utilizes PHP’s goto construct to eliminate the deep nesting. As earlier noted, PHP provides some restrictions on its version of the goto construct, and we’ll add one more for the sake of our usage: All goto branches must return a value. This self-imposed restriction ensures that no flow of execution will fall unintentionally into any other labeled block.

I see a few primary concerns with this version. First, this example is the longest of the three. Second, IDE/debugger support for this approach likely ranges from poor to non-existant. Third, and this is a biggie: THIS EXAMPLE USES GOTO AND SOME OF YOU WOULD NEVER, EVER LET THAT HAPPEN!!!

That said, I sincerely believe this version holds significant advantages over the previous versions thanks to the goto construct. While writing new code, I can follow the natural flow of the mental model I’ve developed without worrying about controlling the nesting of the logic through the other techniques. And, while reading and applying edits to existing code, the goto labels provide valuable meta information about the sections of code. If the need arises to add an additional check in the logic, the goto version facilitates finding the location to add the appropriate code, and the structure accommodates the changes with relative ease. Finally, because the goto version doesn’t require more function calls, its performance is on par with the version utilizing deeply-nested if-blocks.

function val_goto($name = null, $value = null, $is_mutable = false)
{
	static $values = array();
	static $mutables = array();

	if ($name === null) {
		goto get_all_values;
	} else {
		goto access_value;
	}

	get_all_values:
		return $values;

	access_value:
		if ($value === null) {
			goto get_value;
		} else {
			goto set_value;
		}

	get_value:
		if (isset($values[$name])) {
			return $values[$name];
		} else {
			return null;
		}

	set_value:
		if (isset($values[$name])) {
			goto set_existing_value;
		} else {
			goto set_new_value;
		}	

	set_existing_value:
		if (!$val_is_mutable = in_array($name, $mutables)) {
			throw new Exception('The value "' . $name . '" is immutable and has already been set to '.$values[$name].'.');
		} else {
			return $values[$name] = $value;
		}

	set_new_value:
		if ($is_mutable) {
			$mutables[] = $name;
		}

		return $values[$name] = $value;
}

Conclusion: Goto Can Be Your Friend

OK, you’ve heard my case for goto, at least the restricted version of goto found in PHP (augmented with our one additional restriction) when used to combat deeply nested logic. In fact, I believe the use of the goto construct in the final example does in fact facilitate the creation of new code and the readability/editability of existing code whilst maintaining a high level of performance.

What do you think?

Update Feb. 17, 2012:
Here’s a great read from the Linux kernel mailing list that discusses why the goto statement is used in the code base: http://kerneltrap.org/node/553

Below, I’ve outlined four simple steps that significantly lower the risk of XSS attacks against your website. By being a bit more restrictive, we can simplify our approach to preventing XSS in the most common use cases. These steps must all be implemented together, but there’s only four of them, so c’mon, you can do it

Step 1: Escape Output Provided by Users

If you want to include data within a page that’s been provided by users, escape the output. And, in this simplified list, we’re going to stick with one simple escape operation: HTML encode any <, >, &, ‘, “. For example, PHP provides the htmlspecialchars() function to accomplish this common task.

Step 2: Always Use XHTML

Read through OWASP’s XSS prevention strategies, and it becomes apparent that protecting against injection requires much more effort if you use unquoted attributes in your HTML. In contrast, in quoted attributes, escaping data becomes the same process needed to escape data for content within tags, the escape operation we already outlined above. That’s because the only troublemaker in terms of sneaking in structurally significant content within the context of a quoted attribute is the closing quote.

Obviously, your markup doesn’t have to be XHTML in order to contain quoted attributes. However, shooting for and validating against XHTML makes it easy to test if all of the attributes are quoted.

Step 3: Only Allow Alphanumeric Data Values in CSS and JavaScript

We need to limit the data you allow from users that will be output within CSS and Javascript sections of the page to alphanumeric (e.g., a regex like [a-zA-Z0-9]+) types, and make sure they are used in a context in which they truly represent values. In Javascript this means user data should only be output within quoted strings assigned to variables (e.g., var userId = “ALPHANUMERIC_USER_ID_HERE”;.) In CSS this means that user data should only be output within the context for a property value (e.g., p { color: #ALPHANUMERIC_USER_COLOR_HERE;}.) This might seem Draconian, but, hey, this is supposed to be a simple XSS tutorial

Now, to be clear, you should always validate user data to make sure it meets your expectations, even for data that’s output within tags or attributes, as in the earlier examples. However, it’s especially important for CSS and JavaScript regions, as the complexity of the possible data structures makes it exceedingly difficult to prevent XSS attacks.

Common data you might want users to be able supply to your JavaScript such as Facebook, Youtube, and Twitter ID’s can all be used whilst accommodating this restriction.   And, CSS color attributes and other styles can be integrated, too.

Step 4: URL-Encode URL Query String Parameters

If user data is output within a URL parameter of a link query string, make sure to URL-encode the data.  Again, using PHP as example, you can simply use the urlencode() function. Now, let’s be clear on this and work through a couple examples, as I’ve seen much confusion concerning this particular point.

Must URL-encode

The following example outputs user data that must be URL-encoded because it is used as a value in the query string.

<a href=”http://site.com?id=USER_DATA_HERE_MUST_BE_URL_ENCODED”>

Must Not URL-Encode

The following example outputs the user-supplied data for the entire URL. In this case, the user data should be escaped with the standard escape function (HTML encode any <, >, &, ‘, “), not URL-encoded. URL-encoding this example would lead to malformed links.

<a href=”USER_DATA_HERE_MUST_USE_STANDARD_HTML_ESCAPING”>

Summary

Let me be clear: These four steps don’t instantly secure a website against all XSS attacks, and I purposely skipped over some very important, related topics (cookie settings, DOM Injection, the risk of including user-provided data in data-schemed URI’s, other contexts such as SVG, etc) that the OWASP website covers very well. Additionally, the limitations outlined above may be too restrictive for some websites, although the number of websites that truly has to offer more flexibility in terms of CSS and Javascript output is likely very small.

That said, these four steps provide a an approach to defending against XSS that is easily remembered and implemented, covers a broad range of typical website scenarios, and serves as a solid start for developers who are learning how to address basic security concerns.

Many online tutorials demonstrate how to implement Object Oriented Programming (OOP) patterns in JavaScript, and, I must confess, the language proves very capable in this respect. However, it’s JavaScript’s ability to implement Functional Programming (FP) patterns that has benefited my work the most.

Sharing logic

There are many qualities that serve to contrast traditional OOP with FP (e.g, first-class functions, (im)mutability, side effects vs. purity, declarative vs. imperative style, etc.), but I’d like to focus on how logic is shared/reused within applications. OOP paradigms tend to share logic by explicitly pushing it out to objects through inheritance, composition, and/or mixins. In contrast, FP tends to push the data to the logic. FP makes this possible because functions typically act on data values rather than from within them.

For a trivial example of how I typically share logic when programming in JavaScript , let’s consider a function called createFormalGreeting(person) that expects a value (object) that contains a lastName field (string) and an isMale field (boolean). As long as the value contains these fields, it will be able to successfully return a string representation of a formal greeting. An employee value, a student value, or even an alien value (the truth is out there) could all be successfully passed to the function as an argument as long as they possess the required structural compatibility.

haven.js

While JavaScript facilitates many aspects of FP, I’ve missed the ability to declare the structural expectations of function parameters and return types (or, the ability to infer type as Haskell does.) I frequently find myself checking for the existence of fields in functions and doing quick tests of a value’s type to avoid coercion gotchas. In light of these issues, I’ve developed haven.js, a simple type checking framework for Javascript that tests for structural compatibility.

The general idea behind haven.js is to ensure that all of the values passed into and out of functions are structurally compatible with the function’s expectations. It works by replacing function calls with wrapper functions that test the parameter and return types explicitly declared as object fields on the functions themselves. If type compatibilities are identified, the details are logged to the console (although the console is used by default, you can tell haven to throw exceptions instead, as you may wish to do when integrating results into unit tests.) I tend to turn off the type checking (i.e., simple don’t call the function haven.typeCheck) in code that’s released in production to avoid the performance hit.

So far, haven.js has greatly facilitated my work, and I hope you’ll get some benefit, too.

Now, if the Richardsons can just learn from his example instead of just watching and enjoying his progress, we’d really be on to something

http://www.infoq.com/presentations/Simple-Made-Easy

Rich always provides great talks, but this one is one of the best, most entertaining I’ve seen. And, my word of the week is now “complect.”

No, it’s not because of his answer to the question “What’s the state of Object Oriented Programming today in your mind?”, to which he responded that:

I think the state is that it’s commercially immensely successful, but practically, I think it’s a disaster.

Although I did agree with much of his analysis on that particular question, I sincerely believe that the whole video has wise words for anyone working as a developer now and in the near future.

And, of interest to me was the fact that he really appreciated the “good engineering decisions” represented in the design of Google’s Dart langauge.

Watch it!

When a team cranks out a new iteration of the product with significant UX enhancements, noticeable performance increases, or demonstrated results in analytics, techies and non-techies alike can realize the enhancements and verbalize praise for the effort. After trying out the new sign-up form, a CEO may exclaim in the weekly executive meeting, “Great job! The new sign-up really flies, and my wife loves the look.” An office assistant may point out over lunch that the new website looks great on their brand new smart phone. And, customers will sometimes go out of their way to contact the company to let someone know that “Cheryl Smith provided fantastic customer support by quickly helping me recover all of the images I’d thought I’d lost.”

Sure, the feedback isn’t always positive (sometimes the CEO hates the new sign-up form, etc.), but the potential for fellow employees, industry peers, and/or general customers to notice and compliment nice work is there.

When do those in charge of security get noticed? When the bored script kiddie gets through the hole in the legacy system that was supposed to be patched last week. When the new programmer’s little omission of an input check leads to a big buffer overflow, allowing the mob compromise the companies digital assets. When the company blogger opened an email that “seemed legit,” only to realize days later that someone has logged into their website and posted porn throughout.

In contrast to their coworkers, security professionals good days are when their work is barely a footnote in the executive meeting. Good days are when they’re contributions are tolerated by team leaders. Good days are when customers say absolutely nothing about security in their survey responses. When working on security, obscurity is the highest compliment.

I used to, in my naive youth, pine for the security associated with your presence from afar, as I contrived my code to the whims of my clients’ environments. Now, I fear you’ll rise from the deep and snatch away the pleasure of my current fancy (Clojure) through yet another exploitation of your capricious complexity.