CGI/Perl Guide | Learning Center | Forums | Advertise | Login
Site Search: in

  Main Index MAIN
INDEX
Search Posts SEARCH
POSTS
Who's Online WHO'S
ONLINE
Log in LOG
IN

Home: Perl Programming Help: Beginner:
subroutine

 



ashish_chand
Novice

Apr 23, 2013, 5:46 AM

Post #1 of 8 (683 views)
subroutine Can't Post

   

please what the below subroutine is doing ?

here %opt is a hash that is used to hold the options.

# usage: debug REF
# debug <message>
sub debug {
if ( $opt{'debug'} ) {
if ( ref($_[0]) eq 'HASH' ) {
foreach my $k (keys %{$_[0]}) {
my $v;
if ( defined $_[0]->{$k} ) { $v = $_[0]->{$k} ; }
else { $v = "" ; }
printf(STDERR "DEBUG: %-20s = %s\n",$k,$v)
}
} else {
print STDERR "DEBUG: " . join(" ",@_) . "\n";
}
}
}


FishMonger
Veteran / Moderator

Apr 23, 2013, 6:38 AM

Post #2 of 8 (678 views)
Re: [ashish_chand] subroutine [In reply to] Can't Post

The sub prints a debug statement.

I see that you've had several similar posts. Lets take a different approach on this one so we all (including yourself) can see how much you've learned.

Please explain to us what you think each line is doing and we'll either confirm that you're correct, or we'll explain where you went wrong.


g4143
Novice

Apr 23, 2013, 6:44 AM

Post #3 of 8 (675 views)
Re: [ashish_chand] subroutine [In reply to] Can't Post

I should think that this would be a big clue


Code
# usage: debug REF 
# debug <message>



BillKSmith
Veteran

Apr 23, 2013, 11:57 AM

Post #4 of 8 (663 views)
Re: [ashish_chand] subroutine [In reply to] Can't Post

I think that you will find this version of your subroutine to be equivalent to yours, but easier to understand. Simplification is achieved by allowing early return (a violation of structured programming), by using the each function to simplify the hash reference, and by exploiting the new defined-or operatior (Introduced in perl version 5.10.0) to supply a default message.

I have provided an example of each type of usage.

Code
use strict; 
use warnings;
use v5.10.0;
my %opt = (debug => 1, VERBOSE => undef);
debug( \%opt );
debug( q(That's all folks) );

sub debug{
*STDERR = *STDOUT;
# usage:
# debug( REF );
# debug( <message> );
return if !$opt{debug};
if ( ref($_[0]) eq 'HASH' ) {
while (my ($k, $v) = each %{$_[0]}) {
$v //= q('');
printf(STDERR "DEBUG: %-20s = %s\n",$k,$v)
}
return;
}
# Assume message(s).
print STDERR "DEBUG: " . join(" ",@_) . "\n";
return;
}


OUTPUT:

Code
DEBUG: VERBOSE              = '' 
DEBUG: debug = 1
DEBUG: That's all folks

Good Luck,
Bill


Laurent_R
Veteran / Moderator

Apr 23, 2013, 3:57 PM

Post #5 of 8 (656 views)
Re: [BillKSmith] subroutine [In reply to] Can't Post


In Reply To
Simplification is achieved by allowing early return (a violation of structured programming)


I may be off-topic, but I strongly object to the idea that early return is a violation of structured programming.

Wink

Yes, Niklaus Wirth, a great computer scientist and one of the fiercest proponents of structured programming, refused to include early returns from Pascal and other languages that he designed (including, I think, Modula and Oberon).

But I think he was wrong on that (I know, who am I to claim that?), and that actually might partly explain why none of the languages he developped on that mindset really succeeded in real life programming (OK, Algol may be an exception, but it still did not last very long). Nothing compared to the longevity of Lisp, C, C++, Java or... Perl.

As far as I know, Dijkstra, another great computer scientist heavily involved in the same debate and the famous author of the "Goto considered harmful" article (although that somewhat provocative title has apparently been chosen by Wirth) never objected to early return. And Donald Knuth also made a case against gotos that go backwards, but not against early returns.

I also (thing to) remember having read an article by Larry Wall (I think it was him, I hope I am not wrong), explaining that an software program can quite often be considered as a decision tree and that an early return is a natural thing to do when some conditions are met. Getting rid of the special cases early usually makes programs much easier to understand than straightjacket-type of deeply nested if/then/else constructs.

In brief, I am totally on the side of structured programming, but I think that early returns (or early exits) often simplify considerably the logic of programs. And I never use gotos (except in a specific proprietary language that I am using and in which it is just the only way of making an early return), but, in Perl, I use very often the last and next instructions (which are nothing but early returns constructs).


BillKSmith
Veteran

Apr 25, 2013, 7:11 AM

Post #6 of 8 (633 views)
Re: [Laurent_R] subroutine [In reply to] Can't Post

Laruent,

There does not seem to be any standard definition of "Structured Programming." There is a "Structured Program Theorem" which holds that any algorithm can be implemented using only three simple control structures. Few, if any, programmers ever argued that this was a desirable way to implement all algorithms. The original code in this thread is an excellent example of how blind adherence to the theorem can obscure the intent of the algorithm.

I believe that software should be written for people to read. The theorem is a good starting point. Take any exception that helps the reader. Even the much maligned goto occasionally has its place (usually to separate error processing from the main algorithm).

You may have been "off-topic", but your point certainly deserves to be seen in this forum.
Good Luck,
Bill


FishMonger
Veteran / Moderator

Apr 25, 2013, 8:07 AM

Post #7 of 8 (627 views)
Re: [BillKSmith] subroutine [In reply to] Can't Post

Bill,

Why are you doing this?

Code
*STDERR = *STDOUT;


To me, it makes no logical sense to do that in this case.


BillKSmith
Veteran

Apr 25, 2013, 1:59 PM

Post #8 of 8 (618 views)
Re: [FishMonger] subroutine [In reply to] Can't Post

I added this line of temporary code to help capture the output. Forgot to remove it.Blush
Good Luck,
Bill

 
 


Search for (options) Powered by Gossamer Forum v.1.2.0

Web Applications & Managed Hosting Powered by Gossamer Threads
Visit our Mailing List Archives