Uri Guttman wrote: >>>>>> "SB" == Steve Bertrand <st...@ibctech.ca> writes: > > SB> - is "Perl Best Practises" what most of you use as general guidelines? > SB> IOW, if I continue reading it, will you be able to better understand my > SB> code (even though I stick with a few _small_ personal techniques)? From > SB> what I've read so far, I'm better understanding many of Uri's past > SB> comments a lot better > > i wish i could understand my comments better! :)
Over the last couple months, I've received comments on, and off list by yourself and others. I brought you up because you have been most direct, and the comments you have made were fresh in my mind as to what I was doing... most memorably, I created a dispatch table, you called it, and that very night I read about it in High Order Perl. Your name came up in "Perl Best Practices" (along with many others). You also made me realize that the use of $_ in a particular code snip was not a good idea. I didn't agree with you at that time, but I changed the practise anyway. Now I know for fact that just because it's easier to use in small context, it is far from long-term practicality. > remember (and damian says this in the preface), PBP is a guideline and > not a bible. you should make your own style guide and use the book for > many ideas (and i disagree with some and some are even considered obsolete!). ...guideline. gotcha. That's what I thought. However, if I'm gearing up to do some semi-serious coding, a guide like this is fantastic. What I want: someone who takes over my job does not have to deal with what I had to as far as code goes. I like this idea that my code is reviewed before I write it. > SB> - after many years, I've finally made the switch from a simple editor > SB> (ee) to Vim. A *huge* difference. In three days, I can't believe what I > SB> can do already. In all of my files, I've changed from \t to four-space > SB> tabs. Beyond that, I've run many of my module files into > SB> Perl::Critic. > > see, that is one idea that PBP and i agree upon. hard tabs (\t) is the > correct way to go with indents. they can be displayed with any actual > tab width by setting options in your editor. with fixed spaces you can't > do that. also you can tell the exact indent level by counting the > tabs. but is a 4 space indent 1 indent at 4 spaces or 2 at two spaces? ... did you mean 'disagree' about the tab, or am I misunderstanding? Reviewing the book, it states, under 2.11. Tabs: "Tabs are a bad choice for indenting code, even if you set your editor's tabspacing to four columns." Personally, I prefer using \t (TAB). Even though using '>' is not that bad, I'm used to using TAB. I was just testing out my new-found vi knowledge in multiple-file&window-search-replace, with :%s/\t/ /g ...with registers and macros 8) > SB> Is Perl::Critic recommended, and whether it is or isn't, are there any > SB> other Best Practises you can recommend, so I can review/change my > SB> existing code prior to moving forward again? > > i don't use it but i know plenty who do and it seems to be a good > idea. i would recommend it for most perl hackers and if you want to > enforce a known set of coding styles. i strongly enforce my own style as > i edit so i don't generally need an outside agent. but then i don't like > or need syntax highlighting or use debuggers other than print. Interesting. So, print is a debugging tool that does a complete full circle. Many on the list have helped me with using different debug techniques which have greatly helped me advance my understanding of what my code is actually doing. I appreciate what you say in your last paragraph, and although have questions, I don't think I need to ask them. > SB> - what in God's name is Abigail's last name? > > '' (the answer to your question) I knew pretty much for fact that this would be the answer, but honestly, I wanted to know how you would write the empty string, without thinking about it :) Steve
smime.p7s
Description: S/MIME Cryptographic Signature
