|
Re^5: Newline's creep in, while using Tie::File
by tobyink (Canon) on Nov 17, 2020 at 13:00 UTC
|
The times when it's sometimes useful to not have strictures:
- Perl one-liners. That is perl -e'...'. If your code is literally one line, then the rigour that strictures enforce is unlikely to benefit you much and will just force you to type more.
- When you want to use symbolic references. But in these cases, you can just do no strict 'refs'; in a small scope, like a do {...} block.
Other than that, use strict everywhere. use warnings is often useful too, but use strict is vital.
| [reply]
[d/l]
[select] |
Re^5: Newline's creep in, while using Tie::File
by marto (Cardinal) on Nov 17, 2020 at 11:38 UTC
|
| [reply] |
|
|
Looking at Modern::Perl I am beginning to see how much I don't know!
I thought I was a reasonably competent Perl programmer having written a lot of functional code including a small amount of OO Perl - but just 3 days here is giving me other ideas.
| [reply] |
|
|
From the first link...
"Initially using strict is a pain."
That explains exactly why, until now, I have not used it...
note that I said "until now". The power of persuasion has worked :P
| [reply] |
Re^5: Newline's creep in, while using Tie::File
by GrandFather (Saint) on Nov 17, 2020 at 11:26 UTC
|
Judging by replies here it is a majority belief that strictures should always be used.
For things like variable name typos or scoping issues use strict; can save bulk time and very red faces. The cost of including strictures (two lines of boiler plate code) is trivial compared to the time and cost they can save. Can you honestly say you've never fat fingered a variable name or misremembered what you called a variable?
Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond
| [reply]
[d/l] |
|
|
Not to mention if you use your editor right it literally is boiler plate; I use yasnippet but even other (*cough* inferior :) editors have similar functionality. When I open a new file and get a buffer in cperl-mode all I have to type is "script" then TAB and I get a script ready to go with my cursor sitting at where the $0 marker is (the header before the comment with -- being removed of course, and depending on the use of a version greater than 5.10 to turn strict on).
# -*- snippet -*-
#name : perl script
# --
#!/usr/bin/env perl
use 5.032;
$0
exit 0;
__END__
The cake is a lie.
The cake is a lie.
The cake is a lie.
| [reply]
[d/l]
[select] |
|
|
Can you honestly say you've never fat fingered a variable name or misremembered what you called a variable?
Of course not...that's a normal part of coding isn't it regardless of the technology.
The reason I have never added use strict; is not because of any ideological view. It is because when I learnt to use Perl in the early 1990's I did so out of necessity and by looking at a very limited pool of other people's code which either didn't include strictures or, if it did I didn't notice and found my code worked without it. Back then I didn't have internet access at home so couldn't look things up to learn best practice.
I have experimented with turning on use strict; and got frustrated at having to declare variables before use so ended up not bothering. It sort of slowed down the initial code development although, granted, it may well have speeded things up down the line had I persevered.
The reason I ask is because I have many, many lines of working Perl code in production and I know it would be beneficial for me to up my coding game. Not least because coding is not core to my business and it would make sense for me to employ a developer soon(ish). Improving how I code going forward and improving existing code will have to be part of that process.
| [reply]
[d/l]
[select] |
|
|
when I learnt to use Perl in the early 1990's I did so out of necessity and by looking at a very limited pool of other people's code which either didn't include strictures or, if it did I didn't notice
That will be because it didn't exist in the language back then. I think it was around 5.002 when it was introduced.
I have experimented with turning on use strict; and got frustrated at having to declare variables before use so ended up not bothering. It sort of slowed down the initial code development although, granted, it may well have speeded things up down the line had I persevered.
I don't see why it would slow down initial code development at all. Could you explain more?
FWIW, here is one of my recent nodes showing the benefit. And another one.
| [reply]
[d/l] |
|
|
|
|
|
|
|
"It sort of slowed down the initial code development"
How much time did you save by not typing my, and how much time has been spent finding problems caused by a typo in a variable name?
| [reply]
[d/l] |
|
|
|
|
|
|
I have experimented with turning on use strict; and got frustrated at having to declare variables before use so ended up not bothering. It sort of slowed down the initial code development although, granted, it may well have speeded things up down the line had I persevered.
I used to feel the same way. It's true that not having to
think about variable scope or initialization seems easier
and faster at first, but those gains have costs like
difficulty of debugging and the constant danger of
undetected typos. Strict will help you think more about
why your variables exist and what constitutes sane defaults.
You will find yourself creating less variables and knowing
more about how your program works. The default values of
your variables then become very useful in determining the
flow of your code. Trust the monks, strict is your friend!
| [reply] |
|
|
|
|
A lot of example code (e.g. CPAN module's doc), for the sake of being brief avoid the use of strict.
But even if the example code does not have use strict; and does not declare variables (e.g. my $xyz;), you should. Regarding the few exceptions where strict should **locally** be disabled because you want to do some hackery, then by all means zap the bastard as if it was a star-wars rogue (barhards? plenials? prole-lians? obviously not acquainted with the subject).
| [reply]
[d/l]
[select] |
