Polytropon wrote:
Okay, now I understand what you mean. "Consistency" refers to
the usage of spacing / tabbing for a given project that is
adopted by several programmers. Yes, I agree with that: It's
a very bad idea to have many different styles within the same

. . .

When I need to read / work with other's code, it's can develop
into problems. Natural habits like hitting the tab key are
very hard to change several times, for each project a different
. . .
Not all editors have this ability. And especially under low level
circumstances, e. g. editing with vi in SUM required in a maintenance
phase, you'll be happy about every keystroke you can save.

Most of my work is in a setting where the development machine is different from the target machine. Usually on a development machine you have the luxury of setting up all the tools you want and configuring them however you want. If you spend more time editing on the fly on a target machine, then that creates a different scenario, similar to doing sysadmin work.

I've made most of my main points, and I think we've got to where differences of opinion now rest mainly on taste, which in turn is often guided by what you're used to. Consequently it's not possible to get much further, especially with the "I like 4 spaces because I'm used to them" vs. "I like 8-level tabs because I'm used to them" argument.

I find that as I move from project to project, indentation standards do change. I find that where people have the resources to fully configure their development machines, reasonably thoughtful people who have experience in both standards end up converging on spaces being better than tabs because they are neater. I also find that, given such a configuration choice, more people find 4-space indentation looks better on the screen than go with 2 or 8 or 3.

Consequently I stick with '4 spaces for indentation' as my norm, and if I have to switch to something else for a given project because people are using that standard, then I will change my editor settings.

I'd like to add that tab based indentation is independent from
the functionalities of a specific editor. It's even handy for
printing where the tab width can be set to a certain value.
Okay, your counterargument could now be: "Who prints today
anyway?" :-)

I'm more concerned with things like diff listings, where lines are preceded with:
which breaks the tab indentation because everything is pushed over by a space or two.

Personally, I have the (maybe outdated) opinion that a programmer should
not only care for his programs to be valid, correct, efficient, well
structured, intended and documented, but also tidy and styled. What's
to understand from these words can be very individual, I agree.
We agree on this point, which is why we're having this discussion.
There are lots of cases where it's hard to make code line up the way you
want it with tabs.  Often code that looks good with one tab length
setting (say 8) doesn't look so good with another (say 4).  It gets
especially bad when there are a few space characters thrown in, which
people often do.

Okay, I didn't think of this. Taking this argument into mind, spaces
can be useful for parameter lists that don't fit into one line, but
should line up after the opening (, e. g.

        foofunction(&data, "%d,%d,%d", doodle.x, doodle.y, doodle,z,
                    foo, bar, pups, furz, "This is some stupid text.",

This wouldn't be easy to achieve with tabs, especially when their
width may vary.

Even an 'if' or 'while' statement that spans more than one line can have problems like this.

Nice discussion.


freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Reply via email to