ITEC325 hw01 -- hw01: A first php program

hw01
hw01: A first php program

Due: 2016.Sep.09 (Fri) 11:00
On Wednesday, we will discuss having test-cases in a different file than your function.

For this homework, you'll submit three files, both on D2L and as hardcopy:

10pts: utils-test.php, which contains test cases for pluralize (as runnable code). It will require-once your utils.php (see next item).

10pts: utils.php, which contains only code for function pluralize.

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 hw01-sample-output.html. It should have a couple of calls to pluralize (and, it will also require_once utils.php).

As in lecture and its example “some-web-page.php”, silly-page.php should start with “<?php”, and end with the matching “?>”, and primarily contain echo statements .

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 each parameter by name), and should indicate the types of the parameters, and the function's 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.

(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( number $num, string $noun ) which returns a user-friendly version of a number+noun: pluralize( 7, "t-shirt" ) === "7 t-shirts". One might this function on future web-pages, when (say) confirming somebody's order, or perhaps listing an RPG player's inventory.

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).

¹ 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 statements. ↩

² 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 ) {
  // error-check NOT required for this class, but if you want to:
  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. ↩

Please mail any suggestions
(incl. typos, broken links)
to ibarlandradford.edu

hw01 hw01: A first php program

hw01
hw01: A first php program