Style fixes

[kescobo]

You didn't ask for this, but I thought I'd throw it out there anyway. I am 100% fine with closing this because the effort/reward ratio for reviewing is too high (or for any other reason).

This PR does not add or change any functionality, it just fixes some inconsistent style things that came up in #2447. I tried to keep the following things separate, so if any of them are not desired, I should be able to cut them out.

1. The biggest thing is spaces after commas, which I accomplished primarily using regex find-and-replace in VS-Code (there were nearly 3000 instances). Specifically, I did ,([^\s)]) => , $1. I initially searched for ,\S, but there were a bunch of instances of 1-element tuples that I assumed should not be changed (that is, I wanted to leave (a='b',) alone).
   1. There were a few file exceptions to global find-and replace: iris.csv (for obvious reasons); test/dataframerow.jl due to a couple of @sprint lines that seemed like they shouldn't be changed - I went in and changed some other stuff in this file manually; test/io.jl that had a bunch of output stuff that I didn't want to mess with.
   2. In test/grouping.jl, there were a couple of examples of spaces before commas that I removed (I only noticed them because there were also no spaces after the commas)
   3. A few lines in test/cat.jl with error messages were inconsistent, I tried to unify
   4. I tried to scan through everything else, but it's definitely possible I missed something. I tested locally, but I'm still getting a segfault - I'll fix anything that pops up in CI
2. A few instaces of optional arguments in docstrings, I tried to unify the style here with julia itself (that is, do function(arg1 [, optional_arg1 [, optional_arg2]]
3. Zeros after decimal for floats - I used regex to search, but couldn't sort out a good find-replace, so I just scanned through the results for \d\.\D and fixed them manually

[bkamins]

This is much appreciated. We will review and merge this when things listed in #2484 are done.

The issue is that complex PRs (as mentioned there) take hundreds of lines and such PR as this one will lead to merge conflicts.

However, I hope you understand that we put a priority to "functionality" PRs over "clean-up" PRs. So the policy is that it is "clean-up" PRs should wait for "functionality" PRs to be merged and then rebase appropriately. If we have a proposal like this one I stall opening new significant PRs for several days to allow "clean-up"s to be merged in this "waiting period".

(I would have told you the above policy earlier if I knew you started working on this)

Are you OK with this approach (I assume that it is ~1 week to finish the relevant open PRs as there are three of them: a) multi-column return values in transforms, b) changing printing to PrettyTables.jl, c) deprecation of DataFrame constructors).

[bkamins]

(also note that probably these PRs will introduce some new style inconsistencies - feel free to fix them also then if you would be willing to do this)

[kescobo]

However, I hope you understand that we put a priority to "functionality" PRs over "clean-up" PRs. So the policy is that it is "clean-up" PRs should wait for "functionality" PRs to be merged and then rebase appropriately.

💯 understand and agree

(I would have told you the above policy earlier if I knew you started working on this)

No worries - it only took me about an 90 min to figure stuff out (and 20 min of that was because github ate my first draft of the description 😆), and I bet I could repeat the process in much less time now that I know what to look for.

Are you OK with this approach (I assume that it is ~1 week to finish the relevant open PRs as there are three of them: a) multi-column return values in transforms, b) changing printing to PrettyTables.jl, c) deprecation of DataFrame constructors).

Completely OK with it - it may be more sensible to just start from scratch at that point. Let's just leave this open for now, and then you can ping me when it would be worth taking another look (though, if it's going to be after Oct 31st and you're willing to mark this as hacktoberfest-approved, that would be appreciated 😄)

[bkamins]

Actually the key PR to finalize is the "constructor deprecation" PR (as it touches all test files). When it is merged I can tell you which test files are safe to be touched (other PRs will have a major impact but only at selected files)

[bkamins]

Actually looking at your changes - when we go back to this PR - I would split it into 3 smaller PRs:

1. spaces after ,
2. fixing signatures in docstrings
3. proper float formatting

It will be much easier to review them this way (as when reviewing you only have to check one thing when looking at diff).

[kescobo]

Makes sense to me 👍 - I'll close this now, you can ping me on slack or here when that's ready.

[bkamins]

OK