CODEWITHSUNDEEP
ccoding-stylewhitespace
fenceop
fenceop

Reputation: 1497

When is using whitespace for readability NOT allowed?

C seems to be pretty permissive when it comes to whitespace.

We can use or omit whitespace around an operator, between a function name and its parenthesized list of arguments, between an array name and its index, etc. in order to make code more readable. I understand this is a matter of preference.

The only place I can think of where whitespace is NOT allowed is this:

#include < stdio.h > // fatal error:  stdio.h : No such file or directory

What are the other contexts in C where whitespace cannot be used for readability?

Upvotes: 2

Views: 221

Answers (3)

Keith Thompson
Keith Thompson

Reputation: 263337

In most cases, adding whitespace within a single token either makes the program invalid or changes the meaning of the token. An obvious example: "foo" and " foo " are both valid string literals with different values, because a string literal is a single token. Changing 123456 to 123 456 changes it from a single integer constant to two integer constants, resulting in a syntax error.

The exceptions to this involve the preprocessor.

You've already mentioned the #include directive. Note that given:

#include "header.h"

the "header.h" is not syntactically a string literal; it's processed before string literals are meaningful. The syntax is similar, but for example a \t sequence in a header name isn't necessarily replaced by a tab character.

Newlines (which are a form of whitespace) are significant in preprocessor directives; you can't legally write:

#ifdef
    FOO
/* ... */
#endif

But whitespace other than newlines is permitted:

   # if SPACES_ARE_ALLOWED_HERE
#endif

And there's one case I can think of where whitespace is permitted between preprocessor tokens but it changes the meaning. In the definition of a function-like macro, the ( that introduces the parameter list must immediately follow the macro name. This:

#define TWICE(x) ((x) + (x))

defines TWICE as a function-like macro that takes one argument. But this:

#define NOT_TWICE (x) ((x) + (x))

defines NOT_TWICE as an ordinary macro with no arguments that expands to (x) ((x) + (x)).

This rule applies only to macro definitions; a macro invocation follows the normal rules, so you can write either TWICE(42) or TWICE ( 42 ).

Upvotes: 5

Grzegorz Szpetkowski
Grzegorz Szpetkowski

Reputation: 37934

As I recall you need to be very careful with function-like macros, as in such dummy example:

#include <stdio.h>

#define sum(x, y) ((x)+(y))

int main(void)
{
    printf("%d\n", sum(2, 2));

    return 0;
}

the:

#define sum(x, y) ((x)+(y))

is different thing than say:

#define sum (x, y) ((x)+(y))

The latter one is object-like macro, that replaces exactly with (x, y) ((x)+(y)), that is parameters are not being subsituted (as it happens in function-like macro).

Upvotes: 0

CliffordVienna
CliffordVienna

Reputation: 8245

White spaces are not allowed for readability (are significant) within a lexical token. I.e. within an identifier (foo bar is different from foobar), within a number (123 456 is different from 123456), within a string (that's your example basically) or within an operator (+ + is different from ++ and + = is different from +=). Between those you can add as much white space as you want, but when you add white space inside such a token you will break the lexical token into two separate tokens (or change the value in case of string constants), thus changing the meaning of your code .

In most cases the code with the added white space is either equivalent to the original code or results in a syntax error. But there are exceptions. For example:

return a +++ b;

is the same as

return a ++ + b;

but is different from:

return a + ++ b;

Upvotes: 2

Related Questions