I’ve been spending lots of time thinking about naming lately. What kind of naming scheme do you follow in your class names? How does your method names look like? Your variables? Do you use active words or passive? Should you use longer, descriptive names or shorter, more succinct? How can you best use symbolic freedom to allow better naming? What kind of names do you choose for your core classes? Does it matter or should you just go for Good ‘Ole ‘Object’?
These musings is part of my design thoughts about Ioke, and I’ll describe some of the decisions I’ve made.
I first want to start with something simple. What naming scheme do you follow for your class-like objects? I’m going to go the same way as Java here, using capitalized words. This will be a convention and not anything forced by syntax, since the class-like objects will actually not be classes since Ioke is a prototype based language.
So what about method names and variable names? First of all there is no distinction in Ioke. Everything is a message. There are several variations here that are quite common. I have opinions on all of them, of course.
- C#: A typical method might be called ‘ShouldRender’. The words are capitalized and put together without any separation characters. Most symbols aren’t allowed so method names are generally restricted to numbers, letters and underscore. This style doesn’t appeal to me at all. I find it really hard to read. That the naming convention is the same class names makes it hard to discern these names from each other. Having the words connected without any separation characters also doesn’t help.
- Java: The same as C# except that the first character is lower case: ‘shouldRender’. The same restrictions apply as for C#. I find it slightly easier to read than C#, since there is specific difference between class names and method names. But the train wreck style of putting together the words is still inconvenient.
- Ruby: With symbol freedom and small case separated by underscores, Ruby has a quite different style. The example would look like this: ‘should_render?’. The question mark is really nice to have there, and the under scores really make it easier to read. Of course, the difference between class names and method names is quite large which is both a good and bad thing.
- Lisp: Typical Lisp naming is all lower case and separated by dashes: ‘should-render?’. Lisp also has high degrees of symbolic freedom so you can use basically any character except for white space and close parenthesis in it. I like this style a lot. It’s eminently readable but the main problem is the dash. Allowing dashes in names in a language with infix operators means that you must use spaces around a minus sign which really would annoy me. So even though I like this style I don’t think it’s practical unless your language uses Lisp style notation for operator names.
- Smalltalk: This style of naming is definitely the most different. It tries to avoid words that run together by using keyword selectors. That means you interleave the arguments with the parts of the name of the method to call. For example: ‘render: “str” on: screen1’ is actually a method called ‘render:on:’. The method of naming have really nice reading benefits but there is also a high cost. Specifically, Ioke uses spaces to chain invocation, which means that if I used Smalltak style names I would need to surround all method invocations with parenthesis which won’t look good at all in this case. There are lots of good reasons for this naming but ultimately it doesn’t work.
Those are basically the naming styles I can think of right now. Everything else is mostly variations on it. So what will I use for Ioke? I don’t know exactly, but the two alternatives I’m considering right now is Ruby names and Java names + symbolic freedom. I’m leaning towards the Java naming. Adding more symbols will make it easier to use good names. Small things like question marks and exclamation marks really make a difference. Another reason for going with Java names is that it allows interacting with Java without doing name mangling (lke JRuby does). That’s highly attractive, even though the method names will be a bit more compact with this convention.
Any opinions on this?
8 Comments, Comment or Ping
I have done a lot of java dev professionally and some ruby dev as a hobbyist and my question would be :
Is name mangling that much of a problem ? if not then I would still go for the ruby scheme or at least a bastardized version of java and ruby : I definitely love having the marks at the end of the methods ( ‘?’, ‘!’, …)
maybe
foo.shouldRender? isn’t so bad ….
September 30th, 2008
I really like the Smalltalk syntax, I think it’s even a step upward from named parameters (which are an absolute must). Of course it depends on the usage in your library, but methods like:
> SomeClass.doFoo(String, String, String, int, int, File, String)
A horror. IDE support helps a bit, but it’s still a mess to write and in particular to read. Lots of bugs could be avoided by at least using named parameters. The advantage of Smalltalkian over named parameters is that you can’t mess up the order with them, so particular message sends/method calls always follow the same pattern and are thus more readable. Also I think the DSL capabilities are better when mixing parameters and blocks:
> file when: something do: [ … ] endWith: [ … ].
Or similar.
It might fit your language, or not, but I think you should absolutely consider at least named parameters. On the message send operator, in your case whitespace: Scala allows to separate message sends by whitespace, and I always found it pretty messy, in particular when the semicolon is optional.
September 30th, 2008
I work with both Java and Ruby and I don’t have any strong preference (especially with symbolic freedom added to Java style.)
One difference that I see is that with Java-like style you loose the ability to fully use the meaning of capital letters:
E.g. visitBigBen
vs visit_Big_Ben or visit_big_Ben
and can be a bit awkward with acronyms
E.g. runJVMGC, runJvmGc or runJavaVirtualMachineGarbageCollector
vs run_JVM_GC
But these are just minor things and one can of course still use run_JVM_GC in Java as a lesser evil.
September 30th, 2008
Jean:
Well, I will definitely allow symbols like ‘?’ and ‘!’. That’s what I mean with symbolic freedom.
Martin:
Totally agreed on the Smalltalk syntax. I’ve spent lots of time trying to figure out a way to get it working, but since I will use whitespace separation it just won’t work. (And I personally think it’s much cleaner with whitespace then dots).
I’m working on how the named parameters will look like. One alternative is to not have them at all – or rather just use regular code to disguise them.
In something like Foo with(name = “hello”, bar = “fuzz”)
The things that look like keyword parameters are just a code block that will be sent unevaluated to the method, and can be used in any way you want. I’m thinking about making it look like keyword parameters from the defining methods side here.
Also, Scala seems messy to me for other reasons – specifically, the fact that you mix and match spaces with dots make for a bad experience in my opinion. Ioke will only use spaces and thus this problem will not be as bad.
September 30th, 2008
Ola:
I would actually sacrifice whitespace instead of dots without thinking if I can get Smalltalkian named parameters for it, but that’s indeed a preference.
How is the sending of unevaluated blocks done? Who declares that this needs to be sent unevaluated, the called method? That seems suspicious, in particular in a language without static typing.
Also, how will you solve the resolving problem for names within that block? If the names are resolved in the context of the with() method, it will work properly for name and bar, but what if you want to use variables from the lexical scope of the call site?
E.g.
name = “Martin”
location = “Potsdam”
Person.with ( name = name, location = location ) – looks really suspicious. Policies like only binding free names etc can probably also be really confusing. What about name shadowing, i.e. if Person contains a ‘city’ cell, and we have this code:
city = find_city_by_zip(…)
Person.with ( name = city inhabitants first )
Which city are we going to get?
September 30th, 2008
Martin:
Yeah, the scoping is an interesting question. It is definitely the defined method that defines what to do with the code sent to it. Take a look at Io for an example of how this works in practice. (It’s really useful because basically all control structures can be regular methods, such as while, if, switch, and so on).
In the case of with, It’s going to be defined using a method called dualDo, which for reading first looks in the lexical scope and then in the created objects scope. For writing it writes in the created object only.
The way scoping works is actually really flexible, and it’s controlled by a scope object that can use different strategies for doing these things.
Of course, if you want to force things, you can do it exactly like you would in Ruby:
Person with(self name = name, self location = location)
That shouldn’t generally be necessary, though.
And yes, the scoping rules might make things complicated for people. I want to have this flexibility, and sending code as data is such a powerful concept that I will not trade that, even though it creates some hard questions.
I need to point out that I’m not really creating this language for other people. If other people like it, that’s great, but I’m building something that I want to in myself.
September 30th, 2008
> It’s eminently readable but the main problem is the dash. Allowing dashes in names in a language with infix operators means that you must use spaces around a minus sign which really would annoy me.
If you define that an idenfifier must start with one of [a-z][A-Z]_, then you can use any of the characters involved (dash, ?, !) in a unary operator like !foo and -foo.
The price you pay is that any infix operator must be surrounded by spaces, as in (a + b) or (a ? b : c). But seriously, would anyone want it any other way? I have never seen a coding standard that mandated anything different.
September 30th, 2008
Tomas:
Well that’s exactly the problem. Surrounding by spaces constrains code in a way I don’t like and I’m already afraid of constraining it to much as it is. So I think I’m going to go without the dashes.
September 30th, 2008
Reply to “Variations on naming”