>>>>> "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. 

  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.

  >> 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?

  SB> ... did you mean 'disagree' about the tab, or am I misunderstanding?
  SB> Reviewing the book, it states, under 2.11. Tabs:

  SB> "Tabs are a bad choice for indenting code, even if you set your editor's
  SB> tabspacing to four columns."

i believe damian has changed his view on that one. hence my other
comment that some things in PBP are obsolete. hard tabs are the best
indent as long as you stick to a clean indent style and enable the
visual tab expansion in your editor to your liking.

  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. 

  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).

uri

-- 
Uri Guttman  ------  u...@stemsystems.com  --------  http://www.sysarch.com --
-----  Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- http://perlhunter.com/college.html ---------
---------  Gourmet Hot Cocoa Mix  ----  http://bestfriendscocoa.com ---------

-- 
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/


Reply via email to