How about style nits instead?

Post #148,628 by ben_tilly 3/25/04 8:10:53 PM Reply	How about style nits instead? What if you can't write blank.gif? There is no error check on the open. There should be an `or die ("Can't write to blank.gif: $!")` in there. Wouldn't it be nice to be able to choose which file to write the gif to? If you have a function already, why not give the flexibility? A random point about Perl style. I've grown to like list-oriented constructs. So, rather than looping over the characters and printing each one, I'd print a list of things: `print GIF map {chr($_)} @chars;` A more controversial style nit. In what little quantitative data that exists on the topic, human comprehension is maximized at any indent in the 2-4 range. Indents of 6 or more are too extreme, people lose track. So while no indent is clearly best, some are clearly worse, including the 8 character indent. Cheers, Ben "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]
Post #148,644 by admin 3/25/04 8:56:59 PM Reply	Re: How about style nits instead? 1) Good point. It's a throwaway script, though, and I was more interested in showing people the trick than in writing bulletproof code. 2) See 1) 3) I'll have to remember that one. I know about map, of course, but hadn't connected it to print's ability to write lists. 4) They're tabs. Set your tabstops appropriately. Mine are at 4 spaces. :-) Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #148,649 by ben_tilly 3/25/04 9:09:37 PM Reply	Question 4) They're tabs. Set your tabstops appropriately. Mine are at 4 spaces. :-) Any idea how to set that in Mozilla? Alternately, can we make the tabstop a display preference in IWETHEY? ;-) Cheers, Ben "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]
Post #148,719 by cforde 3/26/04 3:42:00 AM Reply	can't get there from here In HTML consecutive white space characters are replaced by a single space. The only exception is in a preformatted area <pre>...</pre>. Within those tags white space is respected. As for tab handling within the preformatted area, the HTML 4 spec has this to say on the subject: The horizontal tab character The horizontal tab character (decimal 9 in [link\|http://www.w3.org/TR/html4/references.html#ref-ISO10646\|[ISO10646]] and [link\|http://www.w3.org/TR/html4/references.html#ref-ISO88591\|[ISO88591]] ) is usually interpreted by visual user agents as the smallest non-zero number of spaces necessary to line characters up along tab stops that are every 8 characters. We strongly discourage using horizontal tabs in preformatted text since it is common practice, when editing, to set the tab-spacing to other values, leading to misaligned documents. See it [link\|http://www.w3.org/TR/html4/struct/text.html#h-9.3.4\|here]. Eight shalt be the number thou shalt count, and the number of the counting shall be eight. :-) Have fun, Carl Forde
Post #148,721 by deSitter 3/26/04 4:20:29 AM Reply	Whom God favors, he shall be allowed the half measure of Tab -drl
Post #148,807 by ben_tilly 3/26/04 1:58:31 PM Reply	Look at the root post... Scott's code has tabs. And is formatted in a way that I dislike. I'd like to see the same code, formatted in a way that I like. This is possible if Scott substitutes hard spaces for the tab up front. Which he could do with his HTML handler. (But probably isn't worthwhile.) I was mostly asking as a way of pointing out to Scott that his note that I should just set the tabstop like he does isn't entirely feasible. Cheers, Ben "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]

Welcome to IWETHEY!