6

In many English-based programming languages like C++ and JavaScript, there exist long keywords like function, namespace, exception (in OCaml languages) and such. Do you think shorter keywords like func should replace them? Why or why not? What about replacing them with digraph operators?

The long keywords we will be mainly talking about, but not limited to, are mainly from curly-brace imperative languages: function, namespace, implements, instanceof and synchronized (I always misspell that). You should also show the examples from your favourite programming language.

9
  • 4
    "What about replacing them with digraph operators?" Maybe you should start programming in brainfuck. Commented Dec 11, 2010 at 8:07
  • 3
    I have doubt if this is a good question in that form. Can you edit in a constructive way. Anyway sometimes I feel that non-English speakers are smarter than native native speakers, not really of course. For a developer that doesn't understand English, namespace == aguucibosyvwtan (hoping this is not a word in any language). Code is not a normal text. I can't understand why developers push hard the notion that the text should be readable as a normal text at least for the programming language. Programmer symbols is another beast. Many operators currently has little mean for most people.
    – Maniero
    Commented Dec 11, 2010 at 9:53
  • 3
    I'm not defending a programming language based on operators instead of keywords but sometimes a math symbol is better than a keyword, sometimes abbreviated word is better. I have nothing about longer keywords. "def" on Python is a example. I heard people complain about a lot of thing in Python but not about "def". People complain about the "complexity" of pointer but nobody claim for a "pointer of" or "address of" syntax. This is not a rant pro shorter syntax. Perhaps it be a rant about the silly insistence of readability of simples things. "Normal" people don't understand (((1+2)*3-4)/5+6)%7)
    – Maniero
    Commented Dec 11, 2010 at 10:07
  • Its good the keywords are that long. Otherwise, I'd have plenty of name clashes with my variables, classes, and members called xmf, jkl, xmf2, xmff, iff, and the good old agh
    – Lukas Eder
    Commented Dec 11, 2010 at 19:09
  • @bigown: my comment was only meant to be ironic/funny. Not to be taken literally or seriously :) Commented Dec 11, 2010 at 21:47

7 Answers 7

10

I accept keywords like func and cons in functional languages, because functional languages tend to be math-like and more symbolic.

But in imperative, object oriented languages, where you are telling the computer how to do something as well as what to do, I prefer that the identifiers and keywords be whole words.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand. ~Martin Fowler

7
  • @Robert: I totally agree with that quote. I think sometimes it gets taken to the extreme though, like when I start writing 20 char function names to explain every little thing. That's one of the ways I know I'm dealing with crappy design. Sometimes other coders', but usually mine :) Commented Dec 11, 2010 at 8:18
  • I agree with the first paragraph of Robert's answer. I see no problem with abbreviated syntax in any paradigm. Pls, IMO, []'s, :-) are understandable as func, def, int, var, cons are. Personally I can understand better a good code in C than a good code in C++ (using the C++ style, of course). Sometimes less is more. No, C++ syntax is not the problem, perhaps the semantics, but certainly the style produces bigger and hidden code and I need to navigate a lot to understand the code. Language syntax is domain of every programmer. Problem domain isn't. That's about what Martin Fowler is saying.
    – Maniero
    Commented Dec 11, 2010 at 11:47
  • 1
    For me is undebatable that the symbol names must be meaningful. Symbol names is about the problem domain. Language syntax is lesser important. People who complain about Perl syntax is not Perl programmer :-) I don't like Perl, but the syntax is not the problem.
    – Maniero
    Commented Dec 11, 2010 at 11:51
  • 1
    @bigown: agreed... the syntax is static to the language. It doesn't really change, so if you want to learn the language, you learn the syntax which includes the keywords. To a good programmer it should make no difference what language those words are in or the length of those words. What really matters is whether the dynamic part of the code, which is the stuff you write, is understandable to the people it is intended to be read by. The only time it makes sense to complain about the keywords is when they become so numerous as to make the language hard to remember or use effectively. Commented Dec 11, 2010 at 17:57
  • Why do programmers use func? I think in maths, fxn is more common.
    – TRiG
    Commented Dec 22, 2010 at 11:00
7

This is a non-issue thanks to the auto-complete capabilities of any text editor worth programming in. You can make a keyword named FunctionNamespaceImplementsInstanceOfSynchronized for all I care.

I'll just hit tab.

One other thing... I don't think I've ever in my programming career come across a keyword that was long enough to annoy me. The examples you give aren't exactly striking fear into my fingers.

However, I really hate those damn double underscores in python.

6
  • 2
    I up voted, even though I don't completely agree. Your identifiers should be a reasonable length; the programmer coming after you may not agree that a name that long actually makes the program easier to read. Commented Dec 11, 2010 at 7:15
  • @robert: i don't make my identifiers excessively long, i'm talking about keywords like in the OP's question. This is just an over the top example, which illustrates that I could care less about function being 4 chars longer than func. Especially since I'll be hitting tab or ctrl-space or whatever by the time i've typed 2 of them. Commented Dec 11, 2010 at 7:57
  • I guess what I'm really getting at is... who gives a shit? as long as the keywords make sense in the context of what I'm doing (telling a computer to do crap that I can't do myself), then I don't mind if the language founders decided to be more or less verbose. Commented Dec 11, 2010 at 8:03
  • 1
    People could disagree about readability of "function" instead of "func" either. See my comment on question post. I agree that the problem is not the writability.
    – Maniero
    Commented Dec 11, 2010 at 11:09
  • 1
    @cavalera: Exactly. It's just a small set of symbols, what's the difference if they are long or short? We agreed.
    – Maniero
    Commented Dec 11, 2010 at 21:40
4

So you are proposing that we reduce code readability in exchange for saving some typing? Perhaps you might want to consider how much time you spend typing code and how much you spend reading/maintaining it.

If you are steadfast that we need concise unreadable code, I'd suggest Perl.

3

Keywords are chosen so as to reduce ambiguity while using them. Also to make the program easier to read. That's why even for a non programmer, the code makes a bit of sense.

6
  • 1
    depends on how far you cast the net into the 'non programmer' sea. I don't think your average non-programmer person can make sense of AppleScript, let along Java. As an aside, I find AppleScript and Visual Basic to be 2 of the most illegible languages out there. Brain just can't parse. What's with that? Commented Dec 11, 2010 at 8:13
  • 1
    Readability cannot be explicitly forced by a language, but it can have features for writing readable code. Yes, a non-programmer is an abstract description, so we can try to judge a program by how much sense it makes considering it to be plain English. e.g. if i in s then print i is a better choice as opposed to if (s.indexOf(i)) echo i
    – nayan
    Commented Dec 11, 2010 at 9:11
  • 2
    I never met a non-programmer that barely understand a program. Good example for your argument although I disagree with all assumptions of the syntax is the big problem of understandability of code. Algorithms and variables/functions names is the opposite.
    – Maniero
    Commented Dec 11, 2010 at 11:19
  • 1
    In any case, we're writing programs that will be read primarily by machines and other programmers. Commented Dec 11, 2010 at 17:52
  • and I don't agree that if i in s then print i is inherently more readable than if (s.indexOf(i)) echo i. It all depends on your background... native language, programming experience, etc. The latter is more readable to me because my early experiences with programming included bat syntax and c. As for the former, it probably would be more readable by a non-programmer. However, we're writing for programmers. You could write it differently given those same keywords and I'd argue it is MORE readable to programmers: valueIsInSet = isValueInSet(i, s); if (valueIsInSet) echo i Commented Dec 11, 2010 at 18:20
2

Time to change your editor. Most editors highlights the keywords and hence it is really easy to find the spell errors. Because of this people normally didn't notice this or don't care about this.

1

Basically it's nature and easy to spell, remember! Look at Java, i feel it seems that's English, not programming language ;)! BTW, if you look at Python or Ruby, you will see something really short!

1
  • Really? Java seems English? For me none programming language seems English. Programming languages has English words, nothing more. Some are closer than others but I can't see the @nayan example as plain English: s.indexOf(i). For me, a programmer, this is equally understandable, for good or for bad, as s[i] and I read in same way. For a non-programmer AFIK the first syntax is equally confuse as the second syntax. Actually a syntax with underscript index can't be understandable for most people. Matrices is a concept barely known outside exact sciences.
    – Maniero
    Commented Dec 11, 2010 at 11:33
1

First of all, those languages of syntactical C ancestry abbreviate some keywords that are used often, while the longer keywords like "namespace" hardly matter... for example "int", "var".

Long keywords are universally understandable between languages. PL/SQL, for example, is not a curly-brace language, but the keywords spelled in full: function, procedure, package, etc. For that reason, it should not be too hard to read a PL/SQL procedure even if you have never learned PL/SQL.

Once keywords are abbreviated, programs are only readable to those who know what each abbreviation means in that language. Ambiguities can arise. And programmers are encouraged to abbreviate their identifiers too, quid pro bono.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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