home—lects—hws
D2L—breeze (snow day)
hw01
hw01: A first php program
Due 2015.Feb.02 (Mon) 10:59.
For this homework, you'll submit three files, both on D2L and as hardcopy:
- 10pts: utils.php, which contains only code for pluralize (see below).
- 10pts: utils-test.php, which contains test cases for pluralize
(as runnable code).
It will require-once your utils.php.
- 5pts: silly-page.php, which (when run) just prints out (what happens to be) valid html for
a web page that, if redirected to a file and opened in in a browser,
would render something like sample-output.html.
As in Wednesday's
lecture
and its example “some-web-page.php”,
silly-page.php should start with “<?php”,
and end with the matching “?>”,
and primarily contain echo statements1.
It will have a couple of calls to pluralize
(and, it will require utils.php).
Notes:
-
For all assignments in this class (and for all your classes)
your primary file (utils.php in this case)
must start with a comment containing:
Your name; the class/semester; the URL of this assignment page.
-
Every function should be commented with a short (1-sentence) description,
(which mentions every each by name),
and should indicate the types of the parameters and the return-type.
You do not need to check for invalid-inputs to your functions.
E.g.:
if I ask for a function taking in (say) a number and a string,
and you repeat in your function-comment that your function handles a number and a string,
then you don't need to check for being given incorrect inputs —
that's the caller's problem, not yours.
Similarly for more refined types like "non-empty-string" or "integer in the range [1,12]":
if it's in the comments as a pre-condition, that'll suffice.2
(We'll talk about validating input received from the (external, untrusted) user later.)
-
Any HTML/XML for this class should follow the following common guidelines:
-
Every tag must be closed.
(Empty-tag notation is fine, but no dangling <p> open-tags.)
-
Every attribute must have a value, and it must be quoted.
-
Tags are case-sensitive.
-
Indent clearly, as for any programming class (or your non-programming classes for that matter).
We'll require these even where it's not strictly needed for (mere) HTML5 compliance.
-
For this assignment, we are not making any web pages!
(The third file prints out a string which happens to be html,
but it's just a string,
and we won't be accessing that file via the web.)
-
Write a php function string pluralize( int $num, string $noun )
which returns a user-friendly version of a number+noun:
pluralize( 7, "t-shirt" ) === "7 t-shirts".
We'll use this function on future web-pages, when (say) confirming somebody's order.
-
Be sure to include at least three test cases, each covering a different situation.
(The noun will never be the empty string, so you don't even need to check for that.
But what other corner-cases should you handle?
Many students lose points by not thinking through test cases closely enough,
and then not having code that covers such corner cases.)
-
You'll get full credit for (only) handling nouns whose plural is formed by adding “s”.
-
You don't need to include test cases for nouns whose plural isn't formed by adding
“s”;
that is, we're not really making a comprehensive set of test cases for this function!
If you want to include a test case like
pluralize(4,"goose"), note that the expected-result really is
"4 geese" — and you can still get full credit w/o passing this test.
(Do not, however, have a test-case claiming that the expected answer is
"4 gooses: it's cheating to re-define your answer to be whatever your code
gives, and then claim that your code is working!
Admittedly, a better term than “expected output” would be
“correct output”.)
-
As also mentioned in standard instructions for all homeworks:
You do not need to check for being given a non-number for the
first argument (or, a non-string for the second);
that's what a type system would check/guarantee
(and in a big project, you might add type-annotations and run-time type-checking,
if you valued a consistent approach to correctness).
1
You may have seen in Web I that text not enclosed
in <?php … ?>
is a short-cut for printing; we'll use that on following assignments,
but for this this assignment use explicit echo (or, print)
statements.
↩
2
While the defensive-programming can be helpful in bigger projects
(esp. in untyped languages like php), it's never interesting code.
If you DO want to do the checks anyway, that's fine, but do all the type-validation
right away (before you enter the 'real' function-logic),
and throw an error if something goes wrong
(don't continue and return some sort of odd, undocumented answer).
For example:
function foo( $someNum ) {
// optional error-check:
if !(is_numeric($someNum)) { throw new InvalidArgumentException( 'foo: expected number, given ' . $someNum ); }
// ...now put your real code, uncluttered by further type-checks.
}
|
(Ideally, you'd include the type-requirements in comments, and then a tool would automatically generate the above boilerplate error-checking for you. That's what Java's type-system gives you, for example.)
↩
home—lects—hws
D2L—breeze (snow day)
radford.edu