Indenting with white spaces, tabs, and how many spaces or the tab width [closed]

You should always use the coding style that the project is already using if you are modifying an existing project.

That being said, if you are able to choose your own coding style for a new project I suggest that you use tabs to indent code and not spaces -- here is why. By using spaces you force all of the other developers working on the project to conform to your indentation preference whether that be 2 spaces or 4 or 8 (or whatever). But by using tabs each developer can view the code using their own preference. You should uses spaces and not tabs to format text (to line up variable names one per line, or to line up multi-line comments) because that will work with any tab width preference. However, when you indent code use tabs not spaces. In short, indent with tabs because indenting with spaces is rude.

• spaces because they render the same everywhere
• indent-width is context-dependent. runaway indentation is bad. generally, languages where you cannot easily reset the indentation to sane levels through named abstraction items (functions or methods) need narrow indentation.
• yes, see previous bullet

the claim that tabs allow individual developers to use different tab widths is false. consider

typedef __LA_SSIZE_T archive_write_callback(struct archive *,                                            void *_client_data,                                            const void *_buffer,                                            size_t _length);

if this was produced with tabwidth of 2, it would look like this with tabwidth = 4:

typedef __LA_SSIZE_T archive_write_callback(struct archive *,                                                                                        void *_client_data,                                                                                        const void *_buffer,                                                                                        size_t _length);

conversely, if it was produced with tabwidth = 8 and displayed with tabwidth = 4, the result would be

typedef __LA_SSIZE_T archive_write_callback(struct archive *,                        void *_client_data,                        const void *_buffer,                        size_t _length);

so if a project style guide requires tabs and says function parameters need to align as in the first code display, then there's a single correct tab width.

(another answer presents the same argument.)

a long-overdue edit:

i wholeheartedly agree with the opening sentence of the accepted answer, which is

You should always use the coding style that the project is already using if you are modifying an existing project.

the rest of that answer is, excuse me, rubbish, and i tried to explain why above.

the question of indentation style should only come up at the very beginning of any project, once it's settled it's done. i do believe that spaces are better than tabs, and have (again, i believe) rational arguments in support of my position, etc. but i'm not going to start discussions on this topic because they're useless: most programmers i met support their preferences with irrational arguments, and the rest have settled for a style which works best with their tooling (like me: "spaces because they render the same everywhere"), which i have no influence over in general.

anecdote: i once worked on a project which underwent a change of newlines, from \r\n to \n, and it turned out to be a pain in the ass any time we needed to go past the revision in svn blame. s/newlines/indentation/, and you have a nice argument against massive indentation changes in a running project.

An advantage to spaces vs tabs is alignment when wrapping long lines. If you use tabs, no matter what you do, the lines below will most likely not align, unless the editor has the same settings.

For example:

    result = variable_one + variable_two + variable_three +             variable_four;

If you use tabs, how to ensure that 'variable_four' will show up aligned if tab indentation changes?