On 06/14/2007 01:18 AM, Reagan Thomas wrote:
> .... In a collaborative project, spaces *will* get
> mixed in whether any one person likes it or not. The two, together,
> cause ugliness. So why not fully embrace the wonderful and (almost) free
> 0x20? As quoted above, any *modern* source editor will be happy to
> auto-indent to your columnar preference using tabs or spaces...
No doubt, in the FG source, there is quite an ugly
mixture of spaces and tabs. That's the fact of the
matter.
In theory, it doesn't have to be that way, and I've
seen plenty of collaborative projects where the issue
of tabs never came up. IMHO that's because there is
an important distinction:
-- a /collaborative/ project, versus
-- a multi-programmer project.
> any *modern* source editor will be happy to
> auto-indent to your columnar preference using tabs or spaces...
Heretofore the true nature of the problem has not been fully
discussed.
As analyzed at e.g. http://www.jwz.org/doc/tabs-vs-spaces.html
there are at least three separate issues involved. The issues
are somewhat related, but they are certainly not the same thing.
There are
#1: display-appearance-intention issues,
#2: file-encoding issues, and
#3: keyboard issues.
It hardly makes sense to expect the programmer to set the
tab-stops "correctly" if he doesn't even know what is the
nature of the problem he's trying to solve.
On 06/13/2007 11:32 PM, Jon S. Berndt wrote:
>> I won't use tabs, and remove them wherever I see them.
Given the exiting mess, adopting a policy of "no tabs in files"
seems like a step in the right direction, namely a way of
dealing with point #2, i.e. the file-encoding issues.
Getting rid of tabs in files is easier said than done. You
have to know what was /intended/. Some programmers intend
the tab-stops to be every 4 places, while some intend them
to be every 8 places (and other options are possible). And
in the case where one programmer has edited part of the file
and another programmer has edited another part, it is possible
to have a situation where each guy's part looks OK /to him/
but no mutually-consistent interpretation of the tabs is
possible.
Somebody with even a modest understanding of code should be
able to do the job. For each region of the file, set
tab-width to 4 and then set it to 8, and choose whichever
looks better. Then untabify the region.
*) This would be labor-intensive, but worth it in the long run.
*) Doing it imperfectly would be better than not doing it at all.
*) It doesn't need to be done all at once.
*) Once the job is done, simple scripts will suffice to
make sure the files /remain/ tab-free.
It must be emphasized that even though point #1 (i.e.
author's intention) governs point #2 (i.e. how untabification
is to be done), the converse is absolutely not true.
Even without tab characters in the file, the author can
still make decisions as to how the code should look,
and still has fully effective ways of implementing those
decisions.
Also let me recommend that untabification be done /separately/
from any edits that affect the function of the code. If
you want to edit a file, and it needs to be untabified, do
it in two steps, and submit two deltas.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
