You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: source/tutorial-english.html
+4-4Lines changed: 4 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -769,7 +769,7 @@ <h4>step 1) first lines of code</h4>
769
769
</pre>
770
770
The above is straightforward (if ugly): we get something in via <code>@_</code> (a string or a list) and we return something via <code>return @range</code> To accomplish this we initialize <code>$range</code> to hold our string.
771
771
772
-
A good principle in loops is "put exit conditions early" and following this principle we put our our die conditions as soon as possible, ie after the if/else check.
772
+
A good principle in loops is "put exit conditions early" and following this principle we put our die conditions as soon as possible, ie after the if/else check.
773
773
774
774
But we dont want to die with an ugly message like <code>Died at ../Range/Validator.pm line x</code> ie from the module perspective: we want to inform the user where his code provoked our module to die.
775
775
@@ -1822,7 +1822,7 @@ <h4>step 2) adding a Carp to the lake</h4>
1822
1822
1823
1823
So we add a line in the top of the module, just after VERSION: <code>our $WARNINGS = 0;</code> to let dev B to trigger our warnings. We commit even this small change.
1824
1824
1825
-
Then we add to the sub a <code>carp</code> call triggered if <code>our $WARNINGS == 1;</code> and if <code>@_ == 0</code> and we add this as <code>elsif</code> condition:
1825
+
Then we add to the sub a <code>carp</code> call triggered if <code>$WARNINGS == 1</code> and if <code>@_ == 0</code> and we add this as <code>elsif</code> condition:
1826
1826
1827
1827
<pre>
1828
1828
# assume we have a string if we receive only one argument
@@ -2046,7 +2046,7 @@ <h4>step 3) another kind of test: MANIFEST</h4>
2046
2046
<aid="daysevenstep4"></a>
2047
2047
<h4>step 4) another kind of test: POD and POD coverage</h4>
2048
2048
2049
-
In our <code>/t</code> folder we still have two tests we did not run: shame! <code>module-starter</code> created for us <code>pod.t</code> and <code>pod-coverage.t</code> The first one checks every POD in our distribution has no errors and the second ensures that all relevant files in your distribution are appropriately documented in POD documentation. Thanks for this. Run them:
2049
+
In our <code>/t</code> folder we still have two tests we did not run: shame! <code>module-starter</code> created for us <code>pod.t</code> and <code>pod-coverage.t</code> The first one checks every POD in our distribution has no errors and the second ensures that all relevant files in your distribution are appropriately documented in POD documentation. Thanks for this. Run them (after installing the necessary modules <code>Test::Pod</code> and <code>Test::Pod::Coverage</code>):
2050
2050
2051
2051
<pre>
2052
2052
shell> prove -l -v ./t/pod.t
@@ -2138,7 +2138,7 @@ <h2>day eight: other module techniques</h2>
2138
2138
<aid="dayeightoptionone"></a>
2139
2139
<h4>option one - the bare bone module</h4>
2140
2140
2141
-
This is option we choosed for the above example and, even if it is the less favorable one, we used this form for the extreme easy. The module is just a container of subs and all subs are available in the program tha uses our module but only using their fully qualified name, ie including the name space where they are defined: <code>Range::Validator::validate</code> was the syntax we used all over the tutorial.
2141
+
This is option we choosed for the above example and, even if it is the less favorable one, we used this form for the extreme easy. The module is just a container of subs and all subs are available in the program that uses our module but only using their fully qualified name, ie including the name space where they are defined: <code>Range::Validator::validate</code> was the syntax we used all over the tutorial.
2142
2142
2143
2143
Nothing bad if the above behaviour is all you need.
0 commit comments