LOGAN: Log File Analysis in International Large-Scale Assessments

Style guide

The following is an adaptation of Google's R Style Guide, and is written here to motivate good writing practices for all package contributors. Following the guidelines below will help make LOGAN's source code easier to read, share and verify.

It is important to notice the correct letter case used in the guidelines below. The Windows Operating System may not differentiate between lowecase and uppercase letters, but other OSs such as GNU/Linux and MacOS (not to mention the R language itself) do, so a file called "A.R" is different from another called "a.r".

Files containing R code should end in .R.
Function names should have Pascal case, e.g. FunctionName.
Other object names (function arguments, variables, constants, etc.) should have lowercase names with dots for spaces, e.g. variable.name.

Lines of code should have no more than 80 characters per column. If one line of your code is taking longer than that, it would probably me more readable if it is broken into multiple lines.
Indentation should be made with two spaces, no tabs.
The opening brace should be on the same line; the closing brace should be in its own line.

For example, instead of this:

if (x == 1)
{
    print(x)
}

write this:

if (x == 1) {
    print(x)
}

The exception is the else statement, which should occupy the same line as the closing brace of the previous if statement, like this:

if (x == 1) {
    print(x)
} else {
    print("not one")       
}

Assignments should be made with <-, not =.
Don't use ; or attach.
All binary operators (=, ==, +, !=, <-, etc.) must have spaces before and after. There is no space after an opening parenthesis or before a closing parenthesis.
Never place a space before a comma.
Always place a space after a comma.

Inline comments need at least one space before the #. All comments need one space after #.
Any persisting # TODO: comment should be written in the README.md file under Section Planned features.
When commenting, remember to favor explaqining the "why", not the "how".

git guidelines

In order to avoid unnecessary merging conflicts and keep our work as organized as possible, please follow the instructions below:

Do not commit to master if the package does not pass all devtools tests---run devtools::test() and check if all results fall under the "OK" category---and the output of devtools::check() is perfect (i.e., no errors, warnings or notes).
Create one different branch for each new feature you're working on.
Commit and push often, but don't commit unfinished (e.g. broken) code.
Only change the package version on master. However, changing build version numbers in other branches is useful and allowed to make sure that what you are seeing relates to the latest build. Use it as a last resource, and consider simply discarding the change to the package version before merging back to master.
Keep your local clone up-to-date as often as possible by pulling from origin.

General guidelines

Credit attribution will be given according to ?utils::person.
Version numbers should follow Semantic Versioning 2.0.0 guidelines, using only numbers separated by periods. Version number appendices like "-beta" are highly discouraged, since they can easily disrupt workflow. When submitting versions to external repositories for approval (e.g., CRAN), the version number stated in the DESCRIPTION file should be fixed. However, for internal control, tags can be created for each release candidate, i.e., for each submission related to the same software version. For example, all attempts of releasing LOGAN 1.0.0 on CRAN had "1.0.0" as the version number in the DESCRIPTION file, but tags were created on git as "1.0.0-rc1", "1.0.0-rc2", etc., to mark the commits that were actually sent to CRAN on each attempt.