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
project.
. . .
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
rule.
. . .
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.",
doom[dee].quoggle);
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.
-Will
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
