gui

2018/9/23 Assignment 1.1 – CS 242 – Illinois Wiki https://wiki.illinois.edu/wiki/display/cs242/Assignment+1.1 1/7 页面 /  Home /  Assignments 由 Triphol “Pao” Nilkuha (admin)创建, 最终由 Kim, Yongjin修改于 九月 21, 2018 Assignment 1.1 Assignment 1.1 ­ Extending Your Chess Library Overview This week, we will be focusing on refactoring your code from last week, adding good documentation, and also extending your library by adding two custom pieces and the controller component of MVC. Refactoring your library code and adding good documentation now ­ and throughout the assignment 1.X ­ will allow for easier and more efficient development in the coming weeks. By the end of the week, you should have a clean, easy­to­understand, and extensible library. For this assignment, you are required to use either Eclipse or IntelliJ IDEA. Both are free and have powerful refactoring tools available. Read this entire page before beginning your assignment, and post on Piazza if anything is still unclear. Part I: Refactoring & Polishing Test Suite Read here and here for further discussion about this topic. You spent Assignment 1.0 making it work, now you will: Refactor your code to make it right. Make it faster by using proper data structures. Before you begin refactoring, consider your test suite from Assignment 1.0. Did your moderator, the TAs, or your peers from discussion section suggest ways to improve the coverage of your test suite? Yes, yes you should have written your tests before implementing your functionality last week, but if for whatever reason, your test suite could be more thorough, spend some time enriching your test suite before you begin refactoring. Doing so will help you refactor more quickly, and to be more confident in the correctness of your refactorings. If you have not already done so, consider using a code coverage tool such as EclEmma for Eclipse, or the integrated code coverage features in IntelliJ IDEA to quantify how thorough your test suite truly is. You should refactor your code to eliminate any code smells (e.g. use communicative naming, decompose larger methods into smaller separate methods, etc), add missing tests, or other problems discussed in section. Part II: Auto­generate Documentation Next, use Doxygen to auto­generate documentation for your library. You can find pre­packaged binaries here, or run the following command on the EWS machines or other Linux distros to get the latest build of Doxygen. I will assume this is run from the root directory of your project (i.e. from Assignment1.1/): wget http://ftp.stack.nl/pub/users/dimitri/doxygen­1.8.2.linux.bin.tar.gz && tar xf doxygen­1.8.2.linux.bin.tar.gz && cp doxygen­1.8.2/bin/doxygen ./ && rm doxygen­1.8.2.linux.bin.tar.gz && rm ­rf doxygen­1.8.2 Then, to automatically configure and generate documentation for your project, simply run the following: 1. Run chmod a+rx doxygen && ./doxygen ­g  2. Modify Doxyfile line 688, and change RECURSIVE from NO to YES  3. Run ./doxygen Doxyfile If you have followed the instructions properly, your project directory should now contain autogenerated HTML & latex found under html and latex. Take a look at html/index.html in a browser to check it out! This part should be relativelystraightforward,and is intended to encourage you to expand on the documentation of your public methods and classes. Imagine you are handing this library to another developer, and that the PDF or HTML generated by Doxygen will be this programmer’s first contact with your library. Are there any thinly documented areas of the code? It should be more obvious using Doxygen which areas could use further explanation. If you do see these areas, expand on your documentation, and run Doxygen again to regenerate your documentation.