OSDev.org

Posted: **Sun Jul 03, 2011 7:57 am**

gerryg400 wrote:
Chandra wrote:Personally, I'd invest time getting myself a cup of coffee, than having required to type 4 spaces for indentation
Chandra, doesn't your editor have a mode where it will enter 4 (or the appropriate number for alignment) spaces when you press the tab key ?

To the guys who say they prefer tabs, I also press tab to indent my code and to align comment blocks etc. I'm sure I type into my editor in almost the same way as the 'tab' guys. It's just that my editor converts them to spaces

We are not voting here which key on the keyboard should be used for entering the whitespace that formats our code (for that I vote tab), we are voting on which character should be stored in the actual source files on the wiki ?

Well, for me it's not about configuring the editor to create shortcuts. It's simply about convinience. I just prefer 'TAB' for alignment so that a '\t' character is inserted by the editor itself. No tricks, no shortcuts and everyone is happy(at least I am).
Cheers.

Posted: **Sun Jul 03, 2011 10:55 am**

berkus wrote:It breaks in many cases already pointed out in the wiki style guide thread.

I went through the whole thread. The only examples I could find involve alignment (of comments, for example) across different indentation levels (which do not occur in my code) and a remark that one can easily confuse tabs and spaces (which does not happen with my editor settings where I use visible tab markers). Remember, this is just my personal preference, not a general advice - it fits my needs, and it works for me.

But anyway, as I said before, for the Wiki I would prefer to use .

Posted: **Sun Jul 03, 2011 1:18 pm**

Now I finally see where you guys are going wrong...
Functions with arguments on different lines and comments being on the same line as code, is just retarded.
Don't do that.

Posted: **Sun Jul 03, 2011 3:33 pm**

My code:

Code: Select all

    units[unit].zd = (units[unit].xc - cam.x) * (units[unit].xc - cam.x)
                   + (units[unit].yc - cam.y) * (units[unit].yc - cam.y)
                   + (units[unit].zc - cam.z) * (units[unit].zc - cam.z);

Drew's version of it:

Code: Select all

    units[unit].zd = (units[unit].xc - cam.x) * (units[unit].xc - cam.x) + (units[unit].yc - cam.y) * (units[unit].yc - cam.y) + (units[unit].zc - cam.z) * (units[unit].zc - cam.z);

Make your choice.

Posted: **Sun Jul 03, 2011 3:38 pm**

My version, by far...

...Oh but no word wrapping, of course.

Posted: **Sun Jul 03, 2011 11:09 pm**

berkus wrote:Of course,

Code: Select all

units[unit].zd = delta_squared(units[unit].xc, cam.x) + delta_squared(units[unit].yc, cam.y) + delta_squared(units[unit].zc, cam.z);

That's a practical example of why you might use something other than assembly language for your operating systems. I'm not even sure if you get the same result, but the original was just too flawed to begin with... I believe he actually wanted something more like:

Code: Select all

    units[ unit ].zd = ( ( units[ unit ].xc - cam.x ) * ( units[ unit ].xc - cam.x ) )
                     + ( ( units[ unit ].yc - cam.y ) * ( units[ unit ].yc - cam.y ) )
                     + ( ( units[ unit ].zc - cam.z ) * ( units[ unit ].zc - cam.z ) );
SPACESPACESPACESPACESPACESPACESPACESPACESPACESPACESPACESPACESPACESPACESPACESPACESPACESPACESPACE

IMHO, I would call your space-indented comment-inline over-elaborate code way too fancy, and just not technological enough.... In which I personally see no use for a standard in. That kind of coding just gives me a headache no matter how you put it.

Also, I think these kinds of debates are extremely important, and if you're serious about the type of thing you are trying to accomplish, then you should not take the debates lightly. There are some serious points from each side, but I'm telling you the correct way is to never code in such a manner that requires you to ever need the use of elaborate indentations and structures, or else you lose a lot quality in the many languages this applies to. Which renders all previous points from the other side invalid.

I'm not too good at metaphors, but these little things truly are a big deal, and all of you Jedi's know it in some way, or else we wouldn't be here discussing it. The conflict between the light and the dark force is your personal preference and habits. This little thing might not be important to most people, but it's extremely important if you want to be Jedi. Many ideals, techniques, and practices in theory can be formed from this one little thing. The dark force's way of blasting through one of those big heavy metal security doors could be much more bloated and inefficient that the light force's way of do it, all because the dark force didn't want to use tabs. Sorry all of you Star Wars fans, I hope I didn't mess that up...

Honestly though guys... What are we talking about here?? Syntax... We're not even talking about the actual language itself. Just make it neat, very readable, don't go crazy with the spaces, and don't get too fancy so your code doesn't align on other text editors. Now let's get serious and make a standard on a language, or a framework, or a library, or an API. Take your pick. We'll make it simple enough, so that if you ever would need to indent with spaces it would be because of comments at the end of the line... And then we'll all just laugh at those people who do that.

Posted: **Mon Jul 04, 2011 12:21 am**

drew wrote:
berkus wrote:Of course,
Code: Select all
units[unit].zd = delta_squared(units[unit].xc, cam.x) + delta_squared(units[unit].yc, cam.y) + delta_squared(units[unit].zc, cam.z);
That's a practical example of why you might use something other than assembly language for your operating systems. I'm not even sure if you get the same result, but the original was just too flawed to begin with... I believe he actually wanted something more like:
Code: Select all
    units[ unit ].zd = ( ( units[ unit ].xc - cam.x ) * ( units[ unit ].xc - cam.x ) )
                     + ( ( units[ unit ].yc - cam.y ) * ( units[ unit ].yc - cam.y ) )
                     + ( ( units[ unit ].zc - cam.z ) * ( units[ unit ].zc - cam.z ) );
SPACESPACESPACESPACESPACESPACESPACESPACESPACESPACESPACESPACESPACESPACESPACESPACESPACESPACESPACE
IMHO, I would call your space-indented comment-inline over-elaborate code way too fancy, and just not technological enough.... In which I personally see no use for a standard in. That kind of coding just gives me a headache no matter how you put it.

Also, I think these kinds of debates are extremely important, and if you're serious about the type of thing you are trying to accomplish, then you should not take the debates lightly. There are some serious points from each side, but I'm telling you the correct way is to never code in such a manner that requires you to ever need the use of elaborate indentations and structures, or else you lose a lot quality in the many languages this applies to. Which renders all previous points from the other side invalid.

I'm not too good at metaphors, but these little things truly are a big deal, and all of you Jedi's know it in some way, or else we wouldn't be here discussing it. The conflict between the light and the dark force is your personal preference and habits. This little thing might not be important to most people, but it's extremely important if you want to be Jedi. Many ideals, techniques, and practices in theory can be formed from this one little thing. The dark force's way of blasting through one of those big heavy metal security doors could be much more bloated and inefficient that the light force's way of do it, all because the dark force didn't want to use tabs. Sorry all of you Star Wars fans, I hope I didn't mess that up...

Honestly though guys... What are we talking about here?? Syntax... We're not even talking about the actual language itself. Just make it neat, very readable, don't go crazy with the spaces, and don't get too fancy so your code doesn't align on other text editors. Now let's get serious and make a standard on a language, or a framework, or a library, or an API. Take your pick. We'll make it simple enough, so that if you ever would need to indent with spaces it would be because of comments at the end of the line... And then we'll all just laugh at those people who do that.

You've still provided no reason to use tabs instead of spaces on the wiki pages. This is not actually about personal opinion. It's a debate and vote.

Posted: **Mon Jul 04, 2011 1:59 am**

berkus wrote:Of course,

Code: Select all

units[unit].zd = delta_squared(units[unit].xc, cam.x) + delta_squared(units[unit].yc, cam.y) + delta_squared(units[unit].zc, cam.z);

Or:

Code: Select all

units[unit].zd = delta_squared(units[unit].xc, cam.x) 
               + delta_squared(units[unit].yc, cam.y)
               + delta_squared(units[unit].zc, cam.z);

I'm going to bet 20 invisible tokens here that an impartial user test can prove that my multi-line indented version beats the finding of typo-based bugs over drew's and berkus' version. Spot the bug:

Code: Select all

float crosslen = ((a.y * b.x) - (a.x * b.y)) * ((a.y * b.x) - (a.x * b.y))
               + ((a.z * b.y) - (a.y * b.z)) * ((a.z * b.y) - (a.y * b.z))
               + ((a.x * b.z) - (a.z * b.z)) * ((a.x * b.z) - (a.z * b.x))

And here:

Code: Select all

float crosslen = ((a.y * b.x) - (a.x * b.y)) * ((a.y * b.x) - (a.x * b.y)) + ((a.z * b.y) - (a.y * b.z)) * ((a.z * b.y) - (a.y * b.y)) + ((a.x * b.z) - (a.z * b.x)) * ((a.x * b.z) - (a.z * b.x))

Posted: **Mon Jul 04, 2011 4:23 am**

Combuster, if you're talking about that bug I already pointed out... I just automatically knew from experience, as it should be... And I didn't rely on your fancy coding, even though I did include the fix in your version of the code. I already knew it was going to be a problem without having to visually see it. Everyone should automatically know that the expression would be read from left to right...
That's not the point though...
The point is that you should have never reached such a hard to read expression.

Posted: **Mon Jul 04, 2011 4:46 am**

berkus wrote:
drew wrote:Combuster, if you're talking about that bug I already pointed out...
Wtf are you talking about?

His code looks like:
2 * 2 + 5 * 5 + 3 * 3

Your code looks more like:
(2 * 2) + (5 * 5) + (3 * 3)

I THOUGHT I did a good job pointing that out already:

drew wrote:I'm not even sure if you get the same result, but the original was just too flawed to begin with... I believe he actually wanted something more like:
Code: Select all
    units[ unit ].zd = ( ( units[ unit ].xc - cam.x ) * ( units[ unit ].xc - cam.x ) )
                     + ( ( units[ unit ].yc - cam.y ) * ( units[ unit ].yc - cam.y ) )
                     + ( ( units[ unit ].zc - cam.z ) * ( units[ unit ].zc - cam.z ) );

I guess all of those spaces must have made it really hard to notice.

Edit:
However that's not even a practical example. I don't even have a clue of what it's supposed to do, other than the fact that is appears to have something to do with 3D. (XYZ blah blah) For all I know, he meant for it to be like that.

Posted: **Mon Jul 04, 2011 5:46 am**

Gosh, drew... you just "know automatically from experience, as it should be"? Not only claiming some leet Jedi powers, but at the same time proactively blaming everyone not sharing them as being somehow sub-par?

You're really the character I'd like to have on the team...

...of our competition.

Besides, you totally missed the bug.

drew wrote:However that's not even a practical example. I don't even have a clue of what it's supposed to do...

So because you don't understand it, it's not practical?

Hint: Most code you'll encounter during maintenance will be under-documented...

Posted: **Mon Jul 04, 2011 6:56 am**

For those still wondering what bug we're talking about...

Combuster wrote:

Code: Select all

float crosslen = ((a.y * b.x) - (a.x * b.y)) * ((a.y * b.x) - (a.x * b.y))
               + ((a.z * b.y) - (a.y * b.z)) * ((a.z * b.y) - (a.y * b.z))
               + ((a.x * b.z) - (a.z * b.z)) * ((a.x * b.z) - (a.z * b.x))
//                                       ^

I don't know the first thing about 3D calculations. (I previously admitted that maths are my weak point.) I have no idea what Combuster is doing here. But I'd bet money that this third line should read:

Code: Select all

               + ((a.x * b.z) - (a.z * b.x)) * ((a.x * b.z) - (a.z * b.x))
//                                       ^

Simply because there's a pattern to the whole equation, and that 'z' there breaks it. Which you'd totally miss in drew's version.

Admittedly, I only spotted it after Combuster hinted at it (because I didn't "suspect" the code in question I only glanced at it).

Had drew hinted that there's a bug in his equation, the first thing I'd have done would have been to get it properly vert-aligned to look at the pattern.

Posted: **Mon Jul 04, 2011 10:07 am**

berkus wrote:Good catch, Solar. There's a visible pattern if you read this code in columns.

The whole point of formatting code in columns. Our brain is an excellent pattern recognition machine; using that to augment our understanding of things is just logical.

Drew, I have to ask... If you came across code like this out in the wild

Code: Select all

return Mat4(lhs[0] * rhs[0][0] + lhs[1] * rhs[0][1] + lhs[2] * rhs[0][2] + lhs[3] * rhs[0][3], lhs[0] * rhs[1][0] + lhs[1] * rhs[1][1] + lhs[2] * rhs[1][2] + lhs[3] * rhs[1][3], lhs[0] * rhs[2][0] + lhs[1] * rhs[2][1] + lhs[2] * rhs[2][2] + lhs[3] * rhs[2][3], lhs[0] * rhs[3][0] + lhs[1] * rhs[3][1] + lhs[2] * rhs[3][2] + lhs[3] * rhs[3][3]);

would you be able to work out what it does?

(Yes, more 3D. Its a good example of this: systematic calculations over large arrays, rarely rolled up because compilers are bad enough at optimizing vector math as is)

Posted: **Mon Jul 04, 2011 2:43 pm**

I'm not sure why you are all missing my point as if you seemingly didn't read my posts, or surely didn't understand what I'm trying to say, so let me make it as simple as I possibly can for you guys...

I am not trying to advocate tabs over spaces, I am trying to advocate hierarchy over complexity. Though I am saying spaces for indentations is a bad habit, which sets you up for complexity failure. It makes you lazy and you say, "Oh I'll just format it this way, instead of making a macro that I can reuse, or making a function that can be reused, or using a function that already exists." In which case, the bug would have NEVER even had a chance to exist.

Also, stop calling the later MY version. Please. I never claimed that as my own, but I see where you may have misinterpreted me as claiming it. My version would have NEVER reached such complexity. No one has even seen my version, you all just assumed that's what I would do.

drew wrote:That kind of coding just gives me a headache no matter how you put it.

Solar wrote:
drew wrote:However that's not even a practical example. I don't even have a clue of what it's supposed to do...
So because you don't understand it, it's not practical?

Hint: Most code you'll encounter during maintenance will be under-documented...

What's with everyone and their selective reading on this forum?? How can you read that, and then miss the very next sentence?? I know what it does, I don't know what it is supposed to do.

Anyways, no offense guys... Nice community. But I'm done here... I'm just not capable of making any points here, when you guys miss every other sentence I write, and end up talking about something completely different. I feel like I'm trying to teach a homeless man table manners. It's like every question or point someone tries to make towards me, I had already explained in previous posts. But I realize I'm not the best at English or making points, you could all do a much better job of atleast trying to understand. (no wonder there's so many flamewars here, everyone's speaking a different language) Until then... Me trying to explain anything to you guys is fruitless. It's just sad when someone has to quote themselves.

drew wrote:What are we talking about here?? Syntax... We're not even talking about the actual language itself. Just make it neat, very readable, don't go crazy with the spaces, and don't get too fancy so your code doesn't align on other text editors. Now let's get serious and make a standard on a language, or a framework, or a library, or an API. Take your pick.

Good luck with your standard...

Posted: **Mon Jul 04, 2011 2:48 pm**

Too bad. The Enlightened One has left the building...

OSDev.org

Wiki Coding Style: Tabs vs. Spaces

Re: Wiki Coding Style: Tabs vs. Spaces

Re: Wiki Coding Style: Tabs vs. Spaces

Re: Wiki Coding Style: Tabs vs. Spaces

Re: Wiki Coding Style: Tabs vs. Spaces

Re: Wiki Coding Style: Tabs vs. Spaces

Re: Wiki Coding Style: Tabs vs. Spaces

Re: Wiki Coding Style: Tabs vs. Spaces

Re: Wiki Coding Style: Tabs vs. Spaces

Re: Wiki Coding Style: Tabs vs. Spaces

Re: Wiki Coding Style: Tabs vs. Spaces

Re: Wiki Coding Style: Tabs vs. Spaces

Re: Wiki Coding Style: Tabs vs. Spaces

Re: Wiki Coding Style: Tabs vs. Spaces

Re: Wiki Coding Style: Tabs vs. Spaces

Re: Wiki Coding Style: Tabs vs. Spaces