Curtis Vogt

I think this looks reasonable: ```julia p.project && t.julia < v"1.2" && @warn begin "Tests: The project option is set to create a project (supported in Julia 1.2 and later)...

I would say I find the former easier to read. It's definitely worth calling out this [style guide provides guidelines and not rules](https://github.com/invenia/BlueStyle#a-word-on-consistency).

I agree with the suggestions made here. I'd also suggest one module definition per file.

If I recall correctly the original reason 92 was chosen was because it is the [line length limit specified by the Julia contribution guide](https://github.com/JuliaLang/julia/blob/master/CONTRIBUTING.md#general-formatting-guidelines-for-julia-code-contributions).

I think multiple assignments from a single call is okay (unpacking): ```julia a, b, c = f() ``` but multiple assignments from multiple calls should probably be avoided.

I'll open an issue in the BlueStyle repo. It's not explicitly called out but there are a few examples in the style of: ```julia arr = [ 1, 2, 3,...

My preference is to not use the semi-colon. You are correct in that the rule is more straight forward with always including the semi-colon but the only case it's required...

I'm just going to throw out some alternate suggestions. First off I think some of the annoyances with breaking up exception messages over multiple lines is that it's easy to...

I'll mention that there is now a MultilineStrings.jl package that makes it easier to write a single-line string with the multi-line syntax: ```julia julia> m""" Whoa there. Things aren't all...

The counter argument to this proposal is that having an exception for literal strings makes it harder to read error messages. Adding an exemption also means that people won't care...