Uri Guttman wrote: >>>>>> "SB" == Steve Bertrand <st...@ibctech.ca> writes: > > SB> Uri Guttman wrote: > >> > >> i wish i could understand my comments better! :) > > SB> Your name came up in "Perl Best Practices" (along with many > SB> others). You also made me realize that the use of $_ in a > SB> particular code snip was not a good idea. I didn't agree with you > SB> at that time, but I changed the practise anyway. Now I know for > SB> fact that just because it's easier to use in small context, it is > SB> far from long-term practicality. > > it was a very interesting and fun project, being on that large technical > editing team for that book. i hope i did my little bit to make it a > better book.
d'oh! I didn't know you were on the editing team. I'm sure that you already know where I found your name in the book. Believe it or not, it took Perl for me to actually stop skipping through the early stages in a book, and read *thoroughly* through ALL words that precede the first page. I'm thankful for this. In the last three books, I've likely learnt just as much by reading pre-TOC than post-TOC. In regards to the default var, I was referring to a post to the list. At first, I thought you misread the comment I made on how you helped me with the default var, as I thought I made it relatively clear that it was posted to this list. It took some reflection and a break for it to click that perhaps I didn't quite grasp what you said, about your "little bit". Indeed it did. All I have to say is that you told it to me here first, then I read it in some book ;) > SB> ...guideline. gotcha. That's what I thought. However, if I'm gearing up > SB> to do some semi-serious coding, a guide like this is fantastic. What I > SB> want: someone who takes over my job does not have to deal with what I > SB> had to as far as code goes. I like this idea that my code is reviewed > SB> before I write it. > > sure the book is fantastic. just keep in mind the guideline idea. it > doesn't matter which style guide you create but the fact that you have > one and adhere to it. and it isn't something written in concrete but a > living document. I hope to not ever have to lead a development team. I like to program myself, for myself. With that said, I'd like a semi-standardized way of formatting/stylizing just in case. Personally, I think in general, I'm there. > SB> Interesting. So, print is a debugging tool that does a complete full > SB> circle. Many on the list have helped me with using different debug > SB> techniques which have greatly helped me advance my understanding of what > SB> my code is actually doing. I appreciate what you say in your last > SB> paragraph, and although have questions, I don't think I need to ask > them. > > i started with punch cards. print was all you had besides thorough and > deep analysis of your code. that is a talent lost on too many coders > today. and even today proper use of print is better than any debug > tool. but it is still a skill to learn, where and what to print and how > to analyze the results. i have seen many good coders not get that and > they stick with debuggers. i find the simplicity of print and my total > control of what gets printed, etc better than learning more commands, > having to repeat a set of debug commands (yes, you can macro and preset > them but that is still more work), etc. print is always there in any > programs (and debuggers have issues with complex sets of processes, and > daemons and such). Very nicely said, and taken with significant weight applied. Steve
smime.p7s
Description: S/MIME Cryptographic Signature
