|
home—lects—hws
D2L—breeze (snow day)
Due 2016.Sep.19 (Mon) 11:00 Submit on D2L, and a bring hardcopy of your three files utils.php, utils-test.php, and silly-page.php. The files should also be viewable on the web, as discussed below.
For this homework, create a directory ~/dynamic_php/itec325/hw02.
This time, silly-page.php should be mostly not enclosed in
(5pts) A function
We'll use this to make our testing more convenient.
For example, your
Two other requirements, to make this function even more useful:
Note that this is just a regular ol’ function that takes in strings and returns strings!
The fact that the strings happen to have angle-brackets in them means that the result might
be useful to people generating html, but the function itself does't really care.
(You don't need to come up with additional test cases, but you do need to actually include these tests or their equivalent. You can assume that neither string is ever empty.)
Note how the input strings don't contain any quote-characters, but the returned result does (since HTML attributes must be quoted). I recommend that your generated html uses single quote marks around attributes, but you'll get full credit for either single- or double-quote marks, as long as it is valid HTML. Make sure your test case(s) express exactly what you want the desired output should be!
Make the above into a runnable
test-case for
You don't need further test-cases for this problem.
Pay close attention to the exact spacing you want to have.
As discussed in class,
I recommend using single-quotes (
For full credit, your function should call
For example,
given an array with
For full credit, this function should involve a call to
Notes:
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.)
1Why not collapse whitespace to nothing at
all?
This is tempting, since an actual&desired output of
2When having a list of more than 2 items, I personally recommend using the Oxford comma (or, see wikipedia) but I will leave it to your preference. ↩
3 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. } |
home—lects—hws
D2L—breeze (snow day)
©2016, Ian Barland, Radford University Last modified 2016.Oct.12 (Wed) |
Please mail any suggestions (incl. typos, broken links) to ibarlandradford.edu |