For homework I, you have to write a program based on the set requirements and document the results. The focus of this homework is in the correct use of files and structures alongside with common practices such as dividing code and command line arguments. Some variants will include use of enums.
Requirements for the program
The code must adhere to all of the best practices introduced during Programming 1 and the first weeks of Programming 2.
Your solution can include topics that have not been covered, as long as they are used correctly and well documented. You need to provide motivation why those concepts were used so that it clear, that you have mastered those topics.
Requirements for the standards and environment
The program must be written in the C programming language. You are permitted to use the C90 and C99 standards. Using newer standards (C11, C17, C23) is permitted, if it provides additional value. This must be explained in the report.
In addition to the standard C libraries, you are allowed to use C POSIX and GNU C libraries and extensions. Any other libraries must be agreed upon separately.
Your program will be compiled and tested in a Linux environment, equivalent to the one in the lab computers (OpenSUSE SLED-15 SP5, using GCC-12) or with the latest Ubuntu version (Ubuntu Linux 25.10, using GCC-15 or later). Compatibility with Windows or MacOS is not required.
General requirements for the solution
- The source code has to be divided into more than one file. Exact number of files is and the division left to the author of the solution.
- At minimum, a source and a header file must be presented
- If multiple .c files are used, a Makefile must be provided to compile the solution
- The program must accept the name of the input data file as a command line argument
- The behavior, when the argument with the name of the file is not provided or the file could not be opened, is up to the developer. Chosen behavior must be documented!
- The result of the program must be shown both on the screen and saved in an output file
- The output file will only contain the results of the program
- The results of the program must also be presented on the screen. You are allowed to be more verbose in your terminal output, include interim results and additional relevant information, confirmations, prompts for input etc.
- The output needs to be clear and understandable
- The name of the output file is left to the developer
- The program must work with data files where the length of the file is not predefined. Adding or removing some lines from the data file should not cause any issues
- Defining the maximum number of lines the program can handle is allowed. If there are more entries in the data file, reading them is not necessary.
- There is no need for dynamic memory allocation -we will cover that in the next homework. You are still allowed to use it, if you handle it properly (only allocating for what you need, checking the allocation, freeing the memory etc).
- The data is read from the input file and stored in a struct array. The task description may also require use of nested structures. You are free to add additional members and nested structures to the solution. You can also add additional structs, if it makes sense for the solution.
- The program must provide a reasonable user experience (UX)
- The program must notify the user of any errors encountered in a clear manner. The message must be precise and helpful to the user to solve the issue. All error messages must be written to the stderr standard stream.
- When user input is expected, the prompt must be clear to the user. If the input needs to be in a specific format, you must provide the user with the expected format. If applicable, add an example of how the input should be written.
- If the program contains searching, filtering or grouping features and there are no matches the set criteria, it must be written explicitly to the user.
Input data file requirements
- The data file must only contain fields described in your task variant (nothing extra, none skipped)
- Data model for the input file is created by the author of the solution based on their capabilities and knowledge. This includes data field delimiters, order of data fields, data field contents, complexity, etc. The chosen data model and the decisions for it are documented by the author in the document provided alongside the program.
- The data records will be created by the author of the solution and submitted with the solution. The data file must contain at least 10 entries. If the author of the work presents multiple data files for demonstrating different scenarios, the length requirement only applies to one of the data files.
Documentation template
Use the same templates as you used in Programming 1, Homework 1 (https://blue.pri.ee/ttu/programming-i/homework-i/) and adjust it to fit the requirements of this homework.
Documentation requirements
The expected length of the main written content is 3 – 6 A4 pages long, excluding any figures.
Focus on structured documentation! Avoid story-telling (except summary).
- Title page
- Declaration of originality
- List of abbreviations and terms (if needed)
- Table of contents
- List of figures
- List of tables
- The task description (variant)
- Detailed description of the solution (no walls of text!)
- A brief description of what the program does
- Program workflow – In what order are things done? (Do not go into details! Half a page maximum!)
- Project structure – names of files, short description. If code is divided into directories, explain the division.
Recommended: show output of tree application - Document the structures
- Purpose of the structure
- Details (member name, data type, description, example value), formatted as a table
- Document the enumerations (if applicable)
- Name, description and possible values of the enum
- Special situation / error handling
- Description of issue
- What’s the status of it – did you solve it, work around it, is it still present in the code
- If it was mitigated, how did you mitigate it
- Data file structure
- Structure of one record (data field order, separators between fields, separators between records)
- Data fields – name, data type, example of a value, meaning of data (semantics), any limitations (e.g. length, value range, illegal values)
- Present a single data record from the file as an example.
- How-to guide for using your program. Describe all options that can be used regarding command line arguments.
- Extra task (if applicable)
- Summary
- Write a few sentences about your approach to the task and progression during it
- Write a few sentences about the task itself and the complexity of it
- If possible, give an estimate on the workload
- Would you recommend using this task in the future? Would you change anything about it and if so, what?
- Additional comments, emotions, thoughts
- References (can be omitted if not present)
- Use IEEE style for references
English official reference: https://journals.ieeeauthorcenter.ieee.org/wp-content/uploads/sites/7/IEEE_Reference_Guide.pdf
Reference help by TalTech (in Estonian): https://haldus.taltech.ee/sites/default/files/2024-05/IEEE_stiilis_viitamine_2024%20%281%29.pdf - Everything that wasn’t covered within the subject and that you didn’t create on your own.
- This includes help from a friend or a colleague: https://libraryguides.vu.edu.au/ieeereferencing/personalcommunication
- Use of AI tools must be referenced (i.e. ChatGPT, Gemini, …)
- All references must be precise. References such as stackoverflow.com or google.com are meaningless. It must be directly to the page where you got the information from.
- Use IEEE style for references
- Screen capture(s) of the program
- Screenshots can be added as an appendix or embedded within the write up of the solution – in this case you can extend the length by the amount of pictures
- The screenshots should show both normal operation and operation in various error situations
Extra task for bonus points
It is possible to earn up to 15 bonus points from the task. In order to get any points, you must include the added features to the report. It is possible to obtain partial bonus points if not all requirements are met.
To get bonus points, the following requirements must also be met in addition to the base requirements
- Comprehensive support for command line arguments
- It must be possible to use the program without command line arguments, using default values.
- Must support use of a different input file name
- Must support use of a different output file name
- Must support disabling printing on the screen
- Must support disabling writing the output to the file
- You must figure out a reasonable way to allow for the use of these options – this includes allowing for multiple options to be used at the same time.
- You can write the handling of command line arguments manually or use unistd.h or argp.h libraries for parsing.
- The program must hold the default values in a separate configuration file, provided with the solution. During the execution of the program, the settings are to be kept in a separate
struct dedicated for settings. This struct is allowed to be a global variable.
- At minimum, the configuration file needs to hold the name of the input and output files and output settings (output to the terminal enabled, output to the file enabled). Additional settings are allowed to support the application better.
- The configuration file must be written in a way, that if the order of the settings changes, it will still be correctly processed.
- The values in the settings file are used when no command line arguments are provided
- If any of the values are passed using command line arguments, they will be used in place of the value in the settings file (e.g. if the name of the input file is provided, it will be used for the input, but all other settings are taken from the settings file). The values in the settings file must not be overwritten.
- You must add a level 1 heading to the documentation called “Extra task”.
- Describe the added features
- Describe the process on how you approached supporting the command line arguments
- Explain the reasoning how you created the settings file and made it work even if the order of the values changes.
- Write a specification of the options supported by the specification file.
Deadlines
A complete homework must be submitted no later than 15.03.2026 23:59:59 (local time)
Each day passed the homework deadline will deduct 1 point from the final homework score. The late penalty is capped at 30 points.
If we have questions about the submitted homework or are not sure about the original author of this work, we will grade this with 0p. In this case, the work must be defended.
If it becomes necessary, we will enforce the rules and guidelines of [Procedure for processing a student’s violation of academic practices and contemptible behavior in the School of Information Technologies]
We will only accept Your homework until the lockdown date (check introduction slides). Past that, submitting your homework will not be possible.
Submitting
The homework needs to be submitted in the Moodle course under Homework 1.
Files required:
- Documentation (pdf)
- All of the code files (.c and .h) to compile the program. If multiple files are used, a Makefile is also required.
- Data files required to run the program
Naming schema: HW1_lastname[_filename]
Naming schema only applies to files directly uploaded to Moodle. It does not apply to files stored in the archive. Even if uploaded as an archive, the PDF file must be uploaded separately!
Example (separate files):
HW1_Tiib.c
HW1_Tiib.h
HW1_Tiib_data.txt
HW1_Tiib_report.pdf
Example (project as an archive):
Example:
HW1_Tiib_project.zip
HW1_Tiib_report.pdf
NB! If you changed the names of the files before uploading, make sure your solution still compiles and works with the new names!
Result and feedback
After your work has been checked and graded, you will see the result and feedback on Moodle (visible from your gradebook only!). If everything was well done, feedback may be absent.
Fixing your homework
You are allowed to fix and improve your homework score until the date of homework lockdown. All fixed submissions are subject to defense.
To fix your homework, first go through your feedback. Then contact your teacher and agree upon the process of how this homework can be fixed.
NB! If fixing the homework changes more than half of the original homework, it is considered as submitting a completely new homework, from which minus points can be deducted from depending on the time of submission.