Fix code style

[GoogleCodeExporter]

Current plan: Linux code style but with 4 spaces for indentation. 2 levels of 
indentation (8 spaces) are not replaced with tabs.

Existing code can be converted to this style by running `indent -linux -i4 
-nut`.

This change will break any outstanding patches and will make merges across this 
commit very difficult. So this will be the last change before the v0.3 release.

Original issue reported on code.google.com by paul.betafive on 1 Feb 2014 at 2:31

[GoogleCodeExporter]

The most of the editors understand VIM modelines, no matter if VIM/VI itself or 
some 
IDE editor. With this it's easier to just write the code down without to check 
if the indentation for every line or fight with various settings within the IDE.

A modline hast to be placed on top of the source code file or at the end, so 
the 
following example will basically work. This does use a tab-stop-width of 4, 
expand every tab into 4 spaces, uses auto indentation with some smart functions 
after keywords (like if, while,*) and delete 4 spaces in case of use of 
backspace. And at least it set a text-width to 76 characters.

/* -*- Mode: C; tab-width: 4; expandtab; autointend; smartintend; softtabstop 
4; shift-width: 4; text-width 76; */
/* vim: set ts=4 et ai si sts=4 sw=4 tw=76: */

The first line isn't needed, it's just to understand what settings are done in 
the other line. Remind the editor reads this line while opening the file, so 
C&P will 
just work after reopen the file.
Look the following cast to understand the relations between tabstop, 
softtabstop and 
shiftwith inside the modline.
http://vimcasts.org/episodes/tabs-and-spaces/

I suggest to place a modeline like this in every file that is touched.

Original comment by c.schoen...@gmail.com on 10 Feb 2014 at 1:34

[GoogleCodeExporter]

Is there any reason for not using tabs? If tabs are used correctly, then moving 
from tab == 4 spaces to tab == 8 spaces should not have a lot of repercussion 
on the code presentation.

I agree that it's a matter of style. I tend to think that it's good to not 
multiply the different styles when working on different project so I would 
prefer to use the linux style, but that's only my own (read: not-that-relevant) 
opinion (although this may have some interesting drawback, like the possibility 
to use the kernel-provided checkpatch.pl tool to check for the validity of 
patches and reject them early if needed).

By the way, I believe comment #1 is quite interesting although I'm not sure 
that there are a lot of editors that really understand the vim modelines 
natively (some editors (including gedit) may understand them after the 
installation of a plugin ; other editors such as Kate or the venerable emacs 
have their own modeline syntax which is incompatible ; and finally, a lot of 
editors (including eclipse and a large majority of non-linux editor) does not 
even consider them). As one might find by browsing the intarweb, the agreement 
on a particular style is mostly a social issue with virtually no known fully 
working technical solution. Again, something like checkpatch.pl might prove 
beneficient here since it will tag the biggest style violation early (before 
the patch is submitted if the submitter does its job correctly). 

Original comment by emmanueldeloget53 on 4 Jun 2014 at 12:59

[GoogleCodeExporter]

I added vim modelines recently as those are useful to me if no-one else.

The problem with the current style is that it is inconsistent. We discussed 
things on the mailing list and settled on an almost-linux style. 4 spaces were 
preferred to 8 as it fits more layers of conditionals into an 80 character 
width. I know deeply nested conditionals are bad, but many already exist in 
opkg and it will take a while to clean them all up.

Original comment by paul.betafive on 4 Jun 2014 at 1:03

[GoogleCodeExporter]

This is finally fixed in master :)

Original comment by paul.betafive on 19 Dec 2014 at 12:39

• Changed state: Fixed