Eclipse is very nice, but :(...

Hans Fugal hans at fugal.net
Tue Jun 20 17:23:48 MDT 2006


On Tue, 20 Jun 2006 at 17:48 -0500, Michael Halcrow wrote:
> On Tue, Jun 20, 2006 at 12:44:23PM -0600, Hans Fugal wrote:
> > Let's just use occam's razor and keep it simple, folks. Tabs are 8
> > spaces. If you want something else, use spaces.
> 
> While we're all on the pedantical sled...
> 
> http://en.wikipedia.org/wiki/Occam%27s_razor
> 
> ``Furthermore, when multiple competing theories have equal predictive
> powers, the principle recommends selecting those that introduce the
> fewest assumptions and postulate the fewest hypothetical entities. It
> is in this sense that Occam's razor is usually understood.''

fewest assumptions: make no assumptions about the size of tab, or if you
must then assume it's 8 spaces which is by far the safest assumption. 
fewest hypothetical entities: everything represents spaces the same, so
everything is the same basic hypothetical entity... yeah whatever

But I plead guilty regardless. :) I should have stuck with KISS.

> > While I'm here I might as well weigh in on the rest of the
> > opinions. :) I like 4 spaces in C-like languages, 2 spaces in ruby
> > or XML. I don't buy the "8-space tabs in C if you can't read it
> > you're an idiot programmer" argument,
> 
> If you have trouble fitting your code into 80 columns with 8-space
> tabs, then more likely than not, your are trying to do too much in a
> single function, and your code's maintainability suffers. 

Prove it. I don't fall for sweeping generalizations even when they come
from people I respect, like Linus and you.

> Or you are missing a wonderful opportunity to introduce a well-placed
> goto.

:)

> > I find that frequently it takes nearly 60 characters to write a
> > decent line of code using some APIs or well-named variables, and
> > breaking lines is almost always less readable than not breaking
> > them, so 8-space indentation makes a real mess sooner rather than
> > later.
> 
> The Linux kernel code base begs to differ.

The kernel codebase is written in C and is fairly flat. In this case
8-char tabs works fairly well. If you read my original post I hope it is
clear that I was primarily talking about other languages where
8-space indentation quickly gets ridiculous.

In any case, the kernel doesn't beg. It conquers sleeping pheasants in
their sleep.

> The 8-space indentation helps discipline the developer to break his
> code into sane and manageable segments.

And placing cookies on your hands is a great way to discipline the piano
player to maintain good hand posture. Fins and kickboards are excellent
in developing discipline in the swimmer's stroke. 

>         while (index < new_end_page_index) {
>                 /* Fill all intermediate pages with zeros */
>                 rc = write_zeros(file, index, 0, PAGE_CACHE_SIZE);
>                 if (rc) {
>                         ecryptfs_printk(KERN_ERR, "write_zeros(file=[%p], "
>                                         "index=[0x%.16x], "
>                                         "old_end_pos_in_page=[d], "
>                                         "(PAGE_CACHE_SIZE - new_end_pos_in_page"
>                                         "=[%d]"
>                                         ")=[d]) returned [%d]\n", file, index,
>                                         old_end_pos_in_page,
>                                         new_end_pos_in_page,
>                                         (PAGE_CACHE_SIZE - new_end_pos_in_page),
>                                         rc);
>                         goto out;
>                 }
>                 index++;
>         }
> ---
> 
> Yuck. I should have just run past the end on that one. But the rest of
> the code is left in decent shape. For instance:

So you'd rather use whitespace as a weapon against the ever-evil people
who might want to nest a few levels, than have readable code in all
reasonable cases. That's a valid viewpoint, but it is not mine.

> Okay; that's not so great either. I really need to do something about
> the overly-verbose filesystem object interpolation calls (i.e.,
> ecryptfs_inode_to_private). But that's just about the right size for a
> function, it stays within 3 indentations, the ||'d values in the
> conditional are broken up into their own lines, and it is pretty
> maintainable. Looking back, perhaps it would be best to just let most
> of the printk's run past the end rather than breaking the quoted
> material in awkward places.

Yes, that's where I usually find myself going past 80, is in printf
sorts of situations.
 
> Well, you get the idea. There is a very good reasons for requiring
> developers to stick with 8 tabs/80 columns in general, not the least
> of which is to encourage the developer to keep the code broken up into
> concise functional units that are easily understandable and
> maintainable.

Pardon, but that seems like the stupidest reason for how many spaces to
use as indentation. I have always thought so. It is just ridiculous to
me to control one aspect of behavior with an arbitrary and
barely-related restriction on an entirely different aspect of behavior.
It's like arguing that the reason all children should go to school is so
that housewives will play bridge. (or perhaps arguing that housewives
should play bridge so that they will be inclined to send their children
to school)

-- 
Hans Fugal ; http://hans.fugal.net
 
There's nothing remarkable about it. All one has to do is hit the 
right keys at the right time and the instrument plays itself.
    -- Johann Sebastian Bach
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : http://plug.org/pipermail/plug/attachments/20060620/695222c0/attachment.bin 


More information about the PLUG mailing list