JerrZzzz
commented
8 months ago You are absolutely right on the content part. but make sure adding new page is \newpage not /newpage. 😄
Thanks a lot on all those ideas. They are really helpful.
Do you think that I should filter property type to private which will be much closer to my topic here?
I will try get rid of outliers. I will try get rid of 1 % each side of percentile.
The peer review of paper 1 is all based on the "What to look for in a code review" in Google. 2022. “What to Look for in a Code Review.” Google Engineering Practices Documentation. https://google.github.io/eng-practices/review/reviewer/looking-for.html.
1.Functionality: After loading the all required packages of in this paper: opendatatoronto, knitr, janitor, tidyverse, lubridate, ggplot2, dplyr, readr and all datasets of selected_data. The R displayed that all the codes can run compeletely and successfully without gaps. 2.Complexity: Regarding the complexity of the code, I think it is moderate, suitable for reading and reproducible. There is no overly complicated code in the three R files in the Output/Paper/BuildingScoreAnalyze-2023.qmd and script folders, and most of them are easy to understand. 3.Tests： CL are correct, sensible, and useful. When I missed certain codes, the all codes are not work. 4.Naming: I think the title of the entire report is very, very conclusive. In the Abstract, I suggest describing the research results in this report, which can increase the appeal to readers. The segment names for each part are very reasonable. 5.Comments： The report writer uses "###" and concise English at the beginning of each code to explain the meaning of each code and its necessity. 6.Style： All report is written by the R-style without any other style of code writings. 7.Consistency: The author's code is consistent with authoritative guidance. 8.Documentation: If you adopt the suggestions of this peer review, please remember to update the associated documentation, including READMEs, and any generated reference docs, which will statisfy the documentation of the whole report. 9.Every Line： I checked all the folders of this submission in order and made sure that contents such as data and literature were correct and reproducible. The README file also clearly indicates the description of llms and the description of each folder. 10.Exceptions： I am the checker for this report in this submission and I have checked each file in each folder. 11.Context: First, the text description and code writing of the entire report make sense. In the "Discussion" section, the author mentioned outlier, that is, there will be some unexpected data in a data, which is possible but unreasonable. I suggest that this kind of situation be carefully removed from the analysis report. I believe it will reduce unnecessary errors. I think the "Conclusion" description part can be put into the "Discussion" part and add /newpage after it to place the reference part on a new page. Such an operation will make the entire report more formatted. Besides, the colors of the graph can be more colorful to get more concentration and attraction from viewers. In addition, I suggest that the author can add a website link in llms file to make the all chats with Chat-gpt 4.0 avaliable. 12.Good Things: The text description of each part of this article is very summarized. For example, in the Introduction section, the author not only describes what this article mainly talks about, but also describes what this research specifically does, why and how it is done, etc. For the code part, the function of the code is marked at the beginning of each code to show the necessity. This is very convenient for reviewers because they can clearly see what each line of code does. The charting is very rigorous, mainly reflected in the selection of data and the design of lines, which gives readers a clear illustration to better understand the information. The text and pictures support each other, and the structure is very commendable.