How To Create "Write-Only" Code

Primary tabs

One of the leading benefits of ObjectScript is the speed and efficiency it allows for an experienced developer. Let's look at an example of how you can benefit from ObjectScript today.

Suppose you have a class that stores the names of your users. We'll call the class Data.User, and give it a string property Name. Next, we will need a method to create a new user or update an existing one. A naive, simplistic approach might look like this example:

 

ClassMethod UpdateOrCreateUser(id, name) As %String
{
    if ('$data(name)){
        quit "Name required"
    }
    if ($data(id)){
        set user = ##class(Data.User).%OpenId(id)
    }
    else{
        set user = ##class(Data.User).%New()
    }
    if ('user){
        quit "User not found"
    }
    set user.Name = name
    set status = user.%Save()
    if (status '= 1){
        quit "Error saving"
    }
    else{
        quit "User saved"
    }
}

 

The problem with this approach is it's too wordy and drawn out. It takes a lot of time typing the code, the variable names, the curly braces, and when you're done, a trivial piece of code takes up half the screen on your monitor. Luckily, ObjectScript empowers the developers to streamline the process, and cut out the unnecessary fluff. Let's take a look at how an experienced developer can rewrite the messy code to a much cleaner result:

 

ClassMethod CRUDUser(id, name) As %String
{
    q:'$d(name) "Name required"
    s x = $s($d(id):##class(Data.User).%OpenId(id),1:##class(Data.User).%New()) i 'x q "User not found"
    s x.Name = name q $s(x.%Save()=1:"User saved",1:"Error saving")
}

 

And that's it! With only three lines of code, look at what ObjectScript can accomplish. You don't need a dual monitor computer setup just to read the code. And because we cut out all the unnecessary wording, you don't even need mouse, or a scroll wheel,  or copy/paste functionality, or resizing application windows. If you're comfortable developing powerful applications using nothing more than a monochrome 80 column x 24 line display with a simple keyboard, an 8Mhz processor and a 720KB floppy disk, then you can take full advantage of ObjectScript to maximize your productivity.

Now there might be some newcomers who have trouble reading your optimized code. And when the time comes to adapt the application for new requirements, other developers may find it easier to rewrite the code completely, rather than trying to decypher your hand crafted one-liners. And you might even have difficulty following your own code a few years later! But nothing else comes close to putting so much powerful functionality in so little space!

 

Disclaimer: As hopefully everyone reading has realized by now, this article is satire. As a courtesy to your fellow developers and coworkers, do not write code that looks like the shortened version full of abbreviations and one-liners. While it may initially save you some typing and mouse clicking, it wastes much more time when someone other than yourself has to maintain and update such code. The condensed code is harder to read and follow, and therefore is a good candidate for write once and throw away later code.

 

 

 

Replies

laughI enjoyed it!  reminds me of competitions on how to get some results by a minimum of characters.  eg. list a global.

With expanding / compressing code I Studio [ <ctrl>E, <ctrl><shift>E ]  this is all history

I will admit - I was taken by how persuasive the tone was and was planning a rebuttal until I got to the last paragraph.  Well done Igor :)

Haha!

A good one, thanks, Igor! I also added ObjectScirpt highlighting - it helps in reading.

Personally I find the 

q:'$d(name) "Name required"

not very unreadable.

quit:'$data(name) "Name Required"

is better, of course.

But the second one is ... Mostly due to several ##class() stuff.

Several ##class can be eliminated, making the code shorter and readable writable better:

ClassMethod CRUDUser(id, name) As %String
{
  q:'$d(name) "Name required" s x=$classmethod("Data.User",$s($g(id)="":"%New",1:"%OpenId"),$g(id)) q:'x "User not found"
  s x.Name=name q $s(x.%Save()=1:"User saved",1:"Error saving")
}

One of my stylistic peeves is that parentheses around an if condition are not necessary, and I prefer to omit them for readability. You'll often need parens for a function call and/or to evaluate operators correctly, so best not to clutter the code with a superfluous pair.

There is at least one case where this encoding style is acceptable - it is a generator method. Just look at the code generated by &sql() or CSP, for example.
No wonder there are two versions for javascript libraries: for the developer and for production (processed by the minimizer).

At first sight it might be very cool to have code for methods in a few  lines. It is the way of programming we had in the past times. I can't recommend to use this way of coding, because it makes it very hard to read and understand the logic of code. I grew up with this kind of coding so I am very familiar with this but I am happy that Caché gives me the way to code in a modern style. When I look into my old programs, which consist of this kind of coding, then I always feel to read ugly code. I would like to change it immediately. Forget it to compact the code in one line. Put it into more lines and avoid postconditionals. If-statements are more readable and you don't have to think about what the code will do.

Nice satiric article smiley