Code Conventions and Versioning about easystats HOT 6 CLOSED

Importing other packages

• No full import, only selective import of functions
• Use base-R wherever possible (reduce dependencies)

Helper-functions

• Own re-implementation of helper-functions, if it's not too much effort (e.g. I typically use own functions to check if a string starts / ends with a pattern, or if an object (list, data frame) contains an element with a given name (like tibble::has_name()), to reduce dependencies.

Function names

• lower case, underscore separated if more than one verb

Argument names

• lower case, underscore separated if more than one verb

from easystats.

I would opt for the underscore separation both for functions and arguments... Also working with other langs such as python or julia, this dot separator thing in R always felt a bit weird to me :)

For the rest, sounds perfect!

from easystats.

What about versioning? I almost never use different branches and have not much experience with this. I think this is something I should start learning and applying for the projects / packages we plan. Or should we work with pull requests, or both? What is better in which situation?

from easystats.

I had many tentatives working with branches, more or less successful ^^, including a feature-based workflow and a dev-branch workflow, and had better results with the second. Basically, the idea would be to have a maste, and a dev branch to which we upload our commits (the dev is our working branch), and from time to time we merge dev into master, updating the version number

from easystats.

Ok, let's try it with dev-branches.

from easystats.

I updated accoding to easystats/parameters#44

from easystats.