On Thu, 27 Mar 2008, Ben Wheeler wrote:
> Thanks so much for putting the time and effort into fixing up
> all these qDebugs. I had thought about using a mechanical replace
> but feared that it wouldn't work because of the need to also
> drop or alter some of the conversions, ie
> qDebug("%s", foo.latin1());
> should, if I remember correctly, become simply
> qDebug() << foo;
> So it's good to hear that it's worked ok anyway!
Thanks for the kind words! Yeah, some of that script's style
is intentional, and some is laziness (of the non-perl kind :-)
I know the mantra about 'one time tools often become long time
tools' but after this long I can usually tell which are which.
I find coding methodology to be pretty interesting, and have
consciously worked at 'first time success' code for a long time
(with limited success :-)
I have a pretty strict methodology for this sort of task. The
data itself isn't "valuable" in the sense that I can (and did,
for reliability) wipe and check out a new source tree for the
final run.
Program "failures" that truly matter in real programs don't
matter when a program has on user, one use, and the end result
is a bunch of data transformations that are testable.
Overall though, regarding the above limitations, yeah. I made
it catch enough cases that the effort to manually edit the rest
was minor. Balance of effort in the tool vs. actual work.
> use strict;
Yeah, I use -wT and strict; but this is a throwaway script;
bugs matter less here, since my benchmark was strictly the
results of the script, and not program longevity.
> > my (@F)= split (/\%[-\.\d]*[A-Za-z]/, $fmt); # %s
> > %-2d %-4.2e
> > my (@A)= split (/\s*,\s*/, $argstring); # list
> > of args
>
> No need for parens here. I would definitely start these lines:
Ahh... this is different :-) I've worked out over more
years I care to recall style tips that make for repeatable
work-first-time code (at least fragments :-) Rigid var
naming, careful style conventions, and nearly always, strict
disambiguation of parser rules. It's not that I don't/can't know
the compiler's rules; but it often leads to better programmer
(me!) understanding (especially years later) and helps with
debugging and reuse. They also prevent edit iterations when you
tack something to the end of one of those perlisms (function
calls without parens) like ... "if $opt_v;" :-)
> Also, this regex isn't quite adequate to catch all format strings
> > my (@F)= split (/\%[-\.\d]*[A-Za-z]/, $fmt); # %s
> > %-2d %-4.2e
>
> because format strings can look like %02hhd or %#lx ( see printf(3) )
D'oh! missed that!
Yeah this would work "well enough" -- v
my (@F)= split (/\%[-\.\d]+[A-Za-z]/, $fmt);
It's not a real C parser...just a hack :-)
> > if (scalar @A)
> can simply be
> if (@A)
To the compiler, yes; but it reminds me the programmer what I
was intending to do!
> When closing an output file, always check for success:
Yeah, I was just an a**hole for not checking that just out of
habit. But since the next step(s) were svn diff, then vett the
diffs by eye... there's always rm src/*; svn update :-)
> for it, oh dear, you've lost your original file.
>
> > `mv $fn $fn.orig`;
> > `mv $ofn $fn`;
> > } else {
> > `rm $ofn`;
> > }
Fewer keystrokes :-)
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Mixxx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
