views:

546

answers:

12

As the title of this post states. Would you prefer to use a language that is verbose or more shorthand? So would you prefer this:

Dim myvar as string = "hello world"

or this

string myvar = "hello world"

I know I just compared C# to VB but you get my drift, another example would be powershell where you can use the % sign to mean foreach(I'm pretty sure thats right I havn't use PS in a while).

Personally I find VB more easier to write but I would rather read someone elses C# code, mainly because of its shorthand notation I found it easier to see what the person is trying to do.

What about you?

+3  A: 

I like to write shorthand but readable and maintainable code.

Check this great article: The Best Code is No Code At All

CMS
A: 

I have to say that I personally fall into the exact example you gave. I stared out in VB, its verbose language was great for starting with, but now that I have started using C# and Java, VB seems to just take too darn long to code the items I need, too much typing, not enough coding!

Mitchel Sellers
I think you'll need to type even more in Java.
chakrit
+3  A: 

I prefer:

MyString = "a string"

Many languages support this.

Robert Gould
+6  A: 

Code (and any writing!) should be as short it can be without losing readability.

  • Languages which force a lot of lingual cruft on the programmer are the antithesis of good programming, because all the added verbosity causes readability to be highly diminished, therefore disguising the activities performed by said code.
  • Languages which use more keywords to do the same as another language lead to poor programming, because it becomes harder to read and comprehend what the code does.

Those two points say the same thing. You tell me which is easier to read and understand. :-)

Chris Charabaruk
+2  A: 

You want shorthand? Try Ruby!

I love this post on time functions in Ruby and since no class is sealed, you basically have extension method functionality built in.

How's this for concise readable code:

Time.now # => Tue Oct 14 22:48:27 -0500 2008
3.hours.ago # => Mon Oct 13 19:48:27 -0500 2008
1.week.ago # => Tue Oct 07 22:48:27 -0500 2008
Atømix
+3  A: 

I like languages which allow you to vary how concise you are. For instance, in C# when it's already clear what a local variable's type will be based on assignment, I can use implicit typing:

var names = new List<string>();

Where it's clearer to make it explicit, however, I can do so:

List<string> names = new List<string>();

The same is true for various aspects of the language - type inference for generic methods, lambda expressions, delegate instance creation expressions, object initializers etc, using a query expression vs "normal" method calls, etc.

There aren't always "shortcuts" for everything I'd like, but you get the general idea. Having this flexibility allows you to write readable code whatever the situation - because sometimes the most readable code is the shortest, and sometimes extra (redundant) information makes it clearer.

Jon Skeet
+7  A: 

I don't see a real difference between the two examples you provided.

What percentage of your programming time do you spend actually typing code? I expect 5% is an overestimate. When you take into account thinking time, testing, bug-hunting, consulting references, and in some cases, compiling, you see that saving a few characters don't make a tremendous difference. Especially if they're easy-to reach characters (alphabetic ones).

When it comes to actually reading code, extra characters don't consume much extra time at all. In fact, we've had a lot of practice reading English (many of us, anyway) and extra words can actually help us make sense of what we're looking at.

One of the reasons that BASIC has refused to die is that it takes so little effort to read. Compare these two:

For x = 1 To 10 Step 2
for(x=1; x<11; x+=2)

My point is that on the "micro" scale, when it comes to individual keywords and syntax, minor changes aren't going to make a big difference, and blindly trying to save characters is a bad idea.

It's the macro scale that counts. How many lines it takes to do something. How many functions you have to invent to do something, how much thought needs to go in something (worrying about array bounds, or empty strings, or simply solving problems that the language could solve for you). Languages that have this sort of "shorthand" are better.

Artelius
That's why I sticked with VB for so long... until LINQ came along haha.
chakrit
A: 

I used to admire APL (super-concise language with lot of special symbols) and C for its shortcuts like doing an action and testing at the same time, like the well known while (p++ = q++);. And to despise Cobol (old style) for its super-verbosity (like add b to c giving a or similar).

Now, some years later, after having read and corrected lot of code (mine and other's), I take highly readability over conciseness and astute tricks that takes hours to understand... I favor explicit variable and function names, splitting long lines in several instructions (even it is creates short lived local variables: it can help debugging anyway), etc.

Some languages can be super verbose without good effect (somehow, Java falls in this trap).
Some languages can use English words in place of symbols without being verbose (Lua using then/do/end instead of {} -- some people are disturbed by that, I find this readable and not so long).
Beside, most modern IDEs and good editors have auto-completion and templates, reducing typing, so it doesn't really matter.

It is a question of taste and habits, but somehow I now tend to favor languages I can understand without first reading a big manual to those with special, convoluted notation.

Now, it can go beyond that: some languages have some nice, original concepts worth studying, and that's independent of syntax.

PhiLho
+1  A: 

Short code is quicker to scan over and understand what its intentions are quickly.

GeekyMonkey
+2  A: 

Conciseness is a virtue, within reason.

I write a lot of my code in Haskell where you can get an amazing amount of punch out of a line or two.

I'm not crazy enough to try and go all the way down to something write-only like J, however, because it becomes an exercise in mental masturbation; no one else can read the code when you're done and there are no decent libraries.

Steve Yegge had a good rant on one of the distinguishing characteristics about newer and older programmers, and that is a 'tolerance for code compression'. While his points are usually somewhat overstated, this one I happen to agree with.

http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.html

Edward Kmett
+3  A: 

More concise is better, up to a point. I find Java code very hard to read because it is so verbose that the high-level purpose of it gets lost in a bunch of superfluous verbosity. On the other hand, Perl is concise to the point of being cryptic.

I think the general rule here should be that a language should be as concise as possible without relying on special-case shortcuts to save a little typing here and there. As a language designer, once you hit the point where you're making the language substantially more complex just to save people a little typing, that's about the time to stop trying to be more concise.

dsimcha
A: 

I'm starting to love Ruby syntax

def say_hi_to(persons)
    persons.each do |person|
      puts "Hello #{person}!"
    end
end

say_hi_to(persons)
Atømix