The sprintf documentation contains details of the formats;
these are not shown in the printf documentation.
So, as it was the sprintf formatting that I was explaining, it seemed appropriate to use sprintf in my example code.
More importantly though, I made a conscious decision to not use printf in my examples. That function has a number of gotchas which aren't specifically related to the actual formatting and which I didn't want to have to explain.
The printf documentation is short: just three paragraphs.
The first gotcha, noted in the very first sentence, has tripped you up!
Here's what happens if I substitute my 'print sprintf' with your ("Why not simply") 'printf':
$ perl -Mstrict -Mwarnings -le '
my $x = 9**-10;
print "$x";
printf "%f" => $x;
printf "%.15f" => $x;
printf "%.31f" => $x;
printf "%g" => $x;
printf "%.15g" => $x;
printf "%.31g" => $x;
'
2.86797199079244e-10
0.0000000.0000000002867970.00000000028679719907924413493062.86797e-102
+.86797199079244e-102.86797199079244134930566254989e-10$
I'll also draw your attention to the last printf paragraph:
"Don't fall into the trap of using a printf when a simple print would do. The print is more efficient and less error prone."
Finally, I use "=>" insted of "," for clarity; particularly when separating different types of arguments. If you look at my posts, you'll find many examples of this kind of thing:
sprintf FORMAT => LIST
split PATTERN => STRING
join STRING => LIST
pack TEMPLATE => LIST
I find it makes the code easier to read and, when necessary, easier to debug.
There's a clear delineation between the first argument, which affects how the function operates, and the remaining arguments, which specify what the function operates on.
|