Re^4: Backdating strict

Replies are listed 'Best First'.
Re^5: Backdating strict by GrandFather (Saint) on Nov 18, 2020 at 22:22 UTC
Though I don't share his confidence that code which evolved without strict can be easily fixed with these tools Um, I don't think I expressed that confidence. I did say: With modern editors that perform background syntax checking it's pretty quick to identify where variables need to be declared and fix that. which as BillKSmith points out may be the thin edge of the wedge, as indeed you also imply. However, identifying issues is a huge head start in resolving them! Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond	[reply]
Re^5: Backdating strict by Fletch (Bishop) on Nov 18, 2020 at 22:01 UTC
Quibble: flycheck >>> flymake. It comes more or less out of the box with both `perl -c` and Perl::Critic support. The cake is a lie. The cake is a lie. The cake is a lie.	[reply] [d/l]
Re^6: Backdating strict by LanX (Saint) on Nov 18, 2020 at 22:42 UTC
I was thinking of mentioning flycheck, because it's indeed far more elaborate. But last time I tried it under Windows it used to slow down and make emacs often pause. (IIRC did the maintainer say that Win is not his concern) Sorry, but I made it a habit to only recommend OS agnostic solutions. flymake dates back to the antiques of emacs, that's why it's stable. Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery}	[reply]
Re^5: Backdating strict by jcb (Parson) on Nov 19, 2020 at 00:21 UTC
The syntax highlighting in Emacs' `cperl-mode` is extensive and tends to catch most of my syntax errors when I notice that the code did not highlight as expected. This is particularly useful for catching sigil and subscript typos — CPerl mode highlights direct array and hash lookups accordingly, so if I miss the shift key and type `$foo[bar]` instead of `$foo{bar}`, the syntax highlighting will indicate my mistake almost instantly.	[reply] [d/l] [select]
Re^6: Backdating strict by LanX (Saint) on Nov 19, 2020 at 00:28 UTC
I just wanted to return to the topic on how an IDE can help refactoring to strict. I agree that cperl's syntax highlighting is among the best. But it can't help catching typos in variable-names or scoping problems. That's where flymake et al. comes very handy. Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery}	[reply]
Re^7: Backdating strict by jcb (Parson) on Nov 19, 2020 at 00:41 UTC
I have never refactored code to `use strict;` because all of my code has been written under `strict` (command-line one-liners excepted), but when I have had typos in variable names, I have always had great success by simply running the script at a terminal and letting perl point out the errors. Since this is presumably functioning code, we can expect that there will be no variable-name typos. The simplest option for moving to `strict` would be to add `use strict;` and then `use vars` at top-level, listing the variables already used until all are declared. Narrowing the scopes to lexicals can then be done incrementally, using grep or Emacs' M-x `occur` to identify where each name is mentioned in the code and understanding of the program to determine where values can be reduced to narrower scopes.	[reply] [d/l] [select]
Re^8: Backdating strict by LanX (Saint) on Nov 19, 2020 at 00:48 UTC
Re^9: Backdating strict by jcb (Parson) on Nov 19, 2020 at 02:09 UTC
Some notes below your chosen depth have not been shown here
Re^5: Backdating strict by Bod (Parson) on Dec 06, 2020 at 21:48 UTC
I know that Komodo offers it too I have downloaded and installed Komodo and it certainly looks impressive. I think I need quite a while to find my way around and start using it to produce something but I shall certainly give it a good try... I did think of Padre but that doesn't seem to be being developed or supported anymore.	[reply]