Spatiophobia?

[andywestken]

Before I go on, this is not meant as a critism. Esp. not to eidge, whose code I randomly chose from amongst the "spatiophobes". I am genuinely intrigued!

From a post by eidge to the thread "How to code using for or while?"
http://www.cplusplus.com/forum/beginner/48633/

for(x;x<3;x=x+1){
. for(y;y<3;y=y+1){

. }
}

I find this kind of code harder to read than

for(x; x < 3; x = x + 1){
. for(y; y < 3; y = y + 1){

. }
}

Now it might be the case that this is what I have become aclimatised to. That is, nurture. Or could it be due to a natural inclination? (introverted code vc extroverted code??)

I have also wondered, when I have seen the minimal spaces style of code, if this is the equivalent of a compact writing style. Which in turn made me wonder if anyone had ever carried out a study of source code "graphology": the correlation between preference for coding style and personality type?

Andy

P.S. I thing normal graphology is -- aside from the obvious -- a load of hokum. But that doesn't mean that no one had carried out such a study!

[ultifinitus]

Y U NO Initialize?

[andywestken]

It's just a code fragment; the initialization is further up the page!

[DSLq5Di1]

Honestly.. I think some people are allergic to whitespace and believe the more compact it looks, the smaller and faster it will run!

Also, seen a few code fragments that go overboard with whitespace,

if ( sky . isBlue ( ) )
    {
        // ...
    }

[ultifinitus]

Haha, I'm giving you crap =]

As far as whitespace goes, I quite dislike too much, some whitespace is necessary for clarity. I like this format:

int function(parametertype parameter){
    int myint = (int)noticeTheWhitespace();

    for (int a = 0; a < 99; a++){
        myint += (int)heyLookYouCanReadMyForLoop(myint);
    }

    return ++myint;
}

[Duthomhas]

I tend to like some space.

int function( int arg )
  {
  int result = (int)lots_and_lots_of_readable_whitespace();

  for (int n = 0; n < arg; n++)
    {
    result += (int)MineToo( n );
    }

  return ++result;
  }

[DSLq5Di1]

  for (int n = 0; n < arg; n++)
    {
    result += (int)MineToo( n );
    }

What is the appeal of this indentation style? I find it more readable when braces line up with the statement,

for (int n = 0; n < arg; n++)
{
    result += (int)MineToo( n );
}

I'm not too fond of space between the arguments of a function call either, though if there is a nested function or complex expression introducing additional parentheses, I might be inclined to do so. ^^

[tition]

I am being torn internally about which is the righteous way:

if (x>0)

or

if(x>0)

as well as

for(int i=0; i<5; i++)

or

for (int i=0; i<5; i++)

.

[Catfish]

Since if and for are keywords and not functions, I personally prefer leaving a space between them and their parameters.

[andywestken]

Since if and for are keywords and not functions, I personally prefer leaving a space between them and their parameters.

I prefer the opposite.

When a ( must follow a token, I like it next to the keyword or function. When it's optional, I leave a space.

if(0 < x)

for(int i = 0; 5 > i; ++i)

return (flags & 0x01);

rather than

if (x > 0)

for (int i = 0; i < 5; i++)

return(flags & 0x01);

P.S. In compound conditions, I use more space. And I generally use plenty of braces

if( (flags & 0x01) && verbose && (CommitRequired() || ShuttingDown() ) )

But I am a bit erratic about the ) ) versus )) an th end of e.g. ShuttingDown

[jsmith]

Well, what I can say is that studies have been done that show that humans at least in part recognize words from their "shape" (stems sticking up, roots down, where, how many, etc).

That being the case, I would think ramming everything together makes that harder.

But largely, readability is personal preference and not science, unless you do something egregious like no indentation, wrong indentation, one letter variable names, etc.

[andywestken]

I think the shape argument works for my preference to group associated tokens (those which represent a single concept) together, with spaces between the groups. Of course, different people will focus on different aspects and therefore come up with other ways of laying out their code.

I use

x + y

rather the the space-less version, as I am adding an x to a y, which I see as distinct entities, with an operator that belongs to neither of them mediating the operation.

But I prefer

x++;

as the increment operator belongs to x

It is also why I use const char* name and not const char *name. The star is part of the type not the identifier, and hence goes nearer the type than the space.

(Note that I strictly follow the one variable definition per line rule; and I always initialize them)

To me the form

char const * const name;

is an aberation I have to suffer.

[Duthomhas]

sloppy9 wrote:

  for (int n = 0; n < arg; n++)
    {
    result += (int)MineToo( n );
    }

What is the appeal of this indentation style? I find it more readable when braces line up with the statement,

for (int n = 0; n < arg; n++)
{
    result += (int)MineToo( n );
}

I'm not too fond of space between the arguments of a function call either, though if there is a nested function or complex expression introducing additional parentheses, I might be inclined to do so. ^^

So what's your excuse? Why is your indentation style superior to mine? I view the "normal" code where braces line up with their statements to be spatially disjointed.

I also like to separate distinct things. An argument is not part of the function name.

My preferences are not invalidated by yours.

jsmith wrote:

But largely, readability is personal preference and not science, unless you do something egregious like no indentation, wrong indentation, one letter variable names, etc.

Exactly. The important point is clarity and readability, not "style", per se.

When you are required to use a particular style, use it. Otherwise, just make your code clean and readable.

andywestken wrote:

To me the form

char const * const name;

is an aberation I have to suffer.

And yet it is clear and concise. Alas, we all have to suffer with everyone else's shortcomings.

I know that many C and C++ programmers prefer a code style different than mine. Yet if you look at the code I've posted here, you would be hard-pressed to argue that it is difficult to follow.


I thought that the point of this thread was to see why people prefer their coding conventions.

Maybe I'm just grouchy.

[helios]

I thought that the point of this thread was to see why people prefer their coding conventions.

Aw, come on. It's got "flamebait" written all over it.

In any case, we all know there is only One True Brace Style.

[andywestken]

I've used the form char const * const name; long enough to be used to it. But for me it is too evenly spaced out.

And when I first enountered this form, it did throw me a bit as I had gotten used to more common, basic form const char*. The rule that the const actually binds to the left, except when it's the left-most token in the declaration, does throw a lot of beginners.

It was even worse in the olden days when some compilers silently accepted const char const * name; (nowadays you should see a warning.)

I thought that the point of this thread was to see why people prefer their coding conventions.

Yes, it was. And I am slowly learning a bit more about the subject!

Discussions about coding conventions invariably end up getting bogged down in detail (I plead guilty to this tendency!) And I have found that there is a surprisingly high emotional component to peoples preferences (I am thinking in particular about some "negotitions" we had about the matter at one place I worked...)

I have mentioned that I like to arrange tokens into conceptual groups, as have others. But we disagree about what these groups are. But we do hold the common view that there should be structure. Out different preferences must have something to do with the features that we use to identify the groups.

If everything is crammed together, or things are absolutely uniformly spaced, then there is no structure. In between are different variations on the theme of grouping. (though randomly scattered code is far worse!)

The simplest example that I (still) don't get -- from a type-ist point of view -- is the char *name form of a C string variable or parameter definition. To me, char* name reads as "name is a variable/parameter of type char*". When the tokens are laid out the other ways, it looks - to me - like it should be read as "name is a variable that when deferenced is of type char." Is that what K & R were thinking about when they came up with their pointer syntax?

I am happy enough reading other styles/layouts, and if editing someone else's code would always (try to) conform to their style. But some styles are harder for me to read. Esp. if I am trying to read them at speed, in the midst of firefighting a problem. (this is generally code with little spacing)

I studied physics at university, and had therefore done a lot of (applied) maths before I ended up becoming a programmer. I think that this just might have some bearing on my preference of int function() over int function (). When I hand write mathematical functions, in basic notation, the bracket pretty much follows the function name f(c) = 2x + 1. Now I have seen pure maths which uses other sort of notation, but that kind of thing's beyond me!

[helios]

To me, char* name reads as "name is a variable/parameter of type char*".

Your logic is valid; however, the most common argument against this style is
char* a, b;
What's the type of b?

[andywestken]

@helios - I am aware of thet argument, which is why I stated that I strictly follow the one variable definition per line rule; and I always initialize them.

So I could write that as

char* a = NULL;
char  b = '\0';

Always!

Andy

P.S. By always, I mean every time I declare a variable in advance. I actually almost always use declaration at first point of use; something a lot of the newbies on this site seem to be unaware of? Is this due to the style they're taught??

[Alrededor]

andywestern : wrote

The simplest example that I (still) don't get -- from a type-ist point of view -- is the char *name form of a C string variable or parameter definition. To me, char* name reads as "name is a variable/parameter of type char*". When the tokens are laid out the other ways, it looks - to me - like it should be read as "name is a variable that when deferenced is of type char." Is that what K & R were thinking about when they came up with their pointer syntax?

Yes. I have read somewhere, though I don't remember where, that one of them (K or R) said that the declaration syntax of the pointer was intended to imitate usage.

[DSLq5Di1]

Duoas wrote:

I thought that the point of this thread was to see why people prefer their coding conventions.

I used your snippet to reflect my own preferences while asking why you prefer your style.. there was no "mine is superior, yours is invalid" garbage you seem to have inferred, if it came off that way it was not my intent.


When I was new to C/C++, the difference between a pointer declaration char *a and the dereferencing of a variable *a confused the hell out of me! I prefer char* a, though against better judgement I sometimes group the pointer with its variable name for multiple declarations.

[jsmith]

Not even the compiler can decide if the * sticks to the type or the variable:

int * a, b;  // declares a to be a pointer but b not, so the * sticks to the variable.
void * f(); // but declares f to be a function returning void*, so * sticks to the type. 

blah.

(ok, so one is declaring a variable and the other forward declaring a function, not the same thing. But still, it's inconsistent.)