Update report - final changes

Author: ReadieFur

dist/Report.pdf

@@ -102,12 +102,12 @@ \subsection*{Custom unit test file parser}
 \subsection*{Manual testing}
 \addcontentsline{toc}{subsection}{\protect\numberline{}Manual testing}
 \label{sec:StandaloneToolTests}
-For the manual testing of the program a simple test solution was created, this test solution contained one instance of every error and was used as a worst case scenario example. This worst case scenario example was used to test the reliability of the program and in particular the standalone tool. It was initially feared that if a bug was present or the analyzer would find its code fixes invalid, the potential for a stack overflow could occur as the code would be fixed, re-evaluated and fixed again over and over due to the nature of the analyzers having to run in a read-eval loop to fix the code one by one. Fortunately this was not the case and the program was able to fix all the errors in the test solution without any issues. The program was also tested against the example solutions provided by Microsoft under the MIT license which allows me full permission to use their code as test data for my program, though results for this were not recorded as the test solution was deemed sufficient for testing purposes.
+For the manual testing of the program a simple test solution was created. This test solution contained one instance of every error and was used as a worst case scenario example. Which was then used to test the reliability of the program and in particular the standalone tool. It was initially feared that if a bug was present or the analyzer would find its code fixes invalid, the potential for a stack overflow could occur as the code would be fixed, re-evaluated and fixed again over and over due to the nature of the analyzers having to run in a read-eval loop to fix the code one by one. The program was constructed to avoid this and it was shown that it did not get stuck in the read-eval loop, and the program was able to fix all the errors in the test solution without any issues. The program was also tested against the example solutions provided by Microsoft under the MIT license which allows me full permission to use their code as test data for this program, though results for this were not recorded as the test solution was deemed sufficient for testing purposes, with more time these would have been re-run and the evidence included.
 
 \subsection*{Debugging research process}
 \addcontentsline{toc}{subsection}{\protect\numberline{}Debugging research process}
 \label{sec:DebuggingResearchProcess}
-Throughout the development of specific parts of the program, certain areas of the program were difficult to implement due to the lack of documentation and examples available. So a debugging research process was created to help with this. The debugging research process is a rather tedious process but when conducted correctly, it can provide a lot of insight into the inner workings of the program and can help to identify and fix bugs in the program. In figure \ref{fig:DebuggingResearchProcess}, an example is shown of the debugging research process in action where undocumented runtime objects are inspected to see if they hold values of any use to the program. In cases like these useful data from undocumented libraries can be obtained through debugging during runtime or through the use of decompilers like DnSpy and the built-in Visual Studio decompiler in order to see static data and members of a library.
+Throughout the development of specific parts of the program, certain areas of the program were difficult to implement due to the lack of documentation and examples available. A debugging research process was created to help with this. The debugging research process is a rather tedious process but when conducted correctly, it can provide a lot of insight into the inner workings of the program and can help to identify and fix bugs in the program. In figure \ref{fig:DebuggingResearchProcess}, an example is shown of the debugging research process in action where undocumented runtime objects are inspected to see if they hold values of any use to the program. In cases like these useful data from undocumented libraries can be obtained through debugging during runtime or through the use of decompilers like DnSpy and the built-in Visual Studio decompiler in order to see static data and members of a library.
 
 \begin{figure}[H]
     \centering

report/Chapters/ClosingChapters/Appendices.tex

@@ -59,13 +59,6 @@ \subsection*{Additional figures}
 %     \includegraphics[width=0.5\textwidth]{Figures/YAMLSchemaCropped.png}
 % \end{figure}
 
-% \begin{figure}
-%     \centering
-%     \caption{VSIX Configuration manager}
-%     \label{fig:VSIXConfigurationManager}
-%     \includegraphics[width=0.4\textwidth]{Figures/VSIXAConfigManagerCropped.png}
-% \end{figure}
-
 % \begin{figure}
 %     \caption{Regex Token Recursive Parse}
 %     \label{fig:RegexTokenRecursiveParse}
@@ -113,6 +106,14 @@ \subsection*{Additional figures}
 }
 \end{figure}
 
+\begin{figure}
+    \vspace{-50px}
+    \centering
+    \caption{VSIX Configuration manager}
+    \label{fig:VSIXConfigurationManager}
+    \includegraphics[width=0.8\textwidth]{Figures/VSIXAConfigManagerCropped.png}
+\end{figure}
+
 \begin{figure}[htp]
     % \vspace{-50px}
     \centering

report/Chapters/ClosingChapters/Appendices_Figures.tex

@@ -7,9 +7,9 @@
 % What would I do differently next time?
 % How could the project be taken further?
 \subsection{Summary}
-From the research conducted and the results that were obtained, it can be seen that the project has been successful in achieving the goals that were set out. The project has been able to create a tool that can restructure source code in a way that is easy to use and can be integrated into a user's workflow. The tool has been designed to be fast and efficient, and can be run in a variety of ways to suit the user's needs. The tool has been tested and evaluated, and has been found to perform well in a variety of scenarios. The project has also been able to demonstrate the benefits of using a tool like this, and has shown that it can save time and improve the quality of code. With more time and resources further benefits and efficiencies may have been achievable but given the constraints, the project has been a success and has achieved the goals that were set at the outset.
+From the research conducted and the results that were obtained, it can be seen that the project has been successful in achieving the goals that were set out. The project has been able to create a tool that can restructure source code in a way that is easy to use and can be integrated into a user's workflow. The tool has been designed to be fast and efficient, and can be run in a variety of ways to suit the user's needs. The tool has been tested and evaluated, and has been found to perform well in a variety of scenarios. The project has also been able to demonstrate the benefits of using a tool like this, and has shown that it can save time and improve the quality of code. With more time and resources further benefits and efficiencies may have been achievable but given the constraints, the project has been a success and has achieved the goals that were set at the outset. It also provides a basis for further development and enhancements if desired.
 
 \subsection{Conclusion}
-The project has been a valuable learning experience, and has provided a good opportunity to develop new skills and knowledge. A better understanding of the principles and patterns of object oriented programming as been gained and provided the opportunity to put these into practice. The project has also allowed the development of skills in software development, and has given me the opportunity to work on a real-world project. While challenging at times, it has been rewarding and has provided a sense of accomplishment, and has been a positive experience.
+The project has been a valuable learning experience, and has provided a good opportunity to develop new skills and knowledge. A better understanding of the principles and patterns of object oriented programming as been gained and provided the opportunity to put these into practice. The project has also allowed the development of skills in software development, and has provided me the opportunity to work on a real-world project. While challenging at times, it has been rewarding and has provided a sense of accomplishment, and has been a positive experience.
 
-In the future with more time the aim would be to continue working on the project, to further develop the tool and add new features and functionality. A primary goal I would like to achieve for this tool is to make it multi-language compatible, as this would greatly increase the usefulness of the tool and make it more accessible to a wider range of users. Ideas of how such a change could be implemented is to provide a language schema in the configuration that would then be used to parse to source code into a universal AST that could then be used to restructure the code. This would also allow for a much more flexible tool that could be used on multiple languages and platforms, as currently the tool is limited to only working with C\# code via the MSBuild pipeline which is limited to the Windows platform. The integration of a custom intermediatory AST parser would allow for the tool to be used on any platform and with any language. However, these are all developments that would enhance the tool created and this is only possible as the project has demonstrated that the use of a properly developed tool does allow for creating software quality and reformatting source code, which has been achievable here on the constrained project. It is exciting to see this succeed and know how this could further be improved.
+In the future with more time the aim would be to continue working on the project, to further develop the tool and add new features and functionality. The primary goal that would be desireable wold be for this tool is to make it multi-language compatible, as this would greatly increase the usefulness of the tool and make it more accessible to a wider range of users. An idea of how such a change could be implemented would be to provide a language schema in the configuration that would then be used to parse to source code into a universal AST that could then be used to restructure the code. This would also allow for a more flexible tool that could be used on multiple languages and platforms, as currently the tool is limited to only working with C\# code via the MSBuild pipeline which is limited to the Windows platform. The integration of a custom intermediatory AST parser would allow for the tool to be used on any platform and with any language. However, these are all developments that would enhance the tool created and this is only possible as the project has demonstrated that the use of a properly developed tool does allow for creating software quality and reformatting source code, which has been achieved here on the constrained project. It is exciting to see this succeed and know how this could further be improved.

report/Chapters/ClosingChapters/SummaryAndConclusion.tex

@@ -9,6 +9,6 @@ \subsection{Product evaluation}
 Throughout the development of the project, the goals that were set out to be solved have, for the most part, been completed. The basis of a tool to restructure source code had successfully been created. The program also shows that being able to easily restructure a programs source would drastically reduce the time required to format documents to a users preferences compared to if it were to be done manually.
 
 The performance of the tool runs fast enough within an integrated environment that it would not hinder the containing process or the development for the end user.
-With various ways to run the program too, the user can choose how they would like to run the program and are therefore less prone to vendor lock in.
+With various ways to run the program too, the user can choose how they would like to run the program and therefor this is less prone to vendor lock in.
 
-By limiting the scope of the project to a single language, the project was able to be completed within the time frame set out. however, this has the downside of not being able to restructure code in other languages which is a particularly large limitation of this tool given that in recent years, web-based languages such as Typescript and Javascript as well as Python for AI based tasks, have become increasingly popular, so by not making this tool multi-language compatible, it cannot be used to aid in enforcing coding standards to these other popular languages. If the project had a longer time frame and delivery period, it would've been feasible to such a feature with more resources.
+By limiting the scope of the project to a single language, the project was able to be completed within the time frame set out. however, this has the downside of not being able to restructure code in other languages which is a particularly large limitation of this tool given that in recent years, web-based languages such as Typescript and Javascript as well as Python for AI based tasks, have become increasingly popular. By not making this tool multi-language compatible, it cannot be used to aid in enforcing coding standards to these other popular languages. If the project had a longer time frame and delivery period and with more resources available it would've been feasible to incorporate such a feature with more resources.

report/Chapters/MainBody/IntegrationAndTesting/ProductEvaluation.tex

@@ -16,7 +16,7 @@ \subsubsection{Unit testing}
 % TODO: Could put these in the appendix. Say "see appendix X".
 
 For testing the code analyzers and fix providers the MSBuild testing framework was used. This framework provides the basic functionality to compile input source files, run the analyzers and fix providers on the compiled source files and then compare the generated diagnostics and fixes to expected results provided by the test.
-The work put into making this testing framework more streamlined and easier to use was a significant development in ensuring the reliability of this tool, more detailed information of the workings behind this testing framework can be found in the appendix section \ref{subsec:CustomUnitTestFileParser}.
+The work put into making this testing framework more streamlined and easier to use was a significant development in ensuring the reliability of this tool. More detailed information of the workings behind this testing framework can be found in the appendix section \ref{subsec:CustomUnitTestFileParser}.
 % This framework requires a custom format for the test data as described by the documentation on the Microsoft website. The format that the framework desires is not ideal as it produces a lot of duplicated code, so to reduce this a custom source file parser was created to drastically cut down the amount of code that was required to write the tests. In this custom source file parser, the source file can contain code and diagnostic comments. The diagnostic comments are formatted as seen in Table \ref{tab:FileParserSyntax}.
 % \begin{table}[H]
 %     \centering
@@ -126,7 +126,7 @@ \subsubsection{Unit testing}
     \end{subfigure}
 \end{figure}
 
-Of the automated tests conducted, fifty-eight were created of which fifty-five were successful. The three tests that failed were due to the line ending issue mentioned above. The tests that failed were not fixed as they were not major issues, would not affect the functionality of the tool and due to a lack of time to resolve the issue. The tests that passed were able to validate the functionality of the tool and ensure that the tool was functioning correctly and as expected. Given the success rate of 94.8\%, it can be concluded that the tool is functioning well within a passable margin of error and is ready enough for real-world use.
+Of the automated tests conducted, fifty-eight were created of which fifty-five were successful. The three tests that failed were due to the line ending issue mentioned above. The tests that failed were not fixed as they were not major issues, would not affect the functionality of the tool and also due to a lack of time to resolve the issue. The tests that passed were able to validate the functionality of the tool and ensure that the tool was functioning correctly and as expected. Given the success rate of 94.8\%, it can be concluded that the tool is functioning well within a passable margin of error and is ready enough for real-world use.
 
 \subsubsection{Integration testing}
 Using the VSIX build of the project, a plugin compatible with the Visual Studio IDE gets created. This plugin allowed for the tool to be interacted with via IDE hints. In order to examine this a test project was loaded up into Visual Studio with the plugin loaded. After compiling the project the IDE would gather diagnostics from the build tool and display them in the error list and the code editor. It can be seen that amongst the diagnostics generated, the tool has provided hints within the IDE that the user can click on to preview and apply the fix. (see figure \ref{fig:IDEHints}).
@@ -141,7 +141,7 @@ \subsubsection{Integration testing}
 \end{figure}
 
 \subsubsection{Standalone testing}
-The standalone package was built to provide a way to run the tool without the need for the Visual Studio IDE. The standalone program is simplistic and takes a C\# solution file from which the analysis can be run on. Any files that can have fixes applied will be displayed in a graphical window with a file differential view. To validate the results of the standalone tool, checks were made to ensure that it doesn't get stuck in a read-eval loop, which did occur during development. In addition to this, the output files were visually inspected to check that the fixes were applied correctly (see figure \ref{fig:StandaloneTool}). Additional, less significant, tests were conducted for the standalone tool which can be read about in the appendix section \ref{sec:StandaloneToolTests}.
+The standalone package was built to provide a way to run the tool without the need for the Visual Studio IDE. The standalone program is simplistic and takes a C\# solution file from which the analysis can be run on. Any files that can have fixes applied will be displayed in a graphical window with a file differential view. To validate the results of the standalone tool, checks were made to ensure that it doesn't get stuck in a read-eval loop, which did occur during development. In addition to this, the output files were visually inspected to check that the fixes were applied correctly (see figure \ref{fig:StandaloneTool}). Less significant tests were also conducted for the standalone tool which can be read about in the appendix section \ref{sec:StandaloneToolTests}.
 
 \begin{figure}[H]
     \centering