To begin with, their file structure is simple and well-organized. All the members have their own branches, which are also allocated according to their tasks. In contrast, their are only limited number of code files in their master. However, these code are explicit and useful. This structure represents well the core idea of “master branch”, the final and functional code.
The following part is respective review on their files in master branch and some comments.
README.md
Their readme file is really function. It explains clearly about their file structure and provides links of their different part of work. Meanwhile, as the core of readme file, they explains their idea and principal design about the project they are working on. Furthermore, they also list the source of data used in their project. This gives tester a better and easier way to evaluate their work precisely and sufficiently.
SCC.log
It worths our mimic that they provide this file on mater branch, because this file could give an overall picture on what is working and what is not to every team member, and thus they can modify the corresponding module soon.
datadownload.py
They are really good at commenting. For every variable they use and every lines of code that is might be strange to others, they provide specific comments to explain the purpose and function of their code very well. And they use space very well so that their code are divided into parts. In a word, their work makes code readable and explicit.
In my scope of knowledge, every attempts involving input and output stream are supposed to code in a try-and-except structure for all the unexpected problem in file reading and writing, which is unfortunately missed in their data download.
process.py
On the one hand, they are good at the following items. They completely avoid the problem of “bad names", because all the names of variables can clearly explain the purpose and meaning of them. Due to the reason that their codes are written in python, they utilize whitespace very well to establish their code structure, which makes code easy to understand. Last but not the least, they are also really good at commenting, they not only make comments on some lines of code, they also explain the propose and potential output of the functions they defines.
On the other hand, however, they sometimes failed to avoid the “magic number” problems, and thus some number they use are hard to understand. And they all use print( ) to output results. However, I think they can use other stdout method to output their result to error log and other log so that they can review they work of their code better.
trainsample.py
It’s another great presentation of their wonderful habit in making comments for commands, variables, and also functions they define.
However, they used some global variables in this file, which is supposed to avoid in the instruction.
All the comments in this review are based on the instruction in http://web.mit.edu/6.005/www/fa15/classes/04-code-review/
To begin with, their file structure is simple and well-organized. All the members have their own branches, which are also allocated according to their tasks. In contrast, their are only limited number of code files in their master. However, these code are explicit and useful. This structure represents well the core idea of “master branch”, the final and functional code.
The following part is respective review on their files in master branch and some comments.
README.md Their readme file is really function. It explains clearly about their file structure and provides links of their different part of work. Meanwhile, as the core of readme file, they explains their idea and principal design about the project they are working on. Furthermore, they also list the source of data used in their project. This gives tester a better and easier way to evaluate their work precisely and sufficiently.
SCC.log It worths our mimic that they provide this file on mater branch, because this file could give an overall picture on what is working and what is not to every team member, and thus they can modify the corresponding module soon.
datadownload.py They are really good at commenting. For every variable they use and every lines of code that is might be strange to others, they provide specific comments to explain the purpose and function of their code very well. And they use space very well so that their code are divided into parts. In a word, their work makes code readable and explicit.
In my scope of knowledge, every attempts involving input and output stream are supposed to code in a try-and-except structure for all the unexpected problem in file reading and writing, which is unfortunately missed in their data download.
process.py On the one hand, they are good at the following items. They completely avoid the problem of “bad names", because all the names of variables can clearly explain the purpose and meaning of them. Due to the reason that their codes are written in python, they utilize whitespace very well to establish their code structure, which makes code easy to understand. Last but not the least, they are also really good at commenting, they not only make comments on some lines of code, they also explain the propose and potential output of the functions they defines.
On the other hand, however, they sometimes failed to avoid the “magic number” problems, and thus some number they use are hard to understand. And they all use print( ) to output results. However, I think they can use other stdout method to output their result to error log and other log so that they can review they work of their code better.
trainsample.py It’s another great presentation of their wonderful habit in making comments for commands, variables, and also functions they define.
However, they used some global variables in this file, which is supposed to avoid in the instruction.