Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Naming of flag macros #8

Closed
knuesel opened this issue Jul 7, 2021 · 3 comments
Closed

Naming of flag macros #8

knuesel opened this issue Jul 7, 2021 · 3 comments

Comments

@knuesel
Copy link

knuesel commented Jul 7, 2021

How would you feel about longer names for the macro flags?

Code using DataFramesMacros is typically super readable: I think even people unfamiliar with the package can easily guess what the code is supposed to do... except for these cryptic one-letter flags! I would personally prefer @bycol, @byrow, @passmissing and @astable (or @AsTable).

It's of course more verbose but isn't it worth it for readability?

Also it would mean passing multiple flags as separate macros, e.g. @bycol @passmissing instead of @cm. But I find the readability improvement even higher in this case.

Note I'm not suggesting to have both long and short names because I find such fragmentation even worse for readability.

(I thought it would be interesting to discuss this before it's set in stone, but feel free to close this issue!)

@jkrumbiegel
Copy link
Owner

Thanks for the suggestion, although I deliberately chose these short versions because there are only four letters (currently) and they can only appear in one place, so if one learns to use the package, there is not that much overhead. My personal preference tends towards as-short-as-is-reasonable. It's true that they are not self-explanatory, but that's also a relatively high bar for code.

@knuesel
Copy link
Author

knuesel commented Jul 12, 2021

OK no problem, thanks for answering!

@jkrumbiegel
Copy link
Owner

After using the system for a while I started to dislike the short macros. Just not readable enough, so I'm reverting in #24 to the explicit versions as you suggested last year.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants