Roadmap: Replace tabs with 4 spaces

Everything about development and the OpenMW source code.
Locked
User avatar
lgromanowski
Site Admin
Posts: 1193
Joined: 05 Aug 2011, 22:21
Location: Wroclaw, Poland
Contact:

Roadmap: Replace tabs with 4 spaces

Post by lgromanowski » 13 Aug 2011, 21:01

pvdk wrote: I wanted to replace the tabs in the code with spaces but I couldn't find any, at least sed couldn't. If this is correct then the entry for this can be removed from the roadmap.
Zini wrote: There are plenty. Example: engine.cpp
pvdk wrote: Strange, will look into it.
ap0 wrote: Wich command do you use ?
Something like

Code: Select all

sed --posix s/[\t]/\ \ \ \ /
?
pvdk wrote:

Code: Select all

sed -i 's/\\t/    /g' filehere.cpp
But I found out that the expand commando does exactly what we need. Now I'm figuring out how to execute it on multiple files with xargs.
pvdk wrote: Ok I've replaced all the tabs with 4 spaces in all the .cpp, .c, .hpp and .h files on my local git clone. Even MyGUI got modified which I think is not ok but maybe I can ignore that somehow whilst committing?

What to do next? I never committed something with git so I don't know what to do...
ap0 wrote: pvdk : check if this do not bork the code, then

Code: Select all

man git
:D
There is a link about this on the wiki iirc.
pvdk wrote: Yeah yeah, RTFM :)

I'll check it out.

Done! I sent you a pull request Zini. Hope I did it right...

EDIT: No I didn't do it right! Expand fucked up.
Star-Demon wrote: One tab is four or five spaces...

I don't understand what the problem is.

Is there some sort of IDE or text editor problem? (You linux users and your silly barebones text editors. pico, vim, emacs, et all.)

Is this a compliance issue?

/boggle
Zini wrote: Are you serious? You said is yourself. Tabs can be represented as varying indent widths (4, 8, sometimes 2, never seen 5 though). If you mix that up with spaces, you get a mess. Depending on the editor settings it can break the source formatting. And that is only the tip of the iceberg.

Never mix spaces and tabs. Either use spaces or use tabs. We decided a while ago to use spaces.
ap0 wrote: By the way : vim pwn your "Visual Studio".

</troll>
Star-Demon wrote: Yes, Zini, I'm serious. I didn't know you settled on something like that.

There isn't a need to cut me down while explaining it. I really don't like it when you do this.
ap0 wrote:By the way : vim pwn your "Visual Studio".
There is no substantial real reason that a text editor presents any benefit over any IDE other than not having to spend few seconds loading a single file for editing. I'm not programming from a bunker in Siberia in 1986, I'm on a desktop computer in 2011. What substantial savings are there, really?

The mouse is a wonderful input device. It shouldn't be sitting idle. Debuggers are also nice. There's lots of nice things with IDEs. You know what's also nice? Colors. I like it when it's pretty. HCI and all.

TBH, I feel anything else is just amounts to Hardcore Attitude.
sir_herrbatka wrote: IDE lacks of zen.

Tools < Person that uses them. Besides complicated tools not always works on your advantage. I prefer to write short story with vim than with document procesor like Word.

Stop bashing everything you don't like Star.
gus wrote: This is going off topic :roll:

So we must use space instead of tab when we code, right?
Zini wrote: Yes, please.
Lordrea wrote: Bah, spaces are evil. Tabs give more freedom to the viewer of the code as to how much spacing they want per indention. I wish you could reformat the code GIT-side, allowing developers to write in whatever environment is best for them.

IDEs, by the by, are not evil. A person might be more important than their tools, but that doesn't mean we should provide our carpenters with stone-age hammers, unless that's their tool of choice.

But yeah, no point in arguing about it. Us Windows guys are a minority here both as a forum base and a developer base, despite our post-Gold user base targeted to a majority of Windows users (as gamers tend to be), and it shows in the code and development of the project. That's perfectly fine, so long as 1.0 is platform independent in a real sense, rather than designed for one OS, and patchable together on another.

Aaand, now I'm going back to lurking.
Star-Demon wrote: I'd like to qualify that I'm not being nasty or anything - Maybe I'm just using the right words to express something. I AM a nerd, ya know. I'm trying hard, though.
Peppe wrote: Star-Demon:
With vim you can use the mouse, have colors and debugger integration.
But not in 1986 as vim is not quite that old ;)

Anyway, choice of editor (integrated or not) really is out of topic here and should be left to each and everyone to use whatever they prefer.
Lordrea wrote:Bah, spaces are evil. Tabs give more freedom to the viewer of the code as to how much spacing they want per indention.
Spaces on the other hand does not change size, which gives you consistency.
The result of people trying to align comments, function parameters and such using tabs can be interesting when viewed using a different tab stop.

There are those arguing that a combination of tabs and spaces will solve this, and used correctly I guess it will. But combine tabs and spaces the wrong way (which probably will happen) and you will build a larger mess.

Then again there are also people who don't use fixed width fonts...
In the end it is largely a question of preference and the important thing is consistency. To pick one way, be it tabs, spaces or a (very controlled) mix and use it consistently.
Lordrea wrote:I wish you could reformat the code GIT-side, allowing developers to write in whatever environment is best for them.
I guess by environment you mean style?
Since as far as I see there is nothing stopping you from using whatever environment (which I interpret as editor or IDE of choice) you want.

It's not really what you asked for, but there are tools to reformat source code based on rules (such as astyle).
If the code base had been consistent I guess it would have been possible to use something like that (post-checkout/pre-commit hooks). It would make git's status and diff functions and such more or less useless but it could work for simple editing.

Having different formats could make for some fun with cooperation too, say there is a problem on line x. If my code style includes breaking function parameters into different lines, or having brackets on one line conditionals and yours does not... Well, we can't talk about line x.
Lordrea wrote:But yeah, no point in arguing about it. Us Windows guys are a minority here both as a forum base and a developer base, despite our post-Gold user base targeted to a majority of Windows users (as gamers tend to be), and it shows in the code and development of the project. That's perfectly fine, so long as 1.0 is platform independent in a real sense, rather than designed for one OS, and patchable together on another.
I fail to see the connection between code style and platform support.
It is the actual code, not the formating of it, that affects the portability.
dhardy wrote:
Peppe wrote:Then again there are also people who don't use fixed width fonts...
I'm not the only one then.

Tabs are (or could be) fine for aligning comments, and would be OK for indentation if people stuck with a fixed width, but as it is tabs+python just leads to a headache...

Anyway, the reason I wanted to post was to suggest just using a code reformat tool (e.g. astyle). I've been using kdevelop's built-in astyle (ANSI) for a while and have been quite happy with the results; unless any of you have very strict preferences on horizontal and vertical spacing you aught to find the result perfectly reasonable.
pvdk wrote: To keep this a little more on topic: the codebase is now (since two days) completely converted to four spaces-only. So if anyone here wants to use post-git-magic to change this: you can without stuff breaking in terrible ways (I hope).
best regards,
Lukasz

Locked