Coding convention in [removed] use of spaces between parentheses

Question

According to JSHint, a Javascript programmer should not add a space after the first parenthesis and before the last one.

I have seen a lot of good Javascript libraries t

Answer 1

I used JSHint to lint this code snippet and it didn't give such an advice:

if( window )
{
   var me = 'me';
}

Answer 2

Standards are important and we should follow them, but not blindly. To me, this question is about that syntax styling should be all about readability.

this.someMethod(toString(value),max(value1,value2),myStream(fileName));

this.someMethod( toString( value ), max( value1, value2 ), myStream( fileName ) );

The second line is clearly more readable to me.

In the end, it may come down to personal preference, but I would ask those who prefer the 1st line if they really make their choice because "they are used it" or because they truly believe it's more readable.

If it's something you are used to, then a short time investment into a minor discomfort for a long term benefit might be worth the switch.

Answer 3

Quoting Code Conventions for the JavaScript Programming Language:

All binary operators except . (period) and ( (left parenthesis) and [ (left bracket) should be separated from their operands by a space.

and:

There should be no space between the name of a function and the ( (left parenthesis) of its parameter list.

Answer 4

I use the second (no space) style most of the time, but sometimes I put spaces if there are nested brackets - especially nested square brackets which for some reason I find harder to read than nested curved brackets (parentheses). Or to put that another way, I'll start any given expression without spaces, but if I find it hard to read I insert a few spaces to compare, and leave 'em in if they helped.

Regarding JS Hint, I wouldn't worry- this particular recommendation is more a matter of opinion. You're not likely to introduce bugs because of this one.

Answer 5

This is my personal preference with reasons as to why.

I will discuss the following items in the accepted answer but in reverse order.

note-one not picking on Alnitak, these comments are common to us all...

note-two Code examples are not written as code blocks, because syntax highlighting deters from the actual question of whitespace only.

I've always done it that way.

Not only is this never a good reason to defend a practice in programming, but it also is never a good reason to defend ANY idea opposing change.

JS file download size matters [although minification does of course fix that]

Size will always matter for Any file(s) that are to be sent over-the-wire, which is why we have minification to remove unnecessary whitespace. Since JS files can now be reduced, the debate over whitespace in production code is moot.

moot: of little or no practical value or meaning; purely academic. moot definition

Now we move on to the core issue of this question. The following ideas are mine only, and I understand that debate may ensue. I do not profess that this practice is correct, merely that it is currently correct for me. I am willing to discuss alternatives to this idea if it is sufficiently shown to be a poor choice.

It's perfectly readable and follows the vast majority of formatting conventions in Javascript's ancestor languages

There are two parts to this statement: "It's perfectly readable,"; "and follows the vast majority of formatting conventions in Javascript's ancestor languages"

The second item can be dismissed as to the same idea of I've always done it that way.

So let's just focus on the first part of the statement It's perfectly readable,"

First, let's make a few statements regarding code.

1. Programming languages are not for computers to read, but for humans to read.
2. In the English language, we read left to right, top to bottom.
3. Following established practices in English grammar will result in more easily read code by a larger percentage of programmers that code in English.

NOTE: I am establishing my case for the English language only, but may apply generally to many Latin-based languages.

Let's reduce the first statement by removing the adverb perfectly as it assumes that there can be no improvement. Let's instead work on what's left: "It's readable". In fact, we could go all JS on it and create a variable: "isReadable" as a boolean.

THE QUESTION

The question provides two alternatives:

( foo === bar )

(foo === bar)

Lacking any context, we could fault on the side of English grammar and go with the second option, which removes the whitespace. However, in both cases "isReadable" would easily be true.

So let's take this a step further and remove all whitespace...

(foo===bar)

Could we still claim isReadable to be true? This is where a boolean value might not apply so generally. Let's move isReadable to an Float where 0 is unreadable and 1 is perfectly readable.

In the previous three examples, we could assume that we would get a collection of values ranging from 0 - 1 for each of the individual examples, from each person we asked: "On a scale of 0 - 1, how would you rate the readability of this text?"

Now let's add some JS context to the examples...

1. if ( foo === bar ) { } ;
2. if(foo === bar){};
3. if(foo===bar){};

Again, here is our question: "On a scale of 0 - 1, how would you rate the readability of this text?"

I will make the assumption here that there is a balance to whitespace: too little whitespace and isReadable approaches 0; too much whitespace and isReadable approaches 0.

example: "Howareyou?" and "How are you ?"

If we continued to ask this question after many JS examples, we may discover an average limit to acceptable whitespace, which may be close to the grammar rules in the English language.

But first, let's move on to another example of parentheses in JS: the function!

function isReadable(one, two, three){};

function examineString(string){};

The two function examples follow the current standard of no whitespace between () except after commas. The next argument below is not concerned with how whitespace is used when declaring a function like the examples above, but instead the most important part of the readability of code: where the code is invoked!

Ask this question regarding each of the examples below...

"On a scale of 0 - 1, how would you rate the readability of this text?"

1. examineString(isReadable(string));

2. examineString( isReadable( string ));

The second example makes use of my own rule

1. whitespace in-between parentheses between words, but not between opening or closing punctuation. i.e. not like this examineString( isReadable( string ) ) ; but like this examineString( isReadable( string )); or this examineString( isReadable({ string: string, thing: thing });

If we were to use English grammar rules, then we would space before the "(" and our code would be...

examineString (isReadable (string));

I am not in favor of this practice as it breaks apart the function invocation away from the function, which it should be part of.

examineString(); // yes; examineString (): // no;

Since we are not exactly mirroring proper English grammar, but English grammar does say that a break is needed, then perhaps adding whitespace in-between parentheses might get us closer to 1 with isReadable?

I'll leave it up to you all, but remember the basic question:

"Does this change make it more readable, or less?"

Here are some more examples in support of my case.

Assume functions and variables have already been declared...

input.$setViewValue(setToUpperLimit(inputValue));

Is this how we write a proper English sentence?

input.$setViewValue( setToUpperLimit( inputValue ));

closer to 1?

config.urls['pay-me-now'].initialize(filterSomeValues).then(magic);

or

config.urls[ 'pay-me-now' ].initialize( fitlerSomeValues ).then( magic );

(spaces just like we do with operators)

Could you imagine no whitespace around operators?

var hello='someting';

if(type===undefined){};

var string="I"+"can\'t"+"read"+"this";

What I do...

I space between (), {}, and []; as in the following examples

function hello( one, two, three ){

return one;

}

hello( one );

hello({ key: value, thing1: thing2 });

var array = [ 1, 2, 3, 4 ];

array.slice( 0, 1 );

chain[ 'things' ].together( andKeepThemReadable, withPunctuation, andWhitespace ).but( notTooMuch );

Answer 6

I prefer the second format. However there are also coding style standards out there that insist on the first. Given the fact that javascript is often transmitted as source (e.g. any client-side code), one could see a slightly stronger case with it than with other languages, but only marginally so.

I find the second more readable, you find the first more readable, and since we aren't working on the same code we should each stick as we like. Were you and I to collaborate then it would probably be better that we picked one rather than mixed them (less readable than either), but while there have been holy wars on such matters since long before javascript was around (in other languages with similar syntax such as C), both have their merits.