|
Re^4: Newline's creep in, while using Tie::File
by Bod (Parson) on Nov 17, 2020 at 11:15 UTC
|
I'm probably asking the wrong person...but...is it a universal belief that strictures should be on or a majority belief? Is there an argument for leaving them off?
I have never used them although I would not argue that my code could be held up as best practice or even good practice - other than it does everything it was designed to do and performs non-trivial tasks. On that basis, it works as well as can be expected. I am aware of some of the problems they eliminate and code so these issues do not arise.
| [reply] |
|
|
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] |
|
|
| [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] |
|
|
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] |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
