Mirror of forum.nim-lang.org

4770 :: Why Nim so inconsistent?

• alexeypetrushin (orginal) [2019-04-05T22:39:24+02:00] view original

  Just checked out Nim, lots of things and design decision that I like about the language.

  But I noticed that there are some inconsistencies with how things are named, example: function names tolower vs toSeq or types string vs Natural - really weird. Why in some cases they start with capital letter and in another not and also sometimes they camel cased and sometimes flat?

---

• Araq (orginal) [2019-04-05T23:23:19+02:00] view original

  It is written toLower, see https://nim-lang.org/docs/theindex.html#toLower

  The type names all follow capitalization except for the really common one we found to annoying to type this way. They also predate our style guide, https://nim-lang.org/docs/nep1.html

---

• alexeypetrushin (orginal) [2019-04-06T00:46:05+02:00] view original

  Thanks, I saw tolower in some nim word count demo, maybe it was outdated.

  Can you please also explain about the types, is there any convention to its naming string vs Natural - why one is lowercased and another is not?

---

• kaushalmodi (orginal) [2019-04-06T01:22:44+02:00] view original

  @alexeypetrushin tolower would work too as Nim is case sensitive only with the starting letter. So using either toLower or tolower would work. But ToLower would be different.

  Though, it's suggested to follow lower camelcase in general.

---

• cdunn2001 (orginal) [2019-04-06T17:29:36+02:00] view original

  Also note the command-line utility, nimpretty, which will not fix upper/lower case but will at least make your indentation consistent, similar to gofmt.

---

• Libman (orginal) [2019-04-07T20:41:15+02:00] view original

  I think encouraging the use of nimpretty and extending its features could subdue a lot of criticism currently directed at Nim. It can even have options for consistency in things like:

  • Identifier casing / underscore style.
  • Forcing explicit module prefixes (probably the biggest issue for some people).
  • Function calling conventions (UFCS, optional parenthesis, named arguments, etc)
  • Use of let / var blocks vs repeating on multiple consecutive lines.
  • Use of comment blocks vs repeating on multiple consecutive lines.
  • Block #end``ings (that some silly people prefer). * One ``import line vs many.
  • Etc, etc, etc.

---

• arnetheduck (orginal) [2019-04-10T18:02:22+02:00] view original

  Human beings write code.

  YMMV, but most devs I know read a lot more code than they write - their own and others' - optimizing for human reading seems like a reasonable priority then, if you're trying to save time.. it compounds too - if a dev is able to read somebody else's code, they might not have to write any code at all :)

---

• yglukhov (orginal) [2019-04-10T18:17:56+02:00] view original

  Let me question Java/Go/Nim readability... What is more readable?

  
  addConstraint(x.plus(y).lessThanOrEqual(x.times(newConst(5).plus(z))
  Run

  or

  
  addConstraint(x + t <= x * (5 + z))
  Run

  I would say, if you want to write readable code nim gives you means to do so. If you want to write unreadable code, no language shall prevent you from doing that.

---