R. Joseph Newton wrote:
>
> > > There are many references , what line number does it say
> > > is evil and which line below is that?
> >
> > Thanks for your help, I have put a -----right here ----- in the code...
> >
> > }
> > $SQL .= "\n";
> > }
> > #---------right here------
> > }
> > $SQL .= ");\n\n";
> > return $SQL;
>
> Given that your error message indicates a problem with a hash ref, and that
> the compiler stopped at the end of a loop, I'd say the problem has something
> to do with mismatched braces. Unfortunately, your code is way too thick to
> be worth crawling through without context.
>
> Lets look at some of the factors that make this difficult to debug:
>
> This:
>
> my @options = @{ $hash{options} };
> while ($_ = shift (@options)) {
> if ($_ =~ m/not null/i) {
> $SQL .= "NOT NULL ";
> }
> ...
> else {
> $debugger->error("Option: $_ is not known.
> Assuming it's database specific and ignoring.");
> }
> }
> $SQL .= "\n";
> }
>
> should be afunction of its own, with clearly named parameters. So should
> this:
>
> $SQL .= "CREATE TABLE $table_name\n";
> $SQL .= "(\n";
> while (my %hash = %{ shift (@columns) }) {
> $SQL .= " $hash{name} ";
> if ($hash{type} =~ m/INT/i) {
> }
> #---------right here------
> }
> $SQL .= ");\n\n";
> return $SQL;
>
> the enclosing block, although I can't say for sure that I picked the right
> ending brace for the start. That uncertainty is the whole point. There are
> many challenges in programming that are more worthy of your efforts than
> tracking braces. One of them is organizing functionality.
>
> while ($_ = shift (@temp)) {
> my $temp3 = {
> name => $_,
>
> So you are naming some that is temporary, huh? Gee, uh, well, that's nice
> to know. It would be even nicer to know what this temporary thing
> represents. Choose your variable names with more care.
>
> Programming should be about something. The identifiers you use should tell
> you what the code is about.
I agree with you completely Joseph, but I'd be grateful for just
proper indentation and whitespace. It's impossible to write code
layed out like this without some trial-and-error placement of
block terminators. I started to lay out the code to find the bug
but gave up after about five minutes.
In the absence of any specific guidelines you should aim for
what is layed out in
perldoc perlstyle
People will forgive even major deviations form this standard,
but the above code may as well be written on a single line.
Perhaps there should be a 'Darwin Awards' for programming style?
Cheers,
Rob
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
