14

Okay, this is one of those little things that always bugged me. I typically don't abbreviate identifiers, and the only time I use a short identifier (e.g., i) is for a tight loop. So it irritates me when I'm working in C++ and I have a variable that needs to be named operator or class and I have to work around it or use an abbreviation, because it ends up sticking out. Caveat: this may happen to me disproportionately often because I work a lot in programming language design, where domain objects may mirror concepts in the host language and inadvertently cause clashes.

How would you deal with this? Abbreviate? (op) Misspell? (klass) Something else? (operator_)

Improve this question
7
  • 7
    Aside from namespacing perhaps we should consider changing our naming conventions? Sorry for the obvious. – Chris Jan 3 '11 at 18:42
  • 1
    @Chris: You never can trust a programmer to realise the obvious! (Though in this case I have.) – Jon Purdy Jan 3 '11 at 18:50
  • 7
    If there is any reason to like PHP's $var syntax, this is it. – Joey Adams Jan 3 '11 at 18:55
  • 3
    @Joey Adams: I smiled briefly when I saw this question and remembered all the PHP bashing questions floating around SE. – Chris Jan 3 '11 at 19:35
  • 3
    Obviously, change the language source code to allow my naming conventions. This also has the benefit of "protecting" my code since it will only run/compile on my interpreter/compiler. – dietbuddha Jan 4 '11 at 7:50
21

  1. Accept that you might have to make minor changes to your naming convention, such as adding capitalization. It's better to accept this as soon as possible so all subsequent code is consistent.

  2. Consider being more specific. Keywords tend to be quite broad, so narrowing class down to demonstrationClass not only works around the issues but also increases readability.

Improve this answer
10

It is not something I have encountered, but if I get in such a situation, I would try to resolve it with the following options, in order.

  1. Try to find a synonym.
  2. (especially for variables) try to find a prefix or postfix
  3. (especially for classes) change the first letter to upper-case and forget about the coding-rule that names should not differ only in case. This option, I would probably only use if the conflict is with a keyword.
  4. Use an abbreviation.
Improve this answer
5
  • 1
    I don't see what's wrong with names differing only in case, especially in argument lists where the parameter of type const Foo& doesn't have any reasonable full name other than foo. Granted, it might be better to give your Foo a more descriptive name than foo if it lives in a function body and serves a less specialised purpose. – Jon Purdy Jan 3 '11 at 18:18
  • @Jon - I agree, though personally I tend towards "p_", "l_" and "m_" prefixes rather than case-varying. I adopted that convention because of the all-have-the-same-obvious-name issue. Which convention you use to deal with this is largely irrelevant as long as you use it consistently in any particular context, of course - the case-varying approach is certainly used widely enough that most developers should recognise it. – Steve314 Jan 3 '11 at 18:32
  • @Jon - that comment reads like I'd selectively apply the convention only when I have the same-names issue, which isn't what I meant. The context issue relates to language, project etc. The conventions are designed so that the issue is a non-issue whenever it occurs (or rather doesn't), not to be selectively applied as needed. – Steve314 Jan 3 '11 at 18:36
  • @Steve314: I got your meaning from the first comment. I dunno, affixes like that always felt a little too close to Systems Hungarian for my comfort. – Jon Purdy Jan 3 '11 at 18:42
  • @Jon: It is not a rule I apply religiously, but I find that it is easier to make mistakes if two identifiers only differ in case. Some of those errors will be spotted by the compiler, some are much harder to find (especially if the two identifiers name the same kind of thing). I prefer to have one general rule, with case by case exceptions, than a full book worth of rules covering all possible cases. – Bart van Ingen Schenau Jan 3 '11 at 18:48
6

The language wins; you can't outsmart the compiler (ignoring abominations such as the PL/1 IF IF = THEN THEN THEN = ELSE ELSE ELSE = IF END, but then PL/1 wouldn't cause you to ask the question in the first place). Basically, you have to follow the rules of the language, and you have to find an alternative to the language's key words for your own use - or find an alternative language.

So, except in very unusual circumstances, you adapt to the language, not vice versa.

Improve this answer
5

Instead of abbreviating how about lengthening? If you are implement a class construct in a Foo language, how about using FooClass and foo_class? (Modulo whatever your casing preferences are).

Improve this answer
3
  • Would you prefix "java" on every identifier you use in Java code? And lets not even mention the problems with prefixing "C++" on every identifier... – Steve314 Jan 4 '11 at 12:01
  • @Steve314, you wouldn't use the prefix java in java code, you would use the prefix java in the c++ code that implements a java compiler. Also, you would only use it if the rest of the identifier was a keyword. – Winston Ewert Jan 4 '11 at 22:18
  • OK - you mean lengthening in general terms, as in being more specific what the identifier refers too. For different applications, "class" might be renamed to "class_taught" or "class_of_animal" or "classiness_value" or whatever. I agree - I just found the compilers oriented example confusing. – Steve314 Jan 8 '11 at 10:46
5

Some of the abbreviations I've used for class, in order of frequency:

  • cls
  • clss
  • clazz
  • theClass
  • aClass

If I know what class the Class instance represents, I might include it in the variable name:

  • stringClass = Class.forName("java.lang.String");
Improve this answer
1
4

In C and C++, keywords are all lowercase and the language is case sensitive, so press the shift key from time to time and a lot of issues go away.

In Modula 2, keywords are all uppercase - but so long as your identifiers have some lowercase letters the difference is obvious and clashes impossible.

Also, absolutely naming conventions to some extent need to reflect the normal conventions of the language you're using, so I'd certainly write "myClass" in Java where I'd more likely write "My_Class" in C++.

Basically, you're not just writing for the compiler, but what people find readable depends to some extent on context and related expectations.

Improve this answer
2
  • 3
    Even for case-sensitive languages, I feel that having intermixed class and Class would hurt the readability of the code. – Karmastan Jan 3 '11 at 22:01
  • @Karmastan - perhaps that depends on how much time you've spent working with case-sensitive languages and conventions. Personally, the upper vs. lowercase "C" is visually very obvious - I see the case usage patterns for long identifiers quicker than I can read them. – Steve314 Jan 4 '11 at 11:59
3

I don't often run into this, but when I do it tends to be a non-issue because I use Delphi and it allows you to work around this issue by prepending an & to the identifier. So "class" is not a valid identifier, but "&class" is.

Improve this answer
1
  • Interesting. I have a code generating utility that allows string literals anywhere an identifier can be used. Originally, most identifiers for generated code were written as string literals to avoid the risk of keyword clashes with a growing (and keyword rich) DSL. Now, identifiers are used for most names (its surprising how much more readable the source is that way), but string literals are always available as a fallback. I thought it was good for code generation, but keyword-clash workarounds would be a bad idea in a general purpose language - but maybe I'm wrong. – Steve314 Jan 8 '11 at 10:54
2

I would add some sort of namespacing to the variable name. For example, suppose you have module named user then I would modify the variable name operator to be something like user_operator or userOperator.

Improve this answer
5
  • 2
    just don't use "smooth", "no", or "my" as a prefix – Steven A. Lowe Jan 3 '11 at 18:00
  • 2
    Absolutely. I vote "Jon_Purdys_Carefully_Chosen_Identifier_Prefix_". – Steve314 Jan 3 '11 at 18:19
  • 1
    @Steven: Even worse, I see a, an, and the used with disturbing frequency by beginner CS students. – Jon Purdy Jan 3 '11 at 18:19
  • 1
    @Jon Purdy, it's not our fault! Blame the professor that decided to name their instance of class People() aPerson. – Ben L Jan 3 '11 at 18:45
  • @Jon: The naming convention where I work at specifies that local variables should begin with a apart from tight loop variables :/ – Matthieu M. Jan 3 '11 at 19:12
2

change or adjust my naming convention

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.