Re: Coding best practices
On Friday 14 August 2009 16:18:38 Shawn H. Corey wrote:
Shlomi Fish wrote:
My recent impression of most Perl programmers has been the opposite -
most of them have been too lazy or unmotivated to learn about the perl -d
flag (or similar interactive debuggers), and are always using print's or
going on IRC asking What is wrong with this code? I find the perl
debugger an indispensable tool and am actively using it.
While print's have their rightful place, I still think the perl debugger
is too under-used.
We will encourage you to develop the three great virtues of a
programmer: laziness, impatience, and hubris. -- Larry Wall
from http://www.c2.com/cgi/wiki?LazinessImpatienceHubris
The last time I used a debugger was on a large C project. For small
programs and unit testing, it was fine, but when things went over 2000
lines, it became increasingly frustrating to use. Of course, print
statements have their limits too but it happens at about 5000 lines.
According to SLOCCount by David A. Wheeler, for Freecell Solver's
trunk/fc-solve/source :
{{
Totals grouped by language (dominant language first):
ansic:16832 (80.85%)
perl: 2914 (14.00%)
python: 446 (2.14%)
sh: 354 (1.70%)
ruby: 274 (1.32%)
Total Physical Source Lines of Code (SLOC)= 20,820
}}
I've successfully used gdb on this application, and I used it in the past,
before I heavily refactored and trimmed it lately. Granted, it's an almost
pure ANSI C program that doesn't do a lot of system stuff, but it is still
pretty complex and pedantic. I've also used gdb on the GIMP and Subversion,
which are much larger than Freecell Solver. In Subversion I ran into a (yet
another) gdb bug, but they are otherwise OK.
I'm using debuggers simply because I know it's often faster and quicker to use
them than to use traces. I'm not saying traces don't have their place, but
debuggers are often time saving.
I also wrote some gdb scripts:
http://www.mail-archive.com/linux...@cs.huji.ac.il/msg54660.html
Regards,
Shlomi Fish
I use Data::Dumper a lot, so most of my debugging statements have
Dumper in them, making them easy to find. For those that don't, I add
# TEMPORARY at the end. And I leave them behind; I just put a # in
front of them. :)
--
-
Shlomi Fish http://www.shlomifish.org/
Stop Using MSIE - http://www.shlomifish.org/no-ie/
God gave us two eyes and ten fingers so we will type five times as much as we
read.
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
Re: Coding best practices
Chas. Owens wrote: On Fri, Aug 14, 2009 at 00:21, Uri Guttmanu...@stemsystems.com wrote: snip 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). snip I have seen the opposite: too many coders sticking with print instead of picking up a debugger when the situation called for one. I tend to debug with a combination of looking at the code, logs, and print statements, but a good visual debugger can be a godsend. To anyone using Perl, I also highly recommend the debugger. I was shown by people who know who they are on this list several interesting things that I didn't know. Most importantly, I was taught that I could 'watch' one or more certain variables while stepping or breaking, so you can see what happens live-time. This was/is invaluable to me to get an understanding of what is really happening. I found watching changes critical to solidifying my understanding of operator precedence: # perl -d ./types.pl DB1 w $type DB2 c Watchpoint 0: $type changed: old value: '' new value: 'user_info' Much of the Perl debugger can be learnt here: http://perldoc.perl.org/perldebtut.html http://perldoc.perl.org/perldebug.html Inserting a breakpoint is very easy. You can put it right in your code, and unless you run your program with -d, the debug code may as well be a comment (ie, there are no visual queues that it exists). Insert a breakpoint (breakpoint == a place where you can tell the debugger to stop) like this: $DB::single=2; Then, when you run your program with -d as noted above, you can just type 'c' in the debugger to jump right to that line of code! ...fancier things can be found by searching the archives, some of which would probably coincide with my name in the search box (such as comments related to the 'watch' command). Steve ps. just to play, I did this: http://ipv6canada.com/age.debug smime.p7s Description: S/MIME Cryptographic Signature
Re: Coding best practices
On Fri, 14 Aug 2009 00:52:24 -0400, Chas. Owens wrote: I have seen the opposite: too many coders sticking with print instead of picking up a debugger when the situation called for one. I tend to debug with a combination of looking at the code, logs, and print statements, but a good visual debugger can be a godsend. The biggest problem with print statements is that you are modifying the code and you might inadvertently change something or leave a debug statement in the code. Right. Not to mention if you want to follow the execution into code that resides in a system-wide library. The effort involved there in using print () statements is considerably larger than running the debugger. -- Peter Scott http://www.perlmedic.com/ http://www.perldebugged.com/ http://www.informit.com/store/product.aspx?isbn=0137001274 -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Coding best practices
Shlomi Fish wrote: My recent impression of most Perl programmers has been the opposite - most of them have been too lazy or unmotivated to learn about the perl -d flag (or similar interactive debuggers), and are always using print's or going on IRC asking What is wrong with this code? I find the perl debugger an indispensable tool and am actively using it. While print's have their rightful place, I still think the perl debugger is too under-used. We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris. -- Larry Wall from http://www.c2.com/cgi/wiki?LazinessImpatienceHubris The last time I used a debugger was on a large C project. For small programs and unit testing, it was fine, but when things went over 2000 lines, it became increasingly frustrating to use. Of course, print statements have their limits too but it happens at about 5000 lines. I use Data::Dumper a lot, so most of my debugging statements have Dumper in them, making them easy to find. For those that don't, I add # TEMPORARY at the end. And I leave them behind; I just put a # in front of them. :) -- Just my 0.0002 million dollars worth, Shawn Programming is as much about organization and communication as it is about coding. I like Perl; it's the only language where you can bless your thingy. -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Coding best practices
On Fri, Aug 14, 2009 at 09:18, Shawn H. Coreyshawnhco...@gmail.com wrote: snip The last time I used a debugger was on a large C project. For small programs and unit testing, it was fine, but when things went over 2000 lines, it became increasingly frustrating to use. Of course, print statements have their limits too but it happens at about 5000 lines. I use Data::Dumper a lot, so most of my debugging statements have Dumper in them, making them easy to find. For those that don't, I add # TEMPORARY at the end. And I leave them behind; I just put a # in front of them. :) snip Are you using a visual debugger or a commandline debugger? I find this makes all of the difference in the world. Try downloading a trial version of [Komodo IDE][1] or using [ddd][2]. I detest IDEs, but visual debuggers are incredibly more useful than commandline debuggers, and I find most people's aversion to debuggers goes away when they are presented with one. Another very useful tool is the REPL. Take a look at [Carp::REPL][3] and [CGI::Inspect][4] which are like print statements on steroids. [1] : http://www.activestate.com/komodo/ [2] : http://www.gnu.org/software/ddd/ [3] : http://search.cpan.org/dist/Carp-REPL/lib/Carp/REPL.pm [4] : http://search.cpan.org/dist/CGI-Inspect/lib/CGI/Inspect.pm -- Chas. Owens wonkden.net The most important skill a programmer can have is the ability to read. -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Coding best practices
Chas. Owens wrote: Are you using a visual debugger or a commandline debugger? Command line, they didn't have visual debuggers back then. :) -- Just my 0.0002 million dollars worth, Shawn Programming is as much about organization and communication as it is about coding. I like Perl; it's the only language where you can bless your thingy. -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Coding best practices
Chas. Owens wrote: Are you using a visual debugger or a commandline debugger? I find this makes all of the difference in the world. Try downloading a trial version of [Komodo IDE][1] or using [ddd][2]. I detest IDEs, but visual debuggers are incredibly more useful than commandline debuggers, and I find most people's aversion to debuggers goes away when they are presented with one. Another very useful tool is the REPL. Take a look at [Carp::REPL][3] and [CGI::Inspect][4] which are like print statements on steroids. [1] : http://www.activestate.com/komodo/ [2] : http://www.gnu.org/software/ddd/ [3] : http://search.cpan.org/dist/Carp-REPL/lib/Carp/REPL.pm [4] : http://search.cpan.org/dist/CGI-Inspect/lib/CGI/Inspect.pm Komodo doesn't work on my machine and since it's propriety, I can't get its source to compile it. DDD is little more than a GUI wrapper around a command-line debugger. As for the Perl modules, they might have come in handy back then, but now I have worked out techniques to do debugging without them. So, they're little more than something else I have to remember. Little value added, at least, for me. -- Just my 0.0002 million dollars worth, Shawn Programming is as much about organization and communication as it is about coding. I like Perl; it's the only language where you can bless your thingy. -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Coding best practices
On Fri, Aug 14, 2009 at 09:59, Shawn H. Coreyshawnhco...@gmail.com wrote: Chas. Owens wrote: Are you using a visual debugger or a commandline debugger? Command line, they didn't have visual debuggers back then. :) snip Why, back when I was a lad we had to debug things by checking the [wavelength of the RF output][1]... [1] : http://www.dadhacker.com/blog/?p=1120 -- Chas. Owens wonkden.net The most important skill a programmer can have is the ability to read. -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Coding best practices
On Fri, Aug 14, 2009 at 10:20, Shawn H. Coreyshawnhco...@gmail.com wrote: snip Komodo doesn't work on my machine and since it's propriety, I can't get its source to compile it. snip Odd, it works just fine on my OS X box, my Linux box, and I hear it works in MS Windows. You must be using a flavor of BSD other than OS X. snip DDD is little more than a GUI wrapper around a command-line debugger. snip And your point is? That GUI Wrapper is what makes a visual debugger better than a commandline debugger. And I wouldn't say little more. It adds graphing capabilities that the commandline debugger never dreamed of. snip As for the Perl modules, they might have come in handy back then, but now I have worked out techniques to do debugging without them. So, they're little more than something else I have to remember. Little value added, at least, for me. snip The point of a REPL is that you can drop into the code at that point in the execution and run arbitrary code and then _restart_ the original code. This means you can do everything the print statement could do and more. You can fix bad values to see if that corrects the problem, change the data to try to trigger the bug, etc. -- Chas. Owens wonkden.net The most important skill a programmer can have is the ability to read. -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Coding best practices
Chas. Owens wrote: On Fri, Aug 14, 2009 at 09:59, Shawn H. Coreyshawnhco...@gmail.com wrote: Chas. Owens wrote: Are you using a visual debugger or a commandline debugger? Command line, they didn't have visual debuggers back then. :) snip Why, back when I was a lad we had to debug things by checking the [wavelength of the RF output][1]... [1] : http://www.dadhacker.com/blog/?p=1120 Well, that's better than flashing LEDs on the front panel. :) -- Just my 0.0002 million dollars worth, Shawn Programming is as much about organization and communication as it is about coding. I like Perl; it's the only language where you can bless your thingy. -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Coding best practices
Chas. Owens wrote: On Fri, Aug 14, 2009 at 10:20, Shawn H. Coreyshawnhco...@gmail.com wrote: snip Komodo doesn't work on my machine and since it's propriety, I can't get its source to compile it. snip Odd, it works just fine on my OS X box, my Linux box, and I hear it works in MS Windows. You must be using a flavor of BSD other than OS X. I have a PowerBook G4. The only software for it these days is open source. The advantage of old hardware: no malware. The disadvantage: no WoW (of course, that might be a good thing). -- Just my 0.0002 million dollars worth, Shawn Programming is as much about organization and communication as it is about coding. I like Perl; it's the only language where you can bless your thingy. -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Coding best practices
Steve == Steve Bertrand st...@ibctech.ca writes:
SB - what in God's name is Abigail's last name?
'' (the answer to your question)
Steve I knew pretty much for fact that this would be the answer, but honestly,
Steve I wanted to know how you would write the empty string, without thinking
Steve about it :)
Of course, PBP would recommend q{}.
:-)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
mer...@stonehenge.com URL:http://www.stonehenge.com/merlyn/
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
Re: Coding best practices
Steve == Steve Bertrand st...@ibctech.ca writes: Steve Interesting. So, print is a debugging tool that does a complete full Steve circle. Many on the list have helped me with using different debug Steve techniques which have greatly helped me advance my understanding of what Steve my code is actually doing. http://www.stonehenge.com/merlyn/LinuxMag/col76.html -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 mer...@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Coding best practices
From: Shawn H. Corey shawnhco...@gmail.com I use Data::Dumper a lot, so most of my debugging statements have Dumper in them, making them easy to find. For those that don't, I add # TEMPORARY at the end. And I leave them behind; I just put a # in front of them. :) I tend to not indent them. So they stick out and since pretty much all code is indented at least one level in any nontrivial program, I only have to look for /^print/. Whether I leave them behind or not depends on whether I expect to need them again. Usually I remove them after I'm done debugging. Jenda = je...@krynicky.cz === http://Jenda.Krynicky.cz = When it comes to wine, women and song, wizards are allowed to get drunk and croon as much as they like. -- Terry Pratchett in Sourcery -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Coding best practices
There are many senior (ie. *very* *very* respected/acknowledged in the community), Perl programmers on this list, who still take the time to answer questions on what may seem like an insignificant list. Many of these people have helped me, even directly. The more I read the books, the more I appreciate the 'chapters' prior to the table of contents. I would never have guessed/believed that so many authors and people who are continuously mentioned in the 'acknowledgement/appreciation' sections would stick to the roots for so long, and continue to have desire to not think they are above themselves. It goes without saying that there are also many other people here who I haven't come across their name in a book (yet) that deserve this same accreditation. I often wonder how authors decide on who's name to insert... it's just easier to say you know who you are ;) Everyone here has made me realize how much I really enjoy programming (Perl). Knowing who reads this list reinforces the fact that those who produce the literature are here to stay, and to help. Not only do I appreciate those who reply day-to-day, but also those who speak up when a question/technique/idiom is right up their alley. I also enjoy when the 'big boys' stand up to one another from time to time. Enough with the sentimental stuff now. A few questions: - is Perl Best Practises what most of you use as general guidelines? IOW, if I continue reading it, will you be able to better understand my code (even though I stick with a few _small_ personal techniques)? From what I've read so far, I'm better understanding many of Uri's past comments a lot better - after many years, I've finally made the switch from a simple editor (ee) to Vim. A *huge* difference. In three days, I can't believe what I can do already. In all of my files, I've changed from \t to four-space tabs. Beyond that, I've run many of my module files into Perl::Critic. Is Perl::Critic recommended, and whether it is or isn't, are there any other Best Practises you can recommend, so I can review/change my existing code prior to moving forward again? - what other Perl lists/sites can you recommend to me? fwiw, I prefer mail lists or newsgroups, as I don't have to bother browsing all over the web. - what in God's name is Abigail's last name? Steve smime.p7s Description: S/MIME Cryptographic Signature
Re: Coding best practices
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! :) 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!). 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? 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 - what in God's name is Abigail's last name? '' (the answer to your question) 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/
Re: Coding best practices
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-filewindow-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
Re: Coding best practices
On Thu, Aug 13, 2009 at 20:25, Steve Bertrandst...@ibctech.ca wrote: snip - is Perl Best Practises what most of you use as general guidelines? IOW, if I continue reading it, will you be able to better understand my code (even though I stick with a few _small_ personal techniques)? From what I've read so far, I'm better understanding many of Uri's past comments a lot better snip PBP is a collection of the folk wisdom at the time of writing. Most things in it are good. Some have not stood the test of time (inside out objects). snip - after many years, I've finally made the switch from a simple editor (ee) to Vim. A *huge* difference. In three days, I can't believe what I can do already. snip I love Vim, but you should also look at Emacs. You should also throw it away in disgust, but you should at least look at it to know that you are not one-of-those-people. snip In all of my files, I've changed from \t to four-space tabs. Beyond that, I've run many of my module files into Perl::Critic. snip Spacing, like editors, is a religious issue. I am an eight character hard tab programmer for the same reasons Uri mentions. Another benefit of eight character tabs combined with an eighty character line limit is that your indent level servers as a warning that your code is getting too deeply nested. snip Is Perl::Critic recommended, and whether it is or isn't, are there any other Best Practises you can recommend, so I can review/change my existing code prior to moving forward again? snip Perl::Critic is good. Many of its rules come straight from PBP; however, like PBP, it is important to remember that parts of it are just advice. snip - what other Perl lists/sites can you recommend to me? fwiw, I prefer mail lists or newsgroups, as I don't have to bother browsing all over the web. snip [P5P][1] has some interesting things on it. I like [Stack Overflow][2]. Other good things are [comp.lang.perl.misc][3] and [Perl Monks][4]. There are numerous other specialty [mailing lists][5]. Another interesting source of information is the [Perl Iron Man Challenge][6] (a [blogging challenge][7] put forth by [mst][8]). [1] : http://www.perlfoundation.org/perl5/index.cgi?perl5_porters [2] : http://stackoverflow.com [3] : http://groups.google.com/group/comp.lang.perl.misc/topics [4] : http://perlmonks.org [5] : http://www.perlfoundation.org/perl5/index.cgi?mailing_lists [6] : http://ironman.enlightenedperl.org/ [7] : http://www.shadowcat.co.uk/blog/matt-s-trout/iron-man/ [8] : http://www.shadowcat.co.uk/blog/matt-s-trout/ -- Chas. Owens wonkden.net The most important skill a programmer can have is the ability to read. -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Coding best practices
Chas. Owens wrote: On Thu, Aug 13, 2009 at 20:25, Steve Bertrandst...@ibctech.ca wrote: snip - is Perl Best Practises what most of you use as general guidelines? IOW, if I continue reading it, will you be able to better understand my code (even though I stick with a few _small_ personal techniques)? From what I've read so far, I'm better understanding many of Uri's past comments a lot better snip PBP is a collection of the folk wisdom at the time of writing. Most things in it are good. Some have not stood the test of time (inside out objects). I haven't got that far in the book yet, but I do feel already that there are things that just won't stick (and I'm not even a programmer). I love Vim, but you should also look at Emacs. You should also throw it away in disgust, but you should at least look at it to know that you are not one-of-those-people. Agreed. I tried it years ago, but with the same effort I tried vi(m) back then...ehrm...none. I'll give it a try, just so I can _silently_ have an opinion on future flame wars. I don't mind whatsoever using meta/ctrl chars, but I do feel already that vi suits my personality/workstyle perfectly. Spacing, like editors, is a religious issue. I am an eight character hard tab programmer for the same reasons Uri mentions. Another benefit of eight character tabs combined with an eighty character line limit is that your indent level servers as a warning that your code is getting too deeply nested. It is religious, and that is not my intention. I'm sure that is well read. Anyone with anything other than constructive comments will be promptly disregarded, I'm sure. I've always done 8-char hard tabs. I've coded for 10 years, off-and-on, mostly quick scripts and some mickey-mouse C++ stuff in Windows. I like 8-char tabs, but I also like how 4-char tabs print onto paper, because I like to read other people's code at home, when I'm just laying on the couch. I don't know what I'll stick with yet. So long as 4 or 8 is _accepted_, I'll figure out how I want mine to be eventually. Perl::Critic is good. Many of its rules come straight from PBP; however, like PBP, it is important to remember that parts of it are just advice. Yes. I toyed with it at all levels. Of course, not having read all of the book yet, many of the 'warnings' tipped me off to things that would be best practise even before reading the book. Things that I kinda-shoulda known better, but didn't. - what other Perl lists/sites can you recommend to me? fwiw, I prefer mail lists or newsgroups, as I don't have to bother browsing all over the web. [P5P][1] has some interesting things on it. I like [Stack Overflow][2]. Other good things are [comp.lang.perl.misc][3] and [Perl Monks][4]. There are numerous other specialty [mailing lists][5]. Another interesting source of information is the [Perl Iron Man Challenge][6] (a [blogging challenge][7] put forth by [mst][8]). [1] : http://www.perlfoundation.org/perl5/index.cgi?perl5_porters [2] : http://stackoverflow.com [3] : http://groups.google.com/group/comp.lang.perl.misc/topics [4] : http://perlmonks.org [5] : http://www.perlfoundation.org/perl5/index.cgi?mailing_lists [6] : http://ironman.enlightenedperl.org/ [7] : http://www.shadowcat.co.uk/blog/matt-s-trout/iron-man/ [8] : http://www.shadowcat.co.uk/blog/matt-s-trout/ Wow, nice! Thanks as always Chas! Steve smime.p7s Description: S/MIME Cryptographic Signature
Re: Coding best practices
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/
Re: Coding best practices
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
Re: Coding best practices
On Fri, Aug 14, 2009 at 00:21, Uri Guttmanu...@stemsystems.com wrote: snip 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). snip I have seen the opposite: too many coders sticking with print instead of picking up a debugger when the situation called for one. I tend to debug with a combination of looking at the code, logs, and print statements, but a good visual debugger can be a godsend. The biggest problem with print statements is that you are modifying the code and you might inadvertently change something or leave a debug statement in the code. -- Chas. Owens wonkden.net The most important skill a programmer can have is the ability to read. -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Coding best practices
CO == Chas Owens chas.ow...@gmail.com writes: CO On Fri, Aug 14, 2009 at 00:21, Uri Guttmanu...@stemsystems.com wrote: CO snip 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). CO snip CO I have seen the opposite: too many coders sticking with print instead CO of picking up a debugger when the situation called for one. I tend to CO debug with a combination of looking at the code, logs, and print CO statements, but a good visual debugger can be a godsend. The biggest CO problem with print statements is that you are modifying the code and CO you might inadvertently change something or leave a debug statement in CO the code. debugging with any technique is a skill to be learned and separate from actual programming. being able to analyze what the code is really doing vs what you expect it to be doing is the real skill. printing and using debuggers are all about getting the raw info for that analysis. as for modifying code or leaving prints around, you just develop handling those as part of the skill set. 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/
Re: Coding best practices
On Friday 14 August 2009 07:21:00 Uri Guttman wrote: SB == Steve Bertrand st...@ibctech.ca writes: 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). My recent impression of most Perl programmers has been the opposite - most of them have been too lazy or unmotivated to learn about the perl -d flag (or similar interactive debuggers), and are always using print's or going on IRC asking What is wrong with this code? I find the perl debugger an indispensable tool and am actively using it. While print's have their rightful place, I still think the perl debugger is too under-used. BTW, you may wish to look at my Devel-LineTrace module as a replacement for print's: http://search.cpan.org/dist/Devel-LineTrace/ It allows one to assign print's and other arbitrary debugging code into arbitrary locations in the code, without having to directly modify it. Thus, one doesn't have to get rid of the print's after one is done with debugging. I wrote by inspiration from some discussion on Perl-Israel (first in a meeting and then on the mailing list). Lately, I've been mostly too lazy to use it and just inserted print's directly, but you may fare better with it. Regards, Shlomi Fish uri -- - Shlomi Fish http://www.shlomifish.org/ God gave us two eyes and ten fingers so we will type five times as much as we read. -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Coding best practices
Chas. Owens wrote: On Fri, Aug 14, 2009 at 00:21, Uri Guttmanu...@stemsystems.com wrote: snip 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). snip I have seen the opposite: too many coders sticking with print instead of picking up a debugger when the situation called for one. I tend to debug with a combination of looking at the code, logs, and print statements, but a good visual debugger can be a godsend. The biggest problem with print statements is that you are modifying the code and you might inadvertently change something or leave a debug statement in the code. ...even though I've (mostly) written 'scripts' (albeit hundreds of them), I've always edited code to throw in a print statement for debugging. Over the years, I've tried to devise cleaner ways to toss them in and disable them on command (global $debug and more recently via dispatch or configuration tables). I do very much like debug tools, especially for getting a better understanding of code that I wrote but in my mind may either be ambiguous or confusing. Hence why I'm trying to learn BCP. Hell, I still don't know how to get around writing an external 'trial test' for each individual piece of code before I write it into a program. Most test files I reuse continuously, and just keep overwriting and renaming (which goes against the number one virtue so I'm told). Many times I get pissed off, and the names show. Each to their own I guess, until they figure it out for themselves. After all, if you are a programmer, you must be a logical thinker. Most likely, you need to learn by your own mistakes, but with influence of others. Hence, I'm sure that many people when they first started out have a list like the following of crappy tests laying around, each starting with the same old: #!/usr/bin/perl use warnings; use strict: I've got literally thousands of test and program files laying around on dozens of servers. For this project, it's been easier, given the fact I've integrated version control, a bit of patience, and a lot of reading. Steve ps. I still have the following style of test programs inside of my project directory (yes, I do plan on evaluating the methods I use to name EVERYTHING, even temporary variables and files ;) http://ipv6canada.com/test.txt smime.p7s Description: S/MIME Cryptographic Signature
