Skip to content

Instantly share code, notes, and snippets.

@lancejpollard lancejpollard/thoughts.md
Last active Jan 29, 2018

Embed
What would you like to do?
code whitespace

function whitespace

The following looks much more like a "package" without the extra space:

app.get('/', function(req, res){
  res.send('Hello World');
});

app.get('/', function(req, res) {
  res.send('Hello World');
});

That extra bit of whitepsace is like, what is the purpose of that? What is your reasoning for that? To me it's just extra stuff that detracts from the flow.

My reasoning for the spacing is probably backward-rationalized, but it feels natural to me for these reasons:

In the case above it's less distracting than that extra space. I'm labeling it as distracting because it doesn't feel balanced. It's like building a landing page, with 10px of padding on the left and 20px on the right, it would just feel off.

For a case like named functions (or constructor functions), it feels like adding the space re-balances the padding:

function Page() {
  
}

Now there is padding on both the left and the right!

As opposed to this, where it's lopsided again (this time with 20px on the left and 10px on the right type thing).

function Page(){
  
}

However, I could go with that flattened version, because you could turn it around and say there is just one space in the middle.

For the last case, of on the prototype, it's the same situation, the padding is symmetric when it's squished:

Page.prototype.load = function(){
  
};

There's the symetric whitespace around the =, and that's it. There isn't extra padding at the end:

Page.prototype.load = function() {
  
};

redundant comments

Redundant/unnecessary comments:

  • eliminate ambiguity
  • focus attention

It's sort of like this. Without a comment, when you look at a chunk of functionality, you have to start analyizing what it is. Even if you are always coding and have been for years, seeing the same require statements at the top of files, you still have to look and your brain (consciously or not) has to analyze what is there.

For things that always occur (like module dependencies), the cost for interpreting what that block of code is is small, but it's still there.

For things that are different often, like a prototype method, if you don't have a comment you have to analyze the function to figure it out, starting with the function name perhaps, and then the arguments and the block of code itself. But even if it's named nicely, like Page.prototype.load, without a comment you still are not certain that the function actually "loads a page". Your brain still has no validation that it's guess about the function is correct.

However, if you have a comment for that function, your guess is immediately validated and your brain doesn't have to continue analysis. It's guess has been confirmed. Look at the difference.

/**
 * Load a page.
 */

Page.prototype.load = function(){
  
};

This is the reason for the super-redundant Module dependencies comment. As your brain scans the code, it's guess is immediately validated with a high degree of certainty. Your brain gets much more feedback that it's knowledge about the world is correct.

With lots of redundancy like this, you more quickly move through code with less analysis.

This is especially valuable for new-comers as well. New coders or new people to the team. By providing this feedback to eliminate ambiguity, it helps them understand the code faster. This is also one of the goals with Tower once we get the parts made, to make it easy for new people to jump into the code. To remove layers of ambiguity and make the experience easier for the brain to digest.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.