From 10c548e3c5633e084a74aa9f1c93b70b0fca171b Mon Sep 17 00:00:00 2001 From: Hayden Hargreaves Date: Fri, 31 Oct 2025 13:24:05 -0700 Subject: [PATCH] Update README.md --- README.md | 230 +++++++++++++++++++++++++++--------------------------- 1 file changed, 115 insertions(+), 115 deletions(-) diff --git a/README.md b/README.md index 06a2bb5..74a71f8 100644 --- a/README.md +++ b/README.md @@ -1,115 +1,115 @@ -# MarkdownToHtmlCompiler - -### Project Overview - -The goal is to create a program that reads a file containing text formatted in a simple version of -Markdown and converts it into a valid HTML file. The program will need to identify and translate -specific syntax (e.g., `# Heading` to `

Heading

`, `*text*` to `text`). - - -### Implementation Requirements (Generated by Gemini) - -Class Hierarchy: Design a class hierarchy to represent the components of your Markdown document. An -abstract base class, Element, can define common behavior. Derived classes would then represent specific -types of elements, such as Heading, Paragraph, BoldText, and ListItem. This is a perfect example of -inheritance and polymorphism. - -Object Composition: A Document class can be composed of multiple Element objects, representing the -entire file. A Parser class would be composed of helper methods to break down the input string and -build the Document object. This shows how you can build a complex system from smaller, self-contained -objects. - -File I/O and Exceptions: You will need to use ifstream to read the Markdown file and ofstream to write -the generated HTML file. Your code should use exceptions to gracefully handle potential errors, such -as a file not being found. - -Operator Overloading: Overload the << stream insertion operator for your Element and Document classes. -This would allow you to easily print the generated HTML to the console or write it to a file, making -your code cleaner and more readable. - -UML Diagram: The complexity of the class relationships makes a UML diagram an essential part of the -project. It will help you plan your design and will be a key component of your submission. - -Recursive Descent Parser: This is the primary algorithm you'll use. It's a top-down parsing technique -where a set of recursive functions "descend" through the grammar of your simple Markdown language. For -example, a parse_document() function would call parse_line(), which in turn might call parse_bold_text() -or parse_italic_text(). This method is intuitive and easy to implement for a simple grammar. - -Stack: A stack is essential for handling nested elements. For instance, if you allow bold text inside -italic text (_This is *bold and italic* text_), you can push the _ token onto the stack and then push -the * token. When you encounter the closing *, you check if the top of the stack matches. This ensures -that all tags are correctly opened and closed. Your presentation can visually demonstrate this process -with a stack diagram. - -Hash Map or Map: A hash map (std::unordered_map) or a map (std::map) can be used to efficiently store -and retrieve the HTML equivalent for each Markdown tag. For example, you could map `#` to `

`or `*` -to ``. This provides O(1) average-case lookup time. - - -### Contribution Policy - -###### Branching -When working on this project, please use a feature branch (i.e. `feature/parser`) with a descriptive name. -`feature/a` is not a descriptive name. These branches should be branched off the most recent `main` branch, -we will not make use of a `dev` or `staging` branch since the project is small in scale as well as time. -**However, if the project becomes larger or out-of-control, a dev/staging branch will be implemented.** - -###### Commits - -When working, it is best practice to commit code as much as possible, without being over zealous. For -example, when a feature or bug is complete, its time to commit. But when you have to make a new function, -that does not mean its time. Each team member should use their best judgment. - -Commit messages a little bit more important, when working in a team, it is important to provide strong, -clear and concise commit messages. In this project, the team will use a simple formula: - -**(SUBJECT) Title: textual description** - -i.e. (FIX) Rendering completed: explain what changed in short. - -###### Pushing - -When working in a feature branch, pushing and pulling has no restrictions. Feel free to do as much -(or as little) as possible. However, you **CANNOT** push directly to `main`, the VCS will not allow you -to do so, but do not make that mistake. When you are ready to merge a feature, you will create a PR -and once it has been reviewed and approved it will be automatically merged in. - -###### Pull Requests (PR) - -Once a feature is complete, you will create a pull request. Before a request can be merged into `main`, -one approval is required (which cannot be the author). This practice is to promote team work and encourage -code reviews. Each team member is expected to check in frequently and review as often as they are able to, -however, there is no defined time requirement. Personal communication is totally acceptable as a means to -request approval, since I am unsure if this platform will notify members. - -###### Issues - -If a bug, issue, or otherwise concern is noticed the first thing the team member should do is create an -issue. An issue should be descriptive and contain everything another team member needs to understand the -issue and its context. This way, a new team member can tackle the issue without contextual gaps. - -If a member would like to work on the issue themself, the `assignee` field is where this should be defined. -If a member would like help from another member, they should assign the other team member to the issue, and -leave a comment in the issue itself describing what help is needed. - -**Labels** are important for understanding what type of issues/bugs exist in the application. When a bug is -created, make sure the proper labels are applied. These labels will be abstract, such as: `bug`, `fix` or `feature` -and they will also be specific, such as: `parser`, `i/o` or `processer`. A combination of both styles of labels -allows other team members to understand what is going on. If a member feels an issue is missing, they are free -to create new ones, but there is a such thing as **too many labels** a few per issue is totally fine. They are -not meant to replace the description. - -**Priority** is the final important factor to consider. In this project, priority will be defined using labels -as well. The policy defined above will apply here to priority labels as well. However, these labels are -**mutually exclusive**. - -###### Projects (Sprints) - -The use of the `projects` tab in the VCS will allow the team to remain organized as create notes and action -items that should be completed before one another. These resemble `sprints` from the `AGILE` development life cycle. -A new "project" should be created when a large piece of functionality needs to be created. Issues can **and should** -be attached to the projects they are related too. This will continue to encourage teamwork and organization. - -Projects should have defined criteria, such as input and outputs, expectations and a semi-defined timeline. -Once a description and is defined, tasks can be added and moved around as needed. The team will use **Kanban** -project types, as they are simple and easy to understand for new team members. +# MarkdownToHtmlTranspiler + +### Project Overview + +The goal is to create a program that reads a file containing text formatted in a simple version of +Markdown and converts it into a valid HTML file. The program will need to identify and translate +specific syntax (e.g., `# Heading` to `

Heading

`, `*text*` to `text`). + + +### Implementation Requirements (Generated by Gemini) + +Class Hierarchy: Design a class hierarchy to represent the components of your Markdown document. An +abstract base class, Element, can define common behavior. Derived classes would then represent specific +types of elements, such as Heading, Paragraph, BoldText, and ListItem. This is a perfect example of +inheritance and polymorphism. + +Object Composition: A Document class can be composed of multiple Element objects, representing the +entire file. A Parser class would be composed of helper methods to break down the input string and +build the Document object. This shows how you can build a complex system from smaller, self-contained +objects. + +File I/O and Exceptions: You will need to use ifstream to read the Markdown file and ofstream to write +the generated HTML file. Your code should use exceptions to gracefully handle potential errors, such +as a file not being found. + +Operator Overloading: Overload the << stream insertion operator for your Element and Document classes. +This would allow you to easily print the generated HTML to the console or write it to a file, making +your code cleaner and more readable. + +UML Diagram: The complexity of the class relationships makes a UML diagram an essential part of the +project. It will help you plan your design and will be a key component of your submission. + +Recursive Descent Parser: This is the primary algorithm you'll use. It's a top-down parsing technique +where a set of recursive functions "descend" through the grammar of your simple Markdown language. For +example, a parse_document() function would call parse_line(), which in turn might call parse_bold_text() +or parse_italic_text(). This method is intuitive and easy to implement for a simple grammar. + +Stack: A stack is essential for handling nested elements. For instance, if you allow bold text inside +italic text (_This is *bold and italic* text_), you can push the _ token onto the stack and then push +the * token. When you encounter the closing *, you check if the top of the stack matches. This ensures +that all tags are correctly opened and closed. Your presentation can visually demonstrate this process +with a stack diagram. + +Hash Map or Map: A hash map (std::unordered_map) or a map (std::map) can be used to efficiently store +and retrieve the HTML equivalent for each Markdown tag. For example, you could map `#` to `

`or `*` +to ``. This provides O(1) average-case lookup time. + + +### Contribution Policy + +###### Branching +When working on this project, please use a feature branch (i.e. `feature/parser`) with a descriptive name. +`feature/a` is not a descriptive name. These branches should be branched off the most recent `main` branch, +we will not make use of a `dev` or `staging` branch since the project is small in scale as well as time. +**However, if the project becomes larger or out-of-control, a dev/staging branch will be implemented.** + +###### Commits + +When working, it is best practice to commit code as much as possible, without being over zealous. For +example, when a feature or bug is complete, its time to commit. But when you have to make a new function, +that does not mean its time. Each team member should use their best judgment. + +Commit messages a little bit more important, when working in a team, it is important to provide strong, +clear and concise commit messages. In this project, the team will use a simple formula: + +**(SUBJECT) Title: textual description** + +i.e. (FIX) Rendering completed: explain what changed in short. + +###### Pushing + +When working in a feature branch, pushing and pulling has no restrictions. Feel free to do as much +(or as little) as possible. However, you **CANNOT** push directly to `main`, the VCS will not allow you +to do so, but do not make that mistake. When you are ready to merge a feature, you will create a PR +and once it has been reviewed and approved it will be automatically merged in. + +###### Pull Requests (PR) + +Once a feature is complete, you will create a pull request. Before a request can be merged into `main`, +one approval is required (which cannot be the author). This practice is to promote team work and encourage +code reviews. Each team member is expected to check in frequently and review as often as they are able to, +however, there is no defined time requirement. Personal communication is totally acceptable as a means to +request approval, since I am unsure if this platform will notify members. + +###### Issues + +If a bug, issue, or otherwise concern is noticed the first thing the team member should do is create an +issue. An issue should be descriptive and contain everything another team member needs to understand the +issue and its context. This way, a new team member can tackle the issue without contextual gaps. + +If a member would like to work on the issue themself, the `assignee` field is where this should be defined. +If a member would like help from another member, they should assign the other team member to the issue, and +leave a comment in the issue itself describing what help is needed. + +**Labels** are important for understanding what type of issues/bugs exist in the application. When a bug is +created, make sure the proper labels are applied. These labels will be abstract, such as: `bug`, `fix` or `feature` +and they will also be specific, such as: `parser`, `i/o` or `processer`. A combination of both styles of labels +allows other team members to understand what is going on. If a member feels an issue is missing, they are free +to create new ones, but there is a such thing as **too many labels** a few per issue is totally fine. They are +not meant to replace the description. + +**Priority** is the final important factor to consider. In this project, priority will be defined using labels +as well. The policy defined above will apply here to priority labels as well. However, these labels are +**mutually exclusive**. + +###### Projects (Sprints) + +The use of the `projects` tab in the VCS will allow the team to remain organized as create notes and action +items that should be completed before one another. These resemble `sprints` from the `AGILE` development life cycle. +A new "project" should be created when a large piece of functionality needs to be created. Issues can **and should** +be attached to the projects they are related too. This will continue to encourage teamwork and organization. + +Projects should have defined criteria, such as input and outputs, expectations and a semi-defined timeline. +Once a description and is defined, tasks can be added and moved around as needed. The team will use **Kanban** +project types, as they are simple and easy to understand for new team members.