Adopt Julia Style

[klensink]

I think it would be a good idea to start following Julia's style conventions moving forward. We could slowly go back and change things that are already in place until we catch up.

I've quoted some sections of Julia's style guide for things that stand out to me:

1. Camel Casing
   All of Julia's Base (and the vast majority of all packages) follow a particular style, so it might be difficult for users to adopt the package if we use a different style.

• modules and type names use capitalization and camel case: module SparseArrays, struct UnitRange.
• functions are lowercase (maximum(), convert()) and, when readable, with multiple words squashed together (isequal(), haskey()). When necessary, use underscores as word separators. Underscores are also used to indicate a combination of concepts (remotecall_fetch() as a more efficient implementation of fetch(remotecall(...))) or as modifiers (sum_kbn()).
• conciseness is valued, but avoid abbreviation (indexin() rather than indxin()) as it becomes difficult to remember whether and how particular words are abbreviated.

2. Re-naming Outer Constructors
   function getAffineScalingLayer(TYPE::Type, nData) return AffineScalingLayer{TYPE}(nData) end
   Should be:

AffineScalingLayer(TYPE::type, nData) = AffineScalingLayer{TYPE}(nData)

3. Unnecessary Static Type Parameters

A function signature:
foo(x::T) where {T<:Real} = ...
should be written as:
foo(x::Real) = ...

or foo(x::Array{T, 2}) where {T<:Number} should be written as foo(x::Array{<:Number, 2}) if T is not used elsewhere.

[eldadHaber]

I hate underscores!

…

On Jan 23, 2018, at 4:58 PM, Keegan Lensink ***@***.***> wrote: I think it would be a good idea to start following Julia's style conventions moving forward. We could slowly go back and change things that are already in place until we catch up. I've quoted some sections of Julia's style guide for things that stand out to me: Camel Casing All of Julia's Base (and the vast majority of all packages) follow a particular style, so it might be difficult for users to adopt the package if we use a different style. modules and type names use capitalization and camel case: module SparseArrays, struct UnitRange. functions are lowercase (maximum(), convert()) and, when readable, with multiple words squashed together (isequal(), haskey()). When necessary, use underscores as word separators. Underscores are also used to indicate a combination of concepts (remotecall_fetch() as a more efficient implementation of fetch(remotecall(...))) or as modifiers (sum_kbn()). conciseness is valued, but avoid abbreviation (indexin() rather than indxin()) as it becomes difficult to remember whether and how particular words are abbreviated. Re-naming Outer Constructors function getAffineScalingLayer(TYPE::Type, nData) return AffineScalingLayer{TYPE}(nData) end Should be: AffineScalingLayer(TYPE::type, nData) = AffineScalingLayer{TYPE}(nData) Unnecessary Static Type Parameters A function signature: foo(x::T) where {T<:Real} = ... should be written as: foo(x::Real) = ... or foo(x::Array{T, 2}) where {T<:Number} should be written as foo(x::Array{<:Number, 2}) if T is not used elsewhere. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[lruthotto]

I'd put changing the style on low priority. let's focus on performance first.

[klensink]

I agree that it is a low priority, but I just wanted to bring it up because keeping it in mind going forward will reduce the amount of changes we'll need to make later.