tabs vs spaces
==============

or: how to begin a codestyle flamewar.


disclaimer: the tab-space discussion will never have a final solution.
            this is mainly JJ's attempt of uniting the world.


introduction
------------

most [sft]tech guys prefer tabs over spaces, as they use less memory,
and grant more freedom and flexibility. and we love freedom.

tabs:

* PRO: you can configure their width
* PRO: they use only one byte memory
* CON: some idiots think they type tabs,
       but insert spaces and the whitespace consistency faks up
* CON: alignment of things fuck up because of flexible width (ascii art...)

spaces:

* PRO: always have a fixed size -> can be used for alignment
* PRO: any idiot can press the space bar for making space
* CON: always have a fixed size -> not configurable for indentations

=> we love flexibility and would like tabs for indentation.
   so, we are using tabs for indenting the C++ code.
   but: alignments by tabs are impossible to be consistent.
   => spaces are needed for ascii arts and alignments


solution: use BOTH tabs and spaces.
--------

yes, more idiots will fail writing it the correct way,
we have to ignore them or fix their code.

example:

```
--->  == tab
.     == space

class LØL {
--->int gschicht;

--->void add_gschicht(struct my_struct_with_long_name *ie,
--->..................int addition) {
--->--->this->gschicht += ie->member + addition;
--->}
};
```

yeah, i'm also ok when you write all the parameters in one line,
i think this proposal's readability is better though.

this example should show you that with this technique:

* you keep the adjustable tab-width
* you keep the consistent alignments
* you may now travel to the nearest flower meadow
  and start picking your favorite plants

```
=> use tabs for indentation
=> use spaces for alignment
```

python
======

problem description
-------------------

the previous section proposes a perfect indentation method.
this all seems nice and rainbow-vomiting good.
but, the python developers decided to use 4 spaces instead of one tab
for their indentation, see PEP8.

for a long time, JJ was rebellious against using spaces for indentation
in python and used tabs, but he now gave up.

too many people complained about breaking rules, and the worst issue:
"i won't reconfigure my editor for you"

=> this led to searching for a solution that satisfies everybody:

* blabla, standard, guidelines, use spaces, PEP8 !!1111
* wraaah, i wanna use tabs, PEP8 can suck my %s

and, you may have guessed it, we found one.

solution
--------

and who will save us? GIT!

why git? git manages the files in your/our project folder
and sends stuff to remote repos.

=> let git replace tabs n spaces they way you like it.


that way:

* you may still use tabs transparently on your local machine for python code
* but the repo will contain spaces only

=> your files will have tabs, but git stores them as spaces.

wheeeee \o/


solution setup
--------------

in your local repo, create/edit .git/info/attributes:

    *.py  filter=tabspace

then configure the repository:

    git config filter.tabspace.smudge 'unexpand --tabs=4 --first-only'
    git config filter.tabspace.clean    'expand --tabs=4 --initial'

`expand` and `unexpand` are part of the GNU coreutils,
you can adapt the invocation at your needs (see `man 1 expand`).

you can use `git config --global ...` to store these filters in your
`~/.gitconfig` instead of saving them into this repo.

update all files in the local repo to have tabs instead of spaces:

    git checkout HEAD -- **

when you commit and push your code, the tabs will be saved as spaces.


conclusion
==========

the hours spent on the tabs-vs-spaces flamewars will never end.
please people, maybe these proposals will shut you up.
instead of flaming the shit out of each, you could have contributed epic code to openage.

so stop flaming, and code stuff. with love.

i hate you all. seriously.