Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commit 88b6fb6

Browse files
Merge pull request #8 from Sadrak/master
Typos & Hints
2 parents 658d402 + 41b7271 commit 88b6fb6

File tree

1 file changed

+6
-6
lines changed

1 file changed

+6
-6
lines changed

‎tutorial/tutorial-english.md‎

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -593,7 +593,7 @@ BEGIN {
593593
diag( "Testing Range::Validator $Range::Validator::VERSION, Perl $], $^X" );
594594

595595
</pre>
596-
This perl program use strict and wanrings (you already know they are friends, do you?) then load the core module <a href="https://perldoc.perl.org/Test/More.html">Test::More</a> which generally
596+
This perl program use strict and warnings (you already know they are friends, do you?) then load the core module <a href="https://perldoc.perl.org/Test/More.html">Test::More</a> which generally
597597
requires that you declare how many tests you intend to run ( <code>plan tests => 1</code> ) then inside the <code>BEGIN</code> block use its method <code>use_ok</code> that loads our own module and in case of failure print "Bail out!\n" aka "everything went wrong, leave the boat".
598598

599599
If the above succeeded <a href="https://perldoc.perl.org/Test/More.html">Test::More</a> calls <code>diag</code> that emits a note with the text specified, useful to have while reviewing test output. The module also has the <code>note</code> method that I prefer. Go to the module documentation to have an idea of <a href="https://perldoc.perl.org/Test/More.html">Test::More</a>
@@ -768,9 +768,9 @@ sub validate{
768768
}
769769

770770
</pre>
771-
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+
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.
772772

773-
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.
773+
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.
774774

775775
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.
776776

@@ -1823,7 +1823,7 @@ B - Yeah man, for a coffee, as always.
18231823

18241824
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.
18251825

1826-
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:
1826+
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:
18271827

18281828
<pre>
18291829
# assume we have a string if we receive only one argument
@@ -2047,7 +2047,7 @@ Push recent changes into the online repository.
20472047
<a id="daysevenstep4"></a>
20482048
<h4>step 4) another kind of test: POD and POD coverage</h4>
20492049

2050-
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:
2050+
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>):
20512051

20522052
<pre>
20532053
shell> prove -l -v ./t/pod.t
@@ -2140,7 +2140,7 @@ Just an example: install <a href="https://metacpan.org/pod/Module::CPANTS::Analy
21402140
<a id="dayeightoptionone"></a>
21412141
<h4>option one - the bare bone module</h4>
21422142

2143-
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.
2143+
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.
21442144

21452145
Nothing bad if the above behaviour is all you need.
21462146

0 commit comments

Comments
(0)

AltStyle によって変換されたページ (->オリジナル) /