Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CamelCase vs underscores: Scientific showdown (2011)

whatheco.de

Post reply on HN
Print view View original

61–70 of 138 posts

Re: CamelCase vs underscores: Scientific showdown (2011)

#61

Post by ReleaseCandidat »

rileymat2 wrote: post #22
delichon wrote: post #15

Earlier quoted context omitted.

So that the compiler or interpreter knows the extent of the variable token. Without spaces allowed you would need some other way to tell it where they start and end, like quotes or a special declaration, which would be harder for the brain to parse. If you know a better way please share it.

I am not picturing why this is true, if you cannot use key words as parts of variables (alone separated by a space) and lines end with a newline or semicolon (some symbol) The first restriction might make this a problem. I am not saying it is a good idea, but it is not obvious to me.

You can parse the whole expression / statement and decide what it is.

You have to be careful with infix operators, but there is always Haskell's solution of adding backticks for infix names.

So add(a, b) is the same as a `add` b

But without joking, a _real_ solution to infix operator names would be a backslash as prefix, as pseudo-Latex-style, so a \add b

Re: CamelCase vs underscores: Scientific showdown (2011)

#62

Post by ChrisMarshallNY »

jrpelkonen wrote: post #23
ChrisMarshallNY wrote: post #18

I use both. Depends on the context. In Swift (where I spend most of my time), it's CamelCase, or, quite often, dromedaryCase.

I’ve never heard of dromedaryCase. It has always been PascalCase vs camelCase in my circles. TIL

It's a joke. I made it up.

Probably not a good idea to propagate it.

;)

I think that there is an official name for lowercase-prefixed CamelCase, but I don't remember it.

Re: CamelCase vs underscores: Scientific showdown (2011)

#64

Post by ReleaseCandidat »

cletus wrote: post #35

I'm firmly in the camp that doesn't care what the rule/style is, I just want an unambiguous rule. I'll just use whatever the language conventions are. Snake case in Java, for example, would be a hate crime. So would camel case in C. My general preferences beyond that are: - Opening braces on the same line (I see the article has examples where it's on a new line); - Two space indent, no tabs - No trailing white space.…

> Don't put the return type on a separate line.

Generally yes, but stuff like

   ReturnType, T>>, U, HmmLetsAdd>
can be on a line of its own.

Re: CamelCase vs underscores: Scientific showdown (2011)

#65

Post by me_me_me »

cletus wrote: post #35

I'm firmly in the camp that doesn't care what the rule/style is, I just want an unambiguous rule. I'll just use whatever the language conventions are. Snake case in Java, for example, would be a hate crime. So would camel case in C. My general preferences beyond that are: - Opening braces on the same line (I see the article has examples where it's on a new line); - Two space indent, no tabs - No trailing white space.…

Very reasonable but, changing func name for sake of code style sounds like a step too far.

Also

(i = i ; i Whoever does that do not change it, they are probably a psychopath. Dont risk your life correcting them.

Re: CamelCase vs underscores: Scientific showdown (2011)

#66

Post by ReleaseCandidat »

ChrisMarshallNY wrote: post #62
jrpelkonen wrote: post #23

Earlier quoted context omitted.

I’ve never heard of dromedaryCase. It has always been PascalCase vs camelCase in my circles. TIL

It's a joke. I made it up. Probably not a good idea to propagate it. ;) I think that there is an official name for lowercase-prefixed CamelCase, but I don't remember it.

That's camelCase. Uppercase would be PascalCase.

Re: CamelCase vs underscores: Scientific showdown (2011)

#68

Post by ssousa666 »

my favorite thing about camelCase is that class instances are (typically) named and cased as the inverse of their pascal-cased class.

val somethingRepository = SomethingRepository()

Is much more visually satisfying and balanced to me than:

something_repository = SomethingRepository()

Re: CamelCase vs underscores: Scientific showdown (2011)

#69

Post by ChrisMarshallNY »

ReleaseCandidat wrote: post #66
ChrisMarshallNY wrote: post #62

Earlier quoted context omitted.

It's a joke. I made it up. Probably not a good idea to propagate it. ;) I think that there is an official name for lowercase-prefixed CamelCase, but I don't remember it.

That's camelCase. Uppercase would be PascalCase.

TIL.

Thanks!

Re: CamelCase vs underscores: Scientific showdown (2011)

#70

Post by ReleaseCandidat »

ivan_gammel wrote: post #39
xmcqdpt2 wrote: post #24

Earlier quoted context omitted.

In languages without infix function calls, that should be possible, but I'm not sure how readable it would be. var initial factory = abstract configuration factory factory. configure new factory()

var search result = users. find all by name (name); if (search result. is present()) { return ok(search result. get()); } else return not found(); It’s weird and syntax highlighting is absolutely necessary to read this.

Using something else than a dot is better, same as using a slightly different syntax:

   search result := users @ find all by name (name)

   if search result @ is present() { 
      return ok(search result @ get())
   } else {
     return not found()
   }
Post reply on HN