I'm having trouble deciding when to use tabs versus spaces for leading whitespace...
* Existing C/C++ source files seem to mostly use tabs, but it's mixed in some places.
* Python (broctl) source files seem to be mostly spaces
* reST source files for documentation seem to be spaces
* Bro policy script source files look like they mostly use tabs
Not sure if I missed any cases, but what's standard convention, if there is one?
I kind of dislike tabs in any case, but even more than that I dislike mixing tabs/spaces or having to switch between the two frequently.
I'm not sure if anyone has strong opinions, but really all I'm looking for is some general rules that I should follow.
I'm having trouble deciding when to use tabs versus spaces for leading whitespace...
Not surprising. The underlying rules are:
* Existing C/C++ source files seem to mostly use tabs, but it's mixed in some places.
* Bro policy script source files look like they mostly use tabs
Indentation-style due to Vern -> Tabs. However, sometimes spaces are
slipping in via contributions from others (including me). That can
(and should) be normalized to tabs when noticed.
* Python (broctl) source files seem to be mostly spaces
* reST source files for documentation seem to be spaces
Indentation-style due to Robin -> Spaces.
Not sure if I missed any cases, but what's standard convention, if there is one?
I guess the implicit rule so far was that subprojects have their own
style conventions.
I kind of dislike tabs in any case, but even more than that I dislike
mixing tabs/spaces or having to switch between the two frequently.
I don't like tabs either but as you say, it's even worse to mix.
Btw, there's an item on our todo-list-once-we-find-a-student: finding
a tool that we can pipe all the source code through to canonify
formatting.
Btw, there's an item on our todo-list-once-we-find-a-student: finding
a tool that we can pipe all the source code through to canonify
formatting.
There's always expand/unexpand. And I would guess that git has a checkin
hook so you it should be easy to force this for leading whitespace
without being too annoying.
Without having used them, I think going from spaces to tabs
automatically is tricky, isn't it? Or said differently: just by doing
the conversion, one doesn't necessarily get the layout "right".
And I would guess that git has a checkin hook so you it should be easy
to force this for leading whitespace without being too annoying.
That's right, and if we have a consensus that we want to enforce this,
I can activate it.
Note however that when I wrote "canonyfing formatting" I was thinking
more broadly in terms of all the little things everybody does
differently with source code (parentheses placement, level of
indentation, etc.). A good candidate for doing that seems to be
uncrustify[1] but that needs somebody spending some time with its
plenty of options.
Yeah. That's usually the problem. Since space<-->tab conversion depends
on the tab-width that should be used. So I would not recommend do
convert automatically it.
But it might be nice to just have a checker, that can notify one if the
indentation style in a file is "wrong". Then one can manually check and
decide whether expand/unexpand is warranted.
(Note that for code that uses tabs, mixing spaces and tabs makes sense
in one particular case: continuations:
<TAB><TAB> this_is_a_function (it, has, very_very_very_many,
<TAB><TAB><SP><SP>...<SP> arguments, more_args, foo, bar);
just my 2ct
Gregor
BTW: I prefer tabs (but python more or less forces one to use spaces....)
Yeah. That's usually the problem. Since space<-->tab conversion depends
on the tab-width that should be used. So I would not recommend do
convert automatically it.
My suggestion is to balk when you attempt to and commit a change with
the leading whitespace that violates the policy.
And really: if anybody is using a tabwidth of other than 8, his/her code
already is messed up for the rest of us.
And really: if anybody is using a tabwidth of other than 8, his/her code
already is messed up for the rest of us.
I use the style that Gregor showed so changing the width doesn't affect anything....
(Note that for code that uses tabs, mixing spaces and tabs makes sense
in one particular case: continuations:
<TAB><TAB> this_is_a_function (it, has, very_very_very_many,
<TAB><TAB><SP><SP>...<SP> arguments, more_args, foo, bar);
(Note that for code that uses tabs, mixing spaces and tabs makes sense
in one particular case: continuations:
<TAB><TAB> this_is_a_function (it, has, very_very_very_many,
<TAB><TAB><SP><SP>...<SP> arguments, more_args, foo, bar);
Yeah, I agree about that.
The case I think we were talking about would be mixing leading whitespace styles. e.g. if there's a function formatted like you had with tabs, then it would be bad to mix in some more code that looks like
int myClass::Method(int foo, char* bar,
<tab><tab> int another_argument)
where if you expand those tabs, you'll find that the "int" for
"another_argument" is right below the "int" for "foo".
But then the alignment depends on tab width, right? If we're going to use that style, we should all agree on what that width is.
Another way to do it is having the continuation line(s) contain a number of tabs equal to the level of indentation plus however many spaces are necessary to get the right alignment. Then everyone would write code that aligns the same regardless of what tab width they're using. So in the example Vern gave, there wouldn't be any tabs, just spaces because the indentation level of that code is 0.
But then the alignment depends on tab width, right?
Yep. And for the Bro sources, that has always been 8 columns.
Another way to do it is having the continuation line(s) contain a number
of tabs equal to the level of indentation plus however many spaces are
necessary to get the right alignment.
That's okay with me in principle. But it's pretty fundamental that we
need a pretty printer that enforces stuff like this. The current style
is the way it is in part due to how vi treats auto-indentation.
The underlying rules are: