friendly / VCDR

Visualizing categorical data with R
0 stars 0 forks source link

General style format #20

Closed philchalmers closed 9 years ago

philchalmers commented 9 years ago

I'll leave this issue open for a while as it pertains to global stylistic issues which I'm unsure about. For example:

Sorry if these seem really low level (I'm sure I'll think of other nuance style issues as well) but I think it's important to keep things consistent. Cheers.

davidjohannesmeyer commented 9 years ago

Hi Phil,

I vote yes whenever you did.

Best David

Am 12.03.2015 um 23:04 schrieb Phil Chalmers notifications@github.com:

I'll leave this issue open for a while as it pertains to global stylistic issues which I'm unsure about. For example:

the use of : is often separated with spaces, e.g., 1 : 4, but is not done so consistently (mostly this way in code blocks, but not in text). Should there be a rule used here, like in-text use should always remove spaces (1:4) but in code chunks keeps spaces? I vote yes, because using 1 : 4 in text can break across lines or have weird LaTeX space stretching issues that look bad

in R chunks, should there be spaces around the matched arguments? I vote yes because they are generally more readable, but it's inconsistent across examples (e.g., type='poisson'versus type = 'poisson' .... I like the latter, but am not opposed to the former; just looking for consistency)

starting in chapter 3, there were a number of undefined acronyms in use that weren't defined (e.g., OLS, ML, LS, WLS, GOF, etc). Is this deliberate because these terms are being added to an index somewhere? Even at that, I think it's nice to include the definition in-text as they come up

em dashes (---) have difference spaces around them. Sometimes I see--- the dashes like this, other times---though a little more rarely---I see them like this, and even--- though less often still ---like this with spaces in different places. Any preferred method here? I'm partial to never having spaces, because it's easier to remember

Sorry if these seem really low level (I'm sure I'll think of other nuance style issues as well) but I think it's important to keep things consistent. Cheers.

— Reply to this email directly or view it on GitHub.

friendly commented 9 years ago

I agree with nearly all of these as desirable consistencies---even for em dashes that should not have spaces. In code chunks, spaces around the = in matched args are desireable, but maybe not in nested ones, i.e gpar = list(x=2, y=3, font=1)

friendly commented 9 years ago

PC and DM edits close this issue (not done yet in Ch 11)