And just before that, it says this:
- Word separation can be indicated by underscores ('_'), but use of
underscores is discouraged unless the name would be hard to read otherwise
.
The documentation is not very consistent...
On Saturday, April 25, 2015 at 10:30:36 PM UTC-4, Sisyphuss wrote:
>
> I find something contradictory :
> http://docs.julialang.org/en/latest/manual/variables/#stylistic-conventions
>
> *Names of functions and macros are in lower case, without underscores.*
>
>
>
> On Saturday, April 25, 2015 at 3:07:46 PM UTC+2, Scott Jones wrote:
>>
>> Umm... the style guide for Julia says *to* use underscore for longer
>> names, *not* camelcase:
>>
>>
>> - modules and type names use capitalization and camel case:module
>> SparseMatrix, immutable UnitRange.
>> - functions are lowercase (maximum()
>>
>> <http://docs.julialang.org/en/release-0.3/stdlib/collections/#Base.maximum>
>> , convert()
>> <http://docs.julialang.org/en/release-0.3/stdlib/base/#Base.convert>)
>> and, when readable, with multiple words squashed together (isequal()
>> <http://docs.julialang.org/en/release-0.3/stdlib/base/#Base.isequal>,
>> haskey()
>>
>> <http://docs.julialang.org/en/release-0.3/stdlib/collections/#Base.haskey>).
>> When necessary, use underscores as word separators. Underscores are also
>> used to indicate a combination of concepts (remotecall_fetch()
>>
>> <http://docs.julialang.org/en/release-0.3/stdlib/parallel/#Base.remotecall_fetch>
>> as
>> a more efficient implementation of remotecall(fetch(...))) or as
>> modifiers (sum_kbn()
>> <http://docs.julialang.org/en/release-0.3/stdlib/arrays/#Base.sum_kbn>
>> ).
>> - conciseness is valued, but avoid abbreviation (indexin()
>>
>> <http://docs.julialang.org/en/release-0.3/stdlib/collections/#Base.indexin>
>> rather
>> thanindxin()) as it becomes difficult to remember whether and how
>> particular words are abbreviated.
>>
>> Personally, I think the Julia style guide gets it right... also, there
>> have even been studies that show that words separated by _ are easier to
>> read (>20% faster to read!) than words with no spaces and camel cased...
>>
>> Scott
>>
>> On Saturday, April 25, 2015 at 6:43:44 AM UTC-4, François Fayard wrote:
>>>
>>> Hi,
>>>
>>> I would like to talk about naming convention. I think it's fine to have
>>> short names in a langage with few keywords such as C (memcpy), but a
>>> langage such as Julia that wants to be also high level with a huge standard
>>> library needs convention because the langage might become very large. I
>>> find the convention used by Mathematica the best ever made. Nothing is
>>> shortened except a few exceptions and consistent use of CamlCase. On the
>>> other hand, Matlab is probably one of the worst thing that happen in terms
>>> of naming: no consistency at all! I suspect that Cleve Moler who started
>>> Matlab not used LAPACK but also the Fortran 77 naming convention which was
>>> only there only for technical reasons ;-)
>>>
>>> I've seen that the naming convention for function in Julia looks like
>>> the same as in Python: everything must be lowercase, and don't use
>>> underscore. Let's look at different naming conventions, the first one being
>>> the one used by Julia.
>>>
>>> 1) daysinmonth()
>>> 2) daysInMonth()
>>> 3) days_in_month()
>>>
>>> I find the first one the most difficult to read. I tend to prefer the
>>> last one, but the second one is also easy to read. The fact that Julia uses
>>> the first one and the fact that many names are shortened, makes reading
>>> code with functions you've never seen a pain. For instance reading a name
>>> "iso..." my mind does not understand if we at talking about a function that
>>> returns a Bool ("is" suggests that) or something that has been standardised
>>> (ISO). Using the second naming convention would make things easier. Also it
>>> would prevent people using underscores as we have in the standard library
>>> without any clear reason.
>>>
>>> I don't find any disadvantage for the second naming convention over the
>>> first one. So why do people use the first one?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
