Description
Specification 36
Your program is to play the Wordle game via terminal interaction. Your program will call the supplied library 37
function get_random_word() (outlined on page 6) to determine a random word of the desired length that is 38
unknown to the user (the answer). Your program will then repeatedly prompt the user to guess the answer 39
until they get it right or they run out of attempts. For incorrect guesses, if the guess is valid (i.e. is the right 40
length and appears in the nominated dictionary) then your program will then report on which letters matched 41
those in the answer (if any) – i.e. which letters were in the right place, which were in the wrong place, and 42
which weren’t in the answer at all. Invalid guesses don’t count as an attempt – the user will be prompted to 43
enter another guess. 44
Full details of the required behaviour are provided below. 45
Command Line Arguments 46
Your program (wordle) is to accept command line arguments as follows: 47
./wordle [-len word-length ] [-max max-guesses ] [dictionary ] 48
In other words, your program should accept 0 to 5 arguments after the program name: zero, one or two 49
option arguments (-len and/or -max, in either order if both present) each followed by an integer (in the range 50
of 3 to 9 inclusive), with the option argument(s) optionally followed by a dictionary file name 1
. 51
Some examples of how the program might be run include the following2
: 52
./wordle 53
./wordle -len 6 54
./wordle -max 7 55
./wordle ./my-dictionary 56
./wordle -len 6 /usr/share/dict/words 57
./wordle -max 7 -len 6 58
The meaning of the arguments is as follows: 59
• -len – if specified, this option argument should be followed by an integer between 3 and 9 inclusive that 60
indicates the length of the word to be used in game play. If the argument is not specified, a default word 61
length of 5 shall be used. 62
• -max – if specified, this option argument should be followed by an integer between 3 and 9 inclusive that 63
indicates the maximum number of guesses that will be permitted in game play. If the argument is not 64
specified, a default value of 6 shall be used. 65
• dictionary – the last argument (if present) is the path name of the dictionary file, i.e. the name of a file 66
containing words – one per line. Each line (including the last) is assumed to be terminated by a newline 67
character (\n) only. You may assume there are no blank lines and that no words are longer than 50 68
characters, although there may be words that contain characters other than letters, e.g. “1st” or “don’t” 69
The filename can be relative to the current directory or absolute (i.e. begin with a /). Some examples 70
are: 71
/usr/share/dict/words 72
../dictname.txt 73
5 (refers to a file with this name in the current directory). 74
If a filename is not specified, the default should be used (/usr/share/dict/words). 75
1The square brackets ([]) indicate optional arguments. The italics indicate placeholders for user-supplied arguments.
2This is not an exhaustive list and does not show all possible combinations of arguments.
2 Version 1.1
Prior to playing the game (or even checking the dictionary file exists) your program must check the command 76
line arguments for validity. If the program receives an invalid command line then it must print the message: 77
Usage: wordle [-len word-length] [-max max-guesses] [dictionary] 78
to standard error (with a following newline), and exit with an exit status of 1. 79
Invalid command lines include (but may not be limited to) any of the following: 80
• An argument begins with the character ‘-’ but it is not -len nor -max. 81
• The -len argument is given but it is not followed by a positive integer between 3 and 9 inclusive. 82
• The -max argument is given but it is not followed by a positive integer between 3 and 9 inclusive. 83
• Either the -len or -max argument is given twice. 84
• Any argument is the empty string. 85
Note that it is valid for a dictionary name to begin with ‘-’ but it is not valid for the dictionary name argument 86
to begin wtih ‘-’. The dictionary name argument can be prefixed with ./ if necessary, e.g., a dictionary file 87
named -len can be passed as an argument by writing ./-len. 88
Dictionary File Name Checking 89
If the given dictionary filename does not exist or can not be opened for reading, your program should print the 90
message: 91
wordle: dictionary file “filename ” cannot be opened 92
to standard error (with a following newline), and exit with an exit status of 2. (The italicised filename is 93
replaced by the actual filename i.e. the full argument given on the command line. The double quotes must be 94
present.) This check happens after the command line arguments are known to be valid. 95
Game Play 96
If the checks above are successful, then your program should print the following to standard output (with a 97
following newline): 98
Welcome to Wordle! 99
Your program should then determine a random word (the “answer”) by calling get_random_word() – see details 100
of this provided library function on page 6. 101
Your program should then repeatedly prompt the user for a guess by printing the following message to 102
standard output (with a following newline): 103
Enter a N letter word (M attempts remaining): 104
where N is replaced by the word length for this game (e.g. 5) and M is replaced by the number of attempts 105
remaining (e.g. initially 6 by default, or whatever value is specified with -max). When there is only one attempt 106
remaining, the program should instead print: 107
Enter a N letter word (last attempt): 108
Guesses are entered on stdin and are terminated by a newline (or pending EOF). If the user enters a guess 109
that is not the correct length then your program should print the following to standard output (with a following 110
newline), followed by another prompt: 111
Words must be N letters long – try again. 112
N is replaced by the expected word length. (Note that the attempt number will not be incremented when the 113
prompt is printed – only valid attempts are to be counted.) 114
If the user enters a guess of the correct length that contains characters other than the letters A to Z (upper 115
case or lowercase), e.g. the guess contains numbers or spaces or punctuation characters, then your program 116
should print the following to standard output (with a following newline), followed by another prompt: 117
Words must contain only letters – try again. 118
If the user enters a guess that is the right length and contains only letters and matches the answer then 119
your program should print the following to standard output (with a following newline) and then exit with exit 120
status 0 (success): 121
Correct! 122
Matching must be done on a case insensitive basis, e.g. the guess HelLo will match the word hello. 123
If the user enters a guess that is the correct length and contains only letters but it is not the answer and the 124
guess cannot be found in the dictionary file then your program should print the following to standard output 125
(with a following newline), followed by another prompt: 126
3 Version 1.1
Word not found in the dictionary – try again. 127
Matching against words in the dictionary file must also be done on a case insensitive basis. 128
A guess that is the correct length, contains only letters, is not the answer, and is found in the dictionary is 129
considered a valid attempt. When a user enters a guess that is considered a valid attempt, then your program 130
will echo that word back to the user with the characters modified in the following way: 131
• If the letter in that position isn’t found anywhere in the answer, then the ‘-’ (hyphen) character is printed. 132
• If the letter in that position is found in that position in the answer, then the letter is printed in uppercase. 133
(The is the same as a green letter in Wordle.) 134
• If the letter in that position is not found in that position in the answer but is found elsewhere in the 135
answer, then the letter is printed in lowercase. (This is the same as a yellow letter in Wordle.) 136
If the user runs out of attempts (i.e. the number of valid guesses they’ve made reaches the maximum but 137
they haven’t guessed the answer) OR end-of-file (EOF) is detected on standard input (e.g. the user presses 138
Ctrl-D when prompted for a guess), then your program should print the following to standard error (with a 139
following newline) and exit with exit status 3: 140
Bad luck – the word is “WORD “. 141
where WORD is replaced by the answer. The double quotes must be present. 142
If the last unsuccessful attempt is a valid guess then your program should report the letters that match in 143
the normal way before printing the message above and exiting. If the program detects EOF when expecting a 144
guess then no matching information is reported – the program just prints the message above and exits. 145
Other Functionality Notes 146
It is permissible for the answer to not appear in the dictionary of valid words – whether the guessed word is 147
the answer or not must be checked before checking whether the guess is in the dictionary or not. 148
It is possible that the dictionary does not contain any words of the correct length (and indeed may not 149
contain any words at all). In this case all guesses will be considered invalid unless the user happens to guess 150
the answer. 151
If EOF (end of file) is detected on standard input when attempting to read a new guess, then this is to be 152
interpreted as the user giving up and your program should print the “Bad luck …” message. 153
If a library call fails unexpectedly (e.g. malloc() returns NULL) then your program may behave in any way 154
you like. This will not be tested. 155
Your program may assume that guesses entered by the user are at most 50 characters (excluding the newline) 156
– the same assumption that can be made about dictionary entries. We will not test your program using guesses 157
longer than 50 characters. 158
Advanced Functionality 1 159
The matching behaviour described above applies when letters appear only once in the guess. If one or more 160
letters appears more than once in a guess then the reported match is slightly more complicated: 161
• If a letter appears more than once in the guess but only once in the answer, then 162
– If one of those repeated letters in the guess is in the correct position, then it will be reported in 163
uppercase in that position (right letter, right location) and the other of those letters in the guess will 164
be reported as not matching any letters (i.e. shown with a hyphen ‘-’). This makes it clear to the 165
user that the letter only appears once in the answer and that they have found that position. 166
– If neither of the letters in the guess is in the correct position, then the first of those letters in the 167
guess will be reported in lower case (right letter, wrong location) and the second will be reported as 168
not matching any letters in the answer (i.e. shown with a hyphen ‘-’). This makes it clear to the 169
user that the letter only appears once in the answer. 170
• Similar principles apply where there are three repeated letters in the guess and one or two of those letters 171
in the answer. The number of matches reported can never exceed the number of those letters in the answer 172
– and if a letter is in the correct location then it must be shown in uppercase (i.e. right letters in the right 173
location are considered a higher priority match then right letters in the wrong location). 174
4 Version 1.1
Advanced Functionality 2 175
The program functionality described above can be implemented without using malloc(). If you read the 176
dictionary file each time that you need to check the validity of a guess, then you don’t need to store the 177
dictionary in memory. Advanced Functionality 2 requires you to store the dictionary (which may have an 178
arbitrary number of words) in memory for checking the validity of guesses. (You don’t have to store the whole 179
dictionary – you can just store valid words of the correct length – this is up to you.) If you implement this 180
functionality then your program may only read the dictionary file once. 181
You must also ensure that your program frees all allocated memory before exiting3
. This will be checked 182
using valgrind. 183
Example Game Sessions 184
In the examples below, guesses entered on standard input are shown in bold green for clarity. Other lines are 185
output to standard output except for the “Bad luck …” message at the end of example 2 which is sent to 186
standard error. Note that the $ character is the shell prompt – it is not entered by the user. 187
Example 1: The word to be guessed is “tense”. Five letter words are the default with a maximum of six guesses.
$ ./wordle
Welcome to Wordle!
Enter a 5 letter word (6 attempts remaining):
Hi
Words must be 5 letters long – try again.
Enter a 5 letter word (6 attempts remaining):
wrdle
Word not found in the dictionary – try again.
Enter a 5 letter word (6 attempts remaining):
vOwEl
—eEnter a 5 letter word (5 attempts remaining):
erase
e–SE
Enter a 5 letter word (4 attempts remaining):
these
T-eSE
Enter a 5 letter word (3 attempts remaining):
tense
Correct!
$
Example 2: A 4 letter word with a maximum of 4 guesses – the word to be guessed is “byte”.
$ ./wordle -len 4 -max 4
Welcome to Wordle!
Enter a 4 letter word (4 attempts remaining):
2310
Words must contain only letters – try again.
Enter a 4 letter word (4 attempts remaining):
ease
—E
Enter a 4 letter word (3 attempts remaining):
TIME
t–E
Enter a 4 letter word (2 attempts remaining):
Vote
–TE
Enter a 4 letter word (last attempt):
3This includes the memory allocated by get_random_word().
5 Version 1.1
cute
–TE
Bad luck – the word is “byte”.
$
Provided Library: libcsse2310a1 188
A library has been provided to you with the following function which your program must use: 189
char* get_random_word(int wordLength); 190
The function is described in the get_random_word(3) man page on moss. (Run man get_random_word.) 191
To use the library, you will need to add #include
-I/local/courses/csse2310/include when compiling your code so that the compiler can find the include 193
file. You will also need to link with the library containing this function. To do this, use the compiler arguments 194
-L/local/courses/csse2310/lib -lcsse2310a1. 195
For testing purposes, if you set the environment variable WORD2310 prior to running ./wordle then get_- 196
random_word() will return the value in that variable (provided it is the correct length). This allows you to test 197
your program like this: 198
Example 3: Running wordle with a known word (“break”) for testing purposes.
$ WORD2310=break ./wordle
Welcome to Wordle!
…
Style 199
Your program must follow version 2.2.0 of the CSSE2310/CSSE7231 C programming style guide available on 200
the course Blackboard site. 201
Hints 202
1. The string representation of a single digit positive integer has a string length of 1. 203
2. You may wish to consider the use of the standard library functions isalpha(), islower(), isupper(), 204
toupper() and/or tolower(). Note that these functions operate on integers (ASCII values). so you will 205
need to cast characters to integers and vice versa as appropriate to avoid compiler warnings. For example, 206
given that variable c is of type char, the following code will convert the character stored in c to lower case 207
(without compiler warnings): 208
c = (char)tolower((int)c); 209
3. If a user enters a line of more than the requested number of characters to fgets() then the last non-null 210
character in the returned string will not be a newline. 211
4. Some other functions which may be useful include: strcasecmp(), strcmp(), strlen(), exit(), fopen(), 212
fgets(), and fprintf(). You should consult the man pages for these functions. 213
5. Note that implementation of the advanced functionality 2 will require the use of dynamically allocated 214
memory (i.e. with malloc() etc.) to store the dictionary in memory. You can implement the majority of 215
the functionality without dynamically allocated memory by opening and reading the dictionary each time 216
you need to check whether a word is valid or not. 217
Suggested Approach 218
It is suggested that you write your program using the following steps. Test your program at each stage and 219
commit to your SVN repository frequently. Note that the specification text above is the definitive description 220
of the expected program behaviour. The list below does not cover all required functionality. 221
6 Version 1.1
1. Write a program that outputs the usage error message and exits with exit status 1. This small program 222
(two lines in main()) will earn marks for detecting usage errors (category 1 below) – because it thinks 223
everything is a usage error!4
224
2. Detect the presence of the -len command line argument and, if present, check the presence/validity of 225
the argument that follows it. Exit appropriately if not valid. 226
3. Detect the presence of the -max command line argument and, if present, check the presence/validity of 227
the argument that follows it. Exit appropriately if not valid. 228
4. Detect the presence of a dictionary file name argument and check whether it can be opened for reading. 229
Exit appropriately if not valid. 230
5. Determine the answer word using the supplied library. Print the welcome message and print the prompt 231
for input. 232
6. Repeatedly prompt and read a word (guess) from the user and check the word is the expected length and 233
only contains letters. Print appropriate message if not. Exit appropriately if EOF detected or if number 234
of attempts is exceeded. 235
7. Check if the guess matches the answer – if so, exit appropriately, otherwise print a message that the word 236
must be found in the dictionary. (Even though you haven’t checked the dictionary, pretending that you 237
have will earn marks.) 238
8. Write a function to read all the words in the dictionary and check whether the guess is in the dictionary. 239
If not, print an appropriate message and prompt again. (Initially, you can read the dictionary for every 240
guess.) 241
9. If the guess is in the dictionary, report on the match – i.e. which letters in the guess can be found in the 242
answer, etc. 243
10. Extend matching to deal with case insensitive matching 244
11. Add code to store the dictionary (or words of the right length from the dictionary) in memory, and scan 245
this copy of the dictionary when checking guesses. 246
12. Extend the match reporting to deal with answers that have repeated letters. 247
13. Implement any remaining functionality as required . . . 248
Forbidden Functions 249
You must not use any of the following C functions/statements. If you do so, you will get zero (0) marks for the 250
assignment. 251
• goto 252
• longjmp() and equivalent functions 253
• system() 254
• execl() or any other members of the exec family of functions 255
• POSIX regex functions 256
Submission 257
Your submission must include all source and any other required files (in particular you must submit a Makefile). 258
Do not submit compiled files (eg .o, compiled programs) or dictionary files. 259
Your program (named wordle) must build on moss.labs.eait.uq.edu.au with: 260
make 261
4However, once you start adding more functionality, it is possible you may lose some marks in this category if your program
can’t detect all the valid command lines.
7 Version 1.1
Your program must be compiled with gcc with at least the following options: 262
-pedantic -Wall -std=gnu99 263
You are not permitted to disable warnings or use pragmas to hide them. You may not use source files other 264
than .c and .h files as part of the build process – such files will be removed before building your program. 265
If any errors result from the make command (i.e. the wordle executable can not be created) then you will 266
receive 0 marks for functionality (see below). Any code without academic merit will be removed from your 267
program before compilation is attempted (and if compilation fails, you will receive 0 marks for functionality). 268
Your program must not invoke other programs or use non-standard headers/libraries. 269
Your assignment submission must be committed to your subversion repository under 270
https://source.eait.uq.edu.au/svn/csse2310-sem1-sXXXXXXX/trunk/a1 271
where sXXXXXXX is your moss/UQ login ID. Only files at this top level will be marked so do not put source 272
files in subdirectories. You may create subdirectories for other purposes (e.g. your own test files) but these 273
will not be considered in marking – they will not be checked out of your repository. 274
You must ensure that all files needed to compile and use your assignment (including a Makefile) are commit- 275
ted and within the trunk/a1 directory in your repository (and not within a subdirectory) and not just sitting 276
in your working directory. Do not commit compiled files or binaries. You are strongly encouraged to check out 277
a clean copy for testing purposes. 278
To submit your assignment, you must run the command 279
2310createzip a1 280
on moss and then submit the resulting zip file on Blackboard (a GradeScope submission link will be made 281
available in the Assessment area on the CSSE2310/7231 Blackboard site)5
. The zip file will be named 282
sXXXXXXX_csse2310_a1_timestamp.zip 283
where sXXXXXXX is replaced by your moss/UQ login ID and timestamp is replaced by a timestamp indicating 284
the time that the zip file was created. 285
The 2310createzip tool will check out the latest version of your assignment from the Subversion repository, 286
ensure it builds with the command ‘make’, and if so, will create a zip file that contains those files and your 287
Subversion commit history and a checksum of the zip file contents. You may be asked for your password as 288
part of this process in order to check out your submission from your repository. 289
You must not create the zip file using some other mechanism and you must not modify the zip file prior 290
to submission. If you do so, you will receive zero marks. Your submission time will be the time that the file 291
is submitted via GradeScope on Blackboard, and not the time of your last repository commit nor the time of 292
creation of your submission zip file. 293
We will mark your last submission, even if that is after the deadline and you made submissions before the 294
deadline. Any submissions after the deadline6 will incur a late penalty – see the CSSE2310/7231 course profile 295
for details. 296
Marks 297
Marks will be awarded for functionality and style and documentation. Marks may be reduced if you are asked 298
to attend an interview about your assignment and you are unable to adequately respond to questions – see the 299
Student conduct section above. 300
Functionality (60 marks) 301
Provided your code compiles (see above) and does not use any prohibited statements/functions (see above), and 302
your zip file has been generated correctly and has not been modified prior to submission, then you will earn 303
functionality marks based on the number of features your program correctly implements, as outlined below. 304
Partial marks will be awarded for partially meeting the functionality requirements. Not all features are of equal 305
difficulty. If your program does not allow a feature to be tested then you will receive 0 marks for 306
that feature, even if you claim to have implemented it. For example, if your program can never open a file, we 307
can not determine if your program can determine word validity correctly. If your program takes longer than 10 308
5You may need to use scp or a graphical equivalent such as WinSCP, Filezilla or Cyberduck in order to download the zip file to
your local computer and then upload it to the submission site.
6or your extended deadline if you are granted an extension.
8 Version 1.1
seconds to run any test7
, then it will be terminated and you will earn no marks for the functionality associated 309
with that test. The markers will make no alterations to your code (other than to remove code without academic 310
merit). 311
Marks will be assigned in the following categories. 312
1. Program correctly handles invalid command lines (8 marks) 313
2. Program correctly handles dictionary files that are unable to be read (4 marks) 314
3. Program initially prompts for input correctly on valid command lines (4 marks) 315
4. Program correctly handles guesses of the wrong length (5 marks) 316
5. Program correctly handles guesses containing non-letters (5 marks) 317
6. Program correctly handles invalid guesses (with both default and supplied dictionary) (6 marks) 318
7. Program correctly handles incorrect guesses with various capitalisation (5 marks) 319
8. Program correctly handles running out of attempts (5 marks) 320
9. Program correctly handles EOF on input (5 marks) 321
10. Program correctly handles getting the answer right (including varied capitalisation) (5 marks) 322
11. Program correctly handles valid guesses with repeated letters (including varied capitalisation) (4 marks) 323
12. Program only reads the dictionary file once and frees all allocated memory (4 marks) 324
It is unlikely that you can earn marks for categories 7 and later unless your program correctly reports matching 325
letters. It is unlikely that you can earn marks for categories 4 and later unless your program correctly prompts 326
for guesses. Some functionality may be assessed in multiple categories, e.g. the ability to set the word length 327
with -len. 328
Style Marking 329
Style marking is based on the number of style guide violations, i.e. the number of violations of version 2.2 of 330
the CSSE2310/CSSE7231 C Programming Style Guide (found on Blackboard). Style marks will be made up of 331
two components – automated style marks and human style marks. These are detailed below. For assignment 332
one, there is no weighting associated with human style marking – but you will be given feedback 333
so that you can improve your style for later programming assignments. 334
You should pay particular attention to commenting so that others can understand your code. The marker’s 335
decision with respect to commenting violations is final – it is the marker who has to understand your code. To 336
satisfy layout related guidelines, you may wish to consider the indent(1) tool. Your style marks can never be 337
more than your functionality mark – this prevents the submission of well styled programs which don’t meet at 338
least a minimum level of required functionality. 339
You are encouraged to use the style.sh tool installed on moss to style check your code before submission. 340
This does not check all style requirements, but it will determine your automated style mark (see below). Other 341
elements of the style guide are checked by humans. 342
All .c and .h files in your submission will be subject to style marking. This applies whether they are 343
compiled/linked into your executable or not8
. 344
Automated Style Marking (5 marks) 345
Automated style marks will be calculated over all of your .c and .h files as follows. If any of your submitted 346
.c and/or .h files are unable to be compiled by themselves then your automated style mark will be zero (0). 347
(Automated style marking can only be undertaken on code that compiles. The provided style.sh script checks 348
this for you.) 349
If your code does compile then your automated style mark will be determined as follows: Let 350
7Valgrind tests for memory leaks (category 12) will be allowed to run for longer.
8Make sure you remove any unneeded files from your repository, or they will be subject to style marking.
9 Version 1.1
• W be the total number of distinct compilation warnings recorded when your .c files are individually built 351
(using the correct compiler arguments) 352
• A be the total number of style violations detected by style.sh when it is run over each of your .c and 353
.h files individually9
. 354
Your automated style mark S will be 355
S = 5 − (W + A) 356
If W +A ≥ 5 then S will be zero (0) – no negative marks will be awarded. Note that in some cases style.sh 357
may erroneously report style violations when correct style has been followed. If you believe that you have been 358
penalised incorrectly then please bring this to the attention of the course coordinator and your mark can be 359
updated if this is the case. Note also that when style.sh is run for marking purposes it may detect style 360
errors not picked up when you run style.sh on moss. This will not be considered a marking error – it is your 361
responsibility to ensure that all of your code follows the style guide, even if styling errors are not detected in 362
some runs of style.sh. 363
Human Style Marking (5 marks) – not included in the assignment one total mark 364
Your human style mark will not be included in your total mark for assignment one, but feedback will be given 365
so that you are better prepared for the later programming assignments. 366
The human style mark (out of 5 marks) will be based on the criteria/standards below for “comments”, 367
“naming” and “other”. The meanings of words like appropriate and required are determined by the requirements 368
in the style guide. Note that functions longer than 50 lines will be penalised in the automated style marking. 369
Functions that are also longer than 100 lines will be further penalised here. 370
Comments (2.5 marks) 371
Mark Description
0
The majority (50%+) of comments present are inappropriate OR there are many required comments
missing
0.5 The majority of comments present are appropriate AND the majority of required comments are
present
1.0 The vast majority (80%+) of comments present are appropriate AND there are at most a few missing
comments
1.5 All or almost all comments present are appropriate AND there are at most a few missing comments
2.0 Almost all comments present are appropriate AND there are no missing comments
2.5 All comments present are appropriate AND there are no missing comments
372
Naming (1 mark) 373
Mark Description
0 At least a few names used are inappropriate
0.5 Almost all names used are appropriate
1.0 All names used are appropriate
374
Other (1.5 marks) 375
Mark Description
0
One or more functions is longer than 100 lines of code OR there is more than one global/static
variable present inappropriately OR there is a global struct variable present inappropriately OR
there are more than a few instances of poor modularity (e.g. repeated code)
0.5 All functions are 100 lines or shorter AND there is at most one inappropriate non-struct global/static
variable AND there are at most a few instances of poor modularity
1.0
All functions are 100 lines or shorter AND there are no instances of inappropriate global/static
variables AND there is no or very limited use of magic numbers AND there is at most one instance
or poor modularity
1.5 All functions are 100 lines or shorter AND there are no instances of inappropriate global/static
variables AND there is no use of magic numbers AND there are no instances of poor modularity
376
9Every .h file in your submission must make sense without reference to any other files, e.g., it must #include any .h files that
contain declarations or definitions used in that .h file.
10 Version 1.1
SVN commit history assessment (5 marks) – not included in the assignment one 377
total mark 378
Your SVN commit history mark will not be included in your total mark for assignment one, but feedback will 379
be given so that you are better prepared for the later programming assignments. 380
Markers will review your SVN commit history for your assignment up to your submission time. This element 381
will be graded according to the following principles: 382
• Appropriate use and frequency of commits (e.g. a single monolithic commit of your entire assignment will 383
yield a score of zero for this section) 384
• Appropriate use of log messages to capture the changes represented by each commit. (Meaningful messages 385
explain briefly what has changed in the commit (e.g. in terms of functionality) and/or why the change 386
has been made and will be usually be more detailed for significant changes.) 387
The standards expected are outlined in the following rubric: 388
Mark
(out of 5) Description
0
Minimal commit history – single commit OR
all commit messages are meaningless.
1
Some progressive development evident (more than one commit) OR
at least one commit message is meaningful.
2
Some progressive development evident (more than one commit) AND
at least one commit message is meaningful.
3
Progressive development is evident (multiple commits) AND
at least half the commit messages are meaningful.
4
Multiple commits that show progressive development of all functionality AND
meaningful messages for most commits.
5
Multiple commits that show progressive development of all functionality AND
meaningful messages for ALL commits.
389
We understand that you are just getting to know Subversion, and you won’t be penalised for a few “test 390
commit” type messages. However, the markers must get a sense from your commit logs that you are practising 391
and developing sound software engineering practices by documenting your changes as you go. In general, tiny 392
changes deserve small comments – larger changes deserve more detailed commentary. 393
Design Documentation (10 marks) – for CSSE7231 students only 394
CSSE7231 students must submit a PDF document containing a written overview of the architecture and design 395
of your program. This must be submitted via the Turnitin submission link on Blackboard. 396
Please refer to the grading criteria available on BlackBoard under “Assessment” for a detailed breakdown 397
of how these submissions will be marked. Note that your submission time for the whole assignment will be 398
considered to be the later of your submission times for your zip file and your PDF design document. Any late 399
penalty will be based on this submission time and apply to your whole assignment mark. 400
This document should describe, at a general level, the functional decomposition of the program, the key design 401
decisions you made and why you made them. It must meet the following formatting requirements: 402
• Maximum two A4 pages in 12 point font 403
• Diagrams are permitted up to 25% of the page area. The diagram(s) must be discussed in the text, it is 404
not ok to just include a figure without explanatory discussion. 405
Don’t overthink this! The purpose is to demonstrate that you can communicate important design decisions, 406
and write in a meaningful way about your code. To be clear, this document is not a restatement of the program 407
specification – it is a discussion of your design and your code. 408
If your documentation obviously does not match your code, you will get zero for this compo- 409
nent, and will be asked to explain why. 410
11 Version 1.1
Total Mark 411
Let 412
• F be the functionality mark for your assignment (out of 60). 413
• S be the automated style mark for your assignment (out of 5). 414
• H be the human style mark for your assignment (out of 5) – not counted for assignment one. 415
• C be the SVN commit history mark (out of 5) – not counted for assignment one. 416
• D be the documentation mark for your assignment (out of 10 for CSSE7231 students) – or 0 for CSSE2310 417
students. 418
Your total mark for the assignment will be: 419
M = F + min{F, S} + min{F, D} 420
out of 65 (for CSSE2310 students) or 75 (for CSSE7231 students). 421
For future programming assignments, your total mark will be:
M = F + min{F, S + H} + min{F, C} + min{F, D}
out of 75 (for CSSE2310 students) or 85 (for CSSE7231 students).
422
In other words, you can’t get more marks for style or SVN commit history or documentation than you do 423
for functionality. Pretty code that doesn’t work will not be rewarded! 424
Late Penalties 425
Late penalties will apply as outlined in the course profile. 426
Specification Updates 427
Any errors or omissions discovered in the assignment specification will be added here, and new versions released 428
with adequate time for students to respond prior to due date. Potential specification errors or omissions can be 429
discussed on the discussion forum or emailed to csse2310@uq.edu.au. 430
431
Version 1.1 432
• Clarified that command line validity must be checked prior to checking whether a provided dictionary file 433
can be read. 434
• Clarified that guesses will be no more than 50 characters longer (excluding any newline) – longer guesses 435
will not be tested. 436
• Clarified that valgrind tests for memory leaks (marking criteria 12) will be allowed to run for longer than 437
the stated 10 seconds. 438
• Clarified that marking criteria 7 is about incorrect guesses and that criteria 11 is about valid guesses. 439
• Fixed hint about tolower() etc. – casting is not needed to avoid compiler warnings with the compiler 440
that we are using. 441
• Clarified when correct guesses are checked for. 442
12 Version 1.1
