Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!chinacat!woody From: woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) Newsgroups: comp.lang.postscript Subject: Re: Bind problems Summary: long names. Message-ID: <1998@chinacat.Unicom.COM> Date: 10 May 91 03:50:23 GMT References: <1991May5.010114.24826@neon.Stanford.EDU> <488@heaven.woodside.ca.us> Organization: a guest of Unicom Systems Development, Austin Lines: 35 In article , jwz@lucid.com (Jamie Zawinski) writes: > > > I think the problem is using insanely short identifier names. This isn't > > /p /show load def > > You shouldn't be "picking weird names to try and survive." You should be > picking meaningful identifiers because it's good programming style in any > language. I have to agree with this in part. For a compiled language, it does not matter, as the variables are reduced to memory locations at compile or link time, but for interpreters, it does matter. Lookups take time. The scheme that Adobe uses, is fast, but still takes time. > > If you are writing a prolog that is large enough to be a transmission-time > hit in and of itself, like the prologs generated by most mac programs, and > by Adobe Illustrator, then you're doing something wrong already. It's not I think that the prolog generaly is a small portion of the file. The deeper problem as far as transmission times go, is the many references to a variable name. For example, if you have a variable called Current_X_Position You have 18 characters. If you use this each time you have to position a word on the page, it is going to add up to A LOT of transmission time, and space. Much better to use X in this case. In general, in an interpreter type language, the most frequently used variables should be as short as possible name wise, and the less frequently used variables should be longer. This does make a certain amount of sense, because a variable that is used infrequently, can be forgotten about easily, and if it has a cryptic name, it makes it that much harder for the next guy coming along to understand things. Programs should be written for the next programmer who will follow you, this applies to Postscript as well as any other language. Cheers Woody