defun99

// Props to : http://nathanleclaire.com/blog/2013/11/16/the-javascript-question-i-bombed-in-an-interview-with-a-y-combinator-startup/
var processOnTime = function ( next, delay ) {
  var d = delay;
  
  if ( ! next ) {
    throw new ReferenceError();
  }
  
  if ( ! d || isNaN ( d ) ) {
    d = 200;

defun99

// Props to : http://nathanleclaire.com/blog/2013/11/16/the-javascript-question-i-bombed-in-an-interview-with-a-y-combinator-startup/
var processOnTime = function ( next, delay ) {
  var d = delay;
  
  if ( ! next ) {
    throw new ReferenceError();
  }
  
  if ( ! d || isNaN ( d ) ) {
    d = 200;

defun99

// Props to : http://nathanleclaire.com/blog/2013/11/16/the-javascript-question-i-bombed-in-an-interview-with-a-y-combinator-startup/
var processOnTime = function ( next, delay ) {
  var d = delay;
  
  if ( ! next ) {
    throw new ReferenceError();
  }
  
  if ( ! d || isNaN ( d ) ) {
    d = 200;

defun99

Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.

---

General rules

1. Follow standard conventions.
2. Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
3. Boy scout rule. Leave the campground cleaner than you found it.
4. Always find root cause. Always look for the root cause of a problem.

Design rules