Ken Moffat wrote:
On Thu, May 21, 2015 at 08:49:33PM -0500, Bruce Dubbs wrote:
Ken Moffat wrote:
Bruce, I can see that you use tiny tab spacing in your own code, but
what is your objection to tabs in a patch ? If upstream uses tabs,
then tabs are the right thing for the patch. For a sed, spacing and
alignment are optional.
My objection to embedded taps is that different users have different
settings for tab stops. The files look a lot different if viewed in an
editor and in a cat. If spaces are used, then the file looks identical for
everyone no matter what tools are used.
The content of a patch (i.e. the actual diff) ought to match the
standards of the project to which it is being applied - i.e the
upstream, not our own individual preferences.
Yes I said that. The patch needs to match upstream in order to work.
As to what is in the description, I do not see any particular reason
to care if it uses tabs or spaces. So, if I cherry-pick a commit, I
will probably paste the description from the original commit after
re-diffing.
The headers I saw in Douglas' patch looked wrong because there were embedded
tabs.
At one time, the difference in spaces and tabs made a difference in file
size. Today, a few dozen bytes in the file size is quite negligible.
As far as small tab sizes go (indentation), there has been quite a bit of
research (admittedly old now), that says that the readability of source code
is optimal at 2-4 spaces for indentation. I split the difference and use 3.
"Then shalt thou count to three, no more, no less.
Three shall be the number thou shalt count,
and the number of the counting shall be three."
;-)
For C-style code, 8 helps show the structure of a long function much
better IMHO.
That's your opinion. Actual research, including my own formal research, shows
differently. Would you like to read my dissertation? The title is "The Effect
of Comment and Code Style on Software Maintenance."
I didn't think so.
For bash, which is what I write these days, I find 8 easier to
follow - but I do drop to 4 if I need to nest 'if' statements, and
sometimes I will indent two spaces for a continuation.
Also, for indentation of fixed pitch fonts (for example 12 point monospaced)
is about 6 points or .083 inch. Indentation of 8 characters then is about
2/3 inch. In a printed text, how often do you see that much indention in
printed (paper) documents? Rarely because 1) it wastes space, and 2)
because it actually makes comprehension slower.
For a printed text, all the considerations are different, and small
indentation often makes a lot of sense. You might even use a
proportional font if printing, depending on the content.
I was actually referring to C code. Have you ever seen code with indents 10
levels deep. I have and it was horrible. Changing to a smaller indent improved
things a little and was needed to just understand the code enough to rewrite it.
If you use vim with the right configuration, the tab key works as you want it
to. It just inserts the appropriate number of blanks instead of an actual tab
character. I'm sure other editors have the same capability.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
