The 3 spaces/tab versus 4 spaces/tab thread
by Daniel Buckmaster · in Torque 3D Professional · 05/05/2014 (4:43 am) · 17 replies
I have just realised that T2D uses a 4-space/tab convention. I think the community preference seems overwhelmingly in favour of following suit. However, internal committee discussion has resolved that it's such a major change that we'd prefer not to introduce it in any version but a major number (i.e., in T3D 4.0).
My question is, what do we do in the meantime? Do we make good folks like Lukas reformat their code into 3-space? Do we accept some 4-spacing and have the code in an ugly transitional state for a while?
I think the former has to be the solution, until we make a concerted move. But I'm happy to be convinced otherwise. Also, is there anyone who wants us not to move to 4-space?
My question is, what do we do in the meantime? Do we make good folks like Lukas reformat their code into 3-space? Do we accept some 4-spacing and have the code in an ugly transitional state for a while?
I think the former has to be the solution, until we make a concerted move. But I'm happy to be convinced otherwise. Also, is there anyone who wants us not to move to 4-space?
About the author
Studying mechatronic engineering and computer science at the University of Sydney. Game development is probably my most time-consuming hobby!
#2
Here is my not necessarily to be taken seriously opinion.... (see note 1)
3 or 4 space tabs are the least of the annoyances with regards the hideous formatting of the torque sources, however it might be worth considering the defaults of the visual studio versions being used, or alternatively finding some way of forcing the settings into the supplied project files.
I'm just curious, will this be another reason to turn down reasonable pull requests for failing to meet the 'dress code' of the repo?
Like Quinton i tend to use the aStyle formatter with the Kernighan & Ritchie style with some customising to bracket one/two line conditionals (a minor pet hate) and remove the idiotic (imo) spaces ( really, unnecessary, really ) in parenthesis (another pet hate especially when this particular format is seemingly arbitrarily used in the torque sources.
note 1:- I was once tasked to investigate the issue of source code style and implement a strategy at a previous employer, while investigating came across a forum where this debate was being tabled (more than just tab spacing) but thee were some 60+ pages of the only people on the planet who badly need some other form of release in their lives....
05/13/2014 (5:51 pm)
Jumping in late as is my custom particularly since I don't seem to be around too much these days.Here is my not necessarily to be taken seriously opinion.... (see note 1)
3 or 4 space tabs are the least of the annoyances with regards the hideous formatting of the torque sources, however it might be worth considering the defaults of the visual studio versions being used, or alternatively finding some way of forcing the settings into the supplied project files.
I'm just curious, will this be another reason to turn down reasonable pull requests for failing to meet the 'dress code' of the repo?
Like Quinton i tend to use the aStyle formatter with the Kernighan & Ritchie style with some customising to bracket one/two line conditionals (a minor pet hate) and remove the idiotic (imo) spaces ( really, unnecessary, really ) in parenthesis (another pet hate especially when this particular format is seemingly arbitrarily used in the torque sources.
note 1:- I was once tasked to investigate the issue of source code style and implement a strategy at a previous employer, while investigating came across a forum where this debate was being tabled (more than just tab spacing) but thee were some 60+ pages of the only people on the planet who badly need some other form of release in their lives....
#3
However I think rejecting PRs that don't align with the existing code style is important if we want to keep some level of consistency in the source. I mean, we never outright reject - we ask the author to clean them up before we can accept.
Quinton: I think having mixed levels of indentation will be bad news for everyone :P. Personally, I think we will need to 'reboot' the repo at some point anyway. It's very, very large, and unnecessarily so. Maybe if we introduce Jeff's component system, we should start a new repo with the old class hierarchy ripped out, spaces/tabs fixed, and without the script template cruft.
Oh. I asked reddit about this ages ago, but nobody seemed to care :P.
05/13/2014 (6:21 pm)
Bloodknight: what is your number 1 annoyance in the Torque source? It tends to basically follow K&R style with the unfortunate addition of whitespace in parentheses, which I also find inexplicable (and it's very inconsistent).However I think rejecting PRs that don't align with the existing code style is important if we want to keep some level of consistency in the source. I mean, we never outright reject - we ask the author to clean them up before we can accept.
Quinton: I think having mixed levels of indentation will be bad news for everyone :P. Personally, I think we will need to 'reboot' the repo at some point anyway. It's very, very large, and unnecessarily so. Maybe if we introduce Jeff's component system, we should start a new repo with the old class hierarchy ripped out, spaces/tabs fixed, and without the script template cruft.
Oh. I asked reddit about this ages ago, but nobody seemed to care :P.
#4
05/13/2014 (6:49 pm)
... reads Bloodknight's last paragraph ... falls of his chair laughing! XD 
#5
Of course, library code doesn't count in this.
On the subject of whitespace in parenthesis, I've seen both torque use whitespace and not use whitespace. Personally I kind of like it, since its easier to read (at least for me), but in the end its more of a stylistic choice anyway.
As for tab spacing... if you just used tabs people could choose which level of indentation to use ;)
05/14/2014 (2:27 am)
I think its important to be consistent, otherwise the project will end up looking like more of a mismatch of programming ideologies than it already is. It's not at all unusual for open source projects to enforce style guidelines for code.Of course, library code doesn't count in this.
On the subject of whitespace in parenthesis, I've seen both torque use whitespace and not use whitespace. Personally I kind of like it, since its easier to read (at least for me), but in the end its more of a stylistic choice anyway.
As for tab spacing... if you just used tabs people could choose which level of indentation to use ;)
#6
I understand that there are many parts of torque libraries and other components written by different people, this is something most people get use to and i'm assuming i act like most people and try to keep the style of the file i'm working on.
I'm sure i mentioned before when the engine first went MIT that there should be a link to the style formatting guide so that everyone knows whats what, i also think that the default tab spacing and other enforced style components that visual studio uses as default should be considered when looking at and maybe adjusting the style guide.
tdn.garagegames.com/wiki/CodeStyleGuide how many people know this even exists? and doe it even apply anymore?
As James pointed out its relatively common practice for large projects to have and use and enforce this kind of document. if you are to make changes maybe the guide should be renewed, reviewed and reposted with comments upon changes noted for people who are used to working with one particular style.
I'm not intentionally trying to heap more work on the steering committee but if i'm not mistaken this is part of what the committee is about.
A cautionary tale: I have seen projects fall apart after applying astyle rules to entire projects, there are conditions where compile fails can be introduced and worse still, logic bugs that compile can be introduced and not noticed due to original bad practices in the code. I'm not saying torque is like that but i have seen it happen.
05/14/2014 (3:54 am)
My main gripe is the general lack of consistency of style applied (within a single file/section see paragraph below) which is probably more of a personal OCD thing wouldn't be the first time ive lost a function simply because of code styling for example. I know this doesn't happen to the real pro coders but if you are tinkering in the engine and only half understand its workings it does add an extra hair of difficulty in reading/understanding.I understand that there are many parts of torque libraries and other components written by different people, this is something most people get use to and i'm assuming i act like most people and try to keep the style of the file i'm working on.
I'm sure i mentioned before when the engine first went MIT that there should be a link to the style formatting guide so that everyone knows whats what, i also think that the default tab spacing and other enforced style components that visual studio uses as default should be considered when looking at and maybe adjusting the style guide.
tdn.garagegames.com/wiki/CodeStyleGuide how many people know this even exists? and doe it even apply anymore?
As James pointed out its relatively common practice for large projects to have and use and enforce this kind of document. if you are to make changes maybe the guide should be renewed, reviewed and reposted with comments upon changes noted for people who are used to working with one particular style.
I'm not intentionally trying to heap more work on the steering committee but if i'm not mistaken this is part of what the committee is about.
A cautionary tale: I have seen projects fall apart after applying astyle rules to entire projects, there are conditions where compile fails can be introduced and worse still, logic bugs that compile can be introduced and not noticed due to original bad practices in the code. I'm not saying torque is like that but i have seen it happen.
#7
05/15/2014 (7:24 am)
Personally, I do not care. A war over 3 spaces per tab versus 4 spaces per tab seems counter-productive. Generally, when I'm in a section of code that isn't formatted with my tab defaults I "fix" it out of habit - I use 4 spaces per tab. Even Torque isn't formatted "correctly" with older sections using 3 spaces. The current style guide was established only recently and the various engines exhibit wildly varying styles depending on the age of the code section. 
#8
This is how I would want to be treated if I was contributing good work in my spare time, so I treat others the same.
Edit - Also, as it was mentioned, T2D uses 4 spaces. This became a standard for internal GG projects and is being maintained for T2D and new GG internal projects. From a coding and merging perspective, especially for cross-platform work, it's the best option to me. However, I don't speak for anything T3D related. Just providing backstory.
05/15/2014 (7:48 am)
I have a suggestion that should be considered. If someone submits a pull request with a great contribution, especially if it took time to put together, I would not consider rejecting it from T2D at all. I would not force them to go back and fix styling. Rather, I would use my responsibilities as a steering committee member to take the pull request, fix the stylings myself, then push to the repo.This is how I would want to be treated if I was contributing good work in my spare time, so I treat others the same.
Edit - Also, as it was mentioned, T2D uses 4 spaces. This became a standard for internal GG projects and is being maintained for T2D and new GG internal projects. From a coding and merging perspective, especially for cross-platform work, it's the best option to me. However, I don't speak for anything T3D related. Just providing backstory.
#9
I'll take the latter :P
05/15/2014 (7:49 am)
I'm a 4 space tab kind of guy. Don't listen to James and his "tab" blasphemy. I will agree a little whitespace in the parenthesis makes things look nicer:for(SceneObject::ZoneRef* walk=list->nextInBin;walk!=NULL;walk=walk->nextInBin)VS
for( SceneObject::ZoneRef* walk = list->nextInBin; walk != NULL; walk = walk->nextInBin )
I'll take the latter :P
#10
Personally I'm a 4-space kind of guy... and none of that damn extra spacing! ;)
05/15/2014 (9:12 am)
Quote:And there was one... mentioned, blogged, obviously located (to some) on the Github wiki, etc., but most people were unobservant and/or didn't care.
I'm sure i mentioned before when the engine first went MIT that there should be a link to the style formatting guide so that everyone knows whats what,
Personally I'm a 4-space kind of guy... and none of that damn extra spacing! ;)
#11
05/15/2014 (10:06 am)
Also, I fix formatting as I go when it comes to T2D coding. As I'm writing, I will use the standard. If I open up an existing file, I will usually end up formatting the entire thing according to the standards. It's honestly the only approach I can take without having a lot of downtime or not finishing my original task.
#12
This whole discussion is about attention to detail - whether you realize it or not - and that takes commitment and effort. So, thanks to everyone here.
05/15/2014 (1:14 pm)
Have I told you guys lately that you're all awesome? Because you are.This whole discussion is about attention to detail - whether you realize it or not - and that takes commitment and effort. So, thanks to everyone here.
#13
05/15/2014 (1:57 pm)
For myself, it's all about cutting down on the false positives when merging to make it less of a pain in the rear for folks. Pick a method.
#14
James: unfortunately tabs seem to get a lot of hate from programmers, which I've never understood. Probably because editors refuse to support them sensibly :/.
Bloodknight: consistency is definitely important. Probaly the most important bit in the guideline is just to use the style that's used in the code you're working on. Don't worry if it's different elsewhere in the engine - keep consistency locally.
Richard: a war is definitely not productive, but members of the SC have proposed the switch so we need the community to decide on whether we should do it.
Mich: I'd love to agree with you. I need to mull it over some more. Frankly while I'd love to be treated that way, I'd also personally never submit code that didn't match the style guide, and be more than happy to fix it if I did make an unintentional breach. It's a matter of etiquette as much as anything. It's just polite IMO :P.
Andrew: I think the issue is not the spaces after semicolons or between binary operators, but spaces around the parentheses:
05/15/2014 (10:01 pm)
Code style guidelines yo
James: unfortunately tabs seem to get a lot of hate from programmers, which I've never understood. Probably because editors refuse to support them sensibly :/.
Bloodknight: consistency is definitely important. Probaly the most important bit in the guideline is just to use the style that's used in the code you're working on. Don't worry if it's different elsewhere in the engine - keep consistency locally.
Richard: a war is definitely not productive, but members of the SC have proposed the switch so we need the community to decide on whether we should do it.
Mich: I'd love to agree with you. I need to mull it over some more. Frankly while I'd love to be treated that way, I'd also personally never submit code that didn't match the style guide, and be more than happy to fix it if I did make an unintentional breach. It's a matter of etiquette as much as anything. It's just polite IMO :P.
Andrew: I think the issue is not the spaces after semicolons or between binary operators, but spaces around the parentheses:
if ( myFunc ( x ) > 0 )versus
if(myFunc(x) > 0)
#15
A newcomer to Torque MIT will have 3 first experiences, not just one:
1. Getting the engine
2. Using the engine
3. Making contributions (optional)
Improving the first experience is very important and becomes an endless process. Put yourself in this example scenario. Say you are new to the community, but a great engineer. After using it for some time, you develop a port of Torque 3D to iOS. You used tabs, instead 4 spaces. Proud of your work and knowing this is a HUGE feature request, you submit a pull request. It is then rejected solely on the usage of tabs. Going through all the files to switch to 4 spaces is a pain and may not be worth the effort if you have other work to do. So you leave it in your fork and say "get it here if you want it." Not a great first experience.
Now, what if this happened. You write the code, submit the pull request, and wait for a reaction. A steering committee member comments along the lines of "Wow! This is awesome. Thank you for this much needed feature. Just so you know, the style for Torque 3D is to use 4 spaces instead of tabs. For this pull request, we'll fix that for you and merge into the official branch. In the future, it would be appreciated if you use 4 spaces instead. However, this kind of contribution is ultimately appreciated above anything else!"
Food for thought.
05/16/2014 (4:42 am)
I'm the same boat with my code submission Daniel. Because I know the preferred style in T2D is 4 spaces, I use that. If it was tabs, I would use tabs for commits and 4 spaces for my other projects. The reason I made my original statement is that everyone should notice that while both T2D and T3D have been chugging along and making good progress, we need more contributors. T2D 3.0 was a huge upgrade with new platforms, new features, more docs, and lots of bug fixes. That was great. It also took a year. That was partially due to lack of organization, but also because the number of contributors was spread out over that year. A newcomer to Torque MIT will have 3 first experiences, not just one:
1. Getting the engine
2. Using the engine
3. Making contributions (optional)
Improving the first experience is very important and becomes an endless process. Put yourself in this example scenario. Say you are new to the community, but a great engineer. After using it for some time, you develop a port of Torque 3D to iOS. You used tabs, instead 4 spaces. Proud of your work and knowing this is a HUGE feature request, you submit a pull request. It is then rejected solely on the usage of tabs. Going through all the files to switch to 4 spaces is a pain and may not be worth the effort if you have other work to do. So you leave it in your fork and say "get it here if you want it." Not a great first experience.
Now, what if this happened. You write the code, submit the pull request, and wait for a reaction. A steering committee member comments along the lines of "Wow! This is awesome. Thank you for this much needed feature. Just so you know, the style for Torque 3D is to use 4 spaces instead of tabs. For this pull request, we'll fix that for you and merge into the official branch. In the future, it would be appreciated if you use 4 spaces instead. However, this kind of contribution is ultimately appreciated above anything else!"
Food for thought.
#16
05/16/2014 (5:10 am)
/me applauds Michael Perry ... definitely a very valid point and one thing that should be considered.
#17
We've seen this happen already with, for example, signmotion's 64-bit PR which Thomas went through and broke into workable chunks. We'll probably also see something similar with Tim Condon's large GUI pull-request that has been sadly languishing in don't-want-to-touch-this land. Though neither of those PRs had issues with formatting.
05/16/2014 (5:47 am)
Sure Mich, I definitely agree, but I don't think we are seeing that kind of interaction at all. In a scenario like that we'd definitely not just leave the work sitting there. We'd obviously want to engage the committer to see if they'd fix it, with the understanding that if they don't want to go to the trouble, we'd still be interested in their work.We've seen this happen already with, for example, signmotion's 64-bit PR which Thomas went through and broke into workable chunks. We'll probably also see something similar with Tim Condon's large GUI pull-request that has been sadly languishing in don't-want-to-touch-this land. Though neither of those PRs had issues with formatting.
Torque Owner Quinton Delpeche
Gobbo Games
So it is irrelevant to me, but I prefer 4-spaces myself. :)
I would have the code in a transitional state, but start enforcing the 4-space standard from here on in on any new code ... might make the migration a little easier in the the long run. :)