|
in reply to Re^3: Generate the perl sequence 1, 11, 111, ....
in thread Generate the perl sequence 1, 11, 111, ....
Do you mind if I offer a critique? There are a few minor points that could be improved.
-
If all that $one_literal can contain is "1", then the variable isn't needed.
If $one_literal can contain something other than "1", then it's misnamed.
-
Speaking of being misnamed, $one_literal doesn't contain a literal. It contains a string. String literals are pieces of source code that get compiled into strings. They don't exist anywhere but in source code.
-
The first argument of printf is a formatting string. Using it to print arbitrary string is a trap waiting to be sprung. Instead, use print or printf('%s', ...).
-
The C syntax for "for" loops (for ( my $i = 1; $i <= $counter; $i++ )) is much more complex than alternative syntax Perl provides (for my $i ( 1..$counter )). That makes it more error-prone and harder to parse mentally (small variations will be obscured).
|
Re^5: Generate the perl sequence 1, 11, 111, ....
by matrixmadhan (Beadle) on Oct 14, 2008 at 09:48 UTC
|
No, I don't mind at all. In fact, I would be glad to correct my mistakes and improve perl coding.
"That makes it more error-prone" - Did you mean the C style for loop syntax. I don't understand why that would be error-prone ? | [reply] |
|
|
I don't understand why that would be error-prone ?
Simply put, the more code you have, the higher the possibility of including an error.
Especially in this case, where there are many symbols packed into a small area and where there are many different common usage of the loop (start at zero, start at one, stop at X, stop before X, etc).
By making it easier to read, it can do nothing but help.
| [reply] |
|
|
By making it easier to read, it can do nothing but help.
Perfect. I agree. Many thanks for that.
| [reply] |
Re^5: Generate the perl sequence 1, 11, 111, ....
by monarch (Priest) on Oct 19, 2008 at 12:09 UTC
|
I would agree with the printf being a trap without a formatting string. However I would disagree that C-style for loops are more error-prone than the double-dot operator. I disagree, however, that c-style loops are harder to understand.
I personally find it much harder to mentally parse the for my $i ( 1 .. $counter ) because it forces me to remember whether the .. operator is a toggle or a list generator, and then I have to wonder if list generation is less efficient than the C-style comparison and increment operators. | [reply]
[d/l]
[select] |
|
|
C-style loops typically involve 3 variables, 3 operators plus "my" and 2 constants.
Perl-style loops typically involve 1 variable, 0 operators plus "my" and 2 constants.
Aside from the studies showing a relation between code length and the chance of there being a bug, aside from my personal experience of C-style loops being one of the biggest source of bugs, I don't see how you can argue that something that has so many more elements to parse is easier to read.
it forces me to remember whether the .. operator is a toggle or a list generator
Well that's simple. The .. operator is always used to generate a list.
| [reply]
[d/l]
[select] |
|
|
