On Thu, Aug 28, 2003 at 05:01:05AM -0500, Alex Malinovich wrote:
> On Thu, 2003-08-28 at 04:41, Steve Lamb wrote:
> --snip--
> > Yeah, on supported languages. I don't see the point of having a tool to
> > shoehorn the code into one bracket style and another tool to shoehorn it into
> > a different bracket style (and hope it remains decent) when one could just get
> > rid of the bloody brackets and be done with it. Hence my last stanza of
> > pseudo code showing all of the different styles being all the same code
> > without the brackets.
>
> But see my last paragraph in my previous post. Those brackets which make
> things so hard for you to read are the same brackets that make it easy
> for me to read. I look at Python code and I get lost. I guess my eyes
> are out of alignment or something, because I can't just look at
> indentation and see what corresponds to what. (Especially so with 4
> nested ifs, loops, etc) With bracketed languages, however, I can just
> keep a count of brackets in my head and always know where I am.
>
> Though I'm afraid that I do at least have to agree on the multiple ways
> of bracing. I much prefer method C in your descriptions, and method A I
> can deal with, but B drives me up a wall! Now if someone would devise a
> language with an extremely solid OO structure, good garbage collection,
> easy interfaces to C libraries, and most importantly, forced type C
> bracketing, I'd be in heaven! :)
I pretty much agree with this. I want the braces, in order to be sure
that I've read it in the same way as the compiler will.
Personally I use method C, partly because I think it looks neater and
partly because it uses fewer lines, so you can get more code on the
screen at a time. As far as reading other people's code is concerned,
as long as the block between the braces is indented - which it
invariably is - I don't let the positioning of the braces worry me too
much.
But I do insist on the braces being there! The Python method fails for
me on several counts:
- There isn't an explicit end-of-block delimiter. A tab to start a
block; what ends it? A tab that isn't there? Yuck.
- The delimiters are not visible characters. I want to *see* something
that says the block STARTS HERE and ENDS HERE. { and } are fine. begin
and end are OK. if-then-else-fi, while-do-done and the like are
bearable, though I prefer to use the same delimiters for everything.
Having the actual meaning as seen by the compiler/interpreter change
according to something as vague as how far across the screen the line
starts just fills me with a total lack of confidence that the code is
going to do what I want. Indentation is great as an *aid* to *human*
reading of the code, but for it to actually control the flow of
execution is RIGHT OUT.
- A corollary of this is that non-visible characters get munged. Yes,
I know this *shouldn't* happen, but it *does*. Too many passes through
stupid software that performs bad end-of-line translation between LF /
LF-CR / CR when it shouldn't, and you end up with a file with its line
structure wiped out. With explicit delimiters, it'll probably still
compile, and it's not too hard to whack line breaks in at appropriate
points to make it more-or-less readable. With delimiting based on
whitespace and line breaks, you've had it.
- A personal subset of this is that I HATE TABS! Each different
application that renders tabs has its own setting for how to do it, so
a file containing tabs looks fine in one app and looks like shit in
another. They result in "booby-trap" areas in the editor where the
cursor moves erratically and text jumps around the screen when editing
in an infuriating manner. They make some "peculiar" indentation tasks,
such as indenting switch statements in C neatly, really awkward. I
always turn them off, type multiple spaces to indent, and get really
annoyed when editing makefiles.
Guess I'll be sticking to C for a while yet...
--
Pigeon
Be kind to pigeons
Get my GPG key here: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F
Attachment:
pgpNRjTz84Ua6.pgp
Description: PGP signature