El sábado, 25 de abril de 2015, 8:21:42 (UTC-5), Scott Jones escribió: > > Yes - I think there are a lot of overshort names in some of the Julia > packages/modules... for example, why is it readdlm, and not read_delim? >
I completely agree that readdlm is a particularly bad offender in the readability contest. +1 for read_delim > > On Saturday, April 25, 2015 at 9:14:12 AM UTC-4, Tracy Wadleigh wrote: >> >> I too like underscores. The thing that bugs me is that they aren't always >> used. I'm not a fan of conventions that involve judgment calls without an >> especially compelling reason. >> >> On Sat, Apr 25, 2015, 9:07 AM Scott Jones <[email protected]> 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? >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>
