Syntactic Sugar/Shorthand code

[sw1ft]

So recently at work we've been discussing the use of shorthand code and why it is good/bad.

I'm personally one for constantly searching out more efficient or syntactically pleasing ways of doing things, but this isn't being well received.

What's the general opinion here? Is readability of code absolutely paramount for everyone who might look at it? Or can you assume a certain level of understanding when it comes to shortcuts?

I'll use JavaScript as an example so that input can come from more people but really this relates to any programming language, in my case JavaScript and C#.Net.

One example is using the below, where the + character is shorthand for the parseInt function:

var s = "0", i = 0;
if (s===i) {
alert("match");
} else if (+s===i) {
alert("parsed match");
}

I understand that this might look confusing to people who don't know that syntax, but surely the same can be said for all programming languages? For example we use the following absolutely everywhere and I think it would be just as confusing for a new developer to understand.

var b = false, s=""; 
var s = (b) ? "true" : "false";

What do you guys think? Is it wrong to use things like this or should I argue my corner a little more?

It may be worth noting that this is part of an application worked on by a small (< 5 persons) development team.

 

[peterwalkley]

Readability every time. Sooner or later someone inexperienced is going to be dumped with your code and a nasty bug to fix in zero time.

 

[Haircut]

Readability every time.

What he said.

That's not to say you can't use the language features that are available to you though.

I don't know JavaScript, so I can't comment on the usage of the operator you've used, whether it's a widely used thing or not.
To my untrained eye it doesn't look particularly nice though and reminds me of operator overloading abuse that I've come across in other languages.

 

[gregorius]

I would go for readability every time, subject to the use of "standard" idioms (that is, those things that are almost universally used and understood in the language community).

Compilers and interpreters these days tend to be so good that most idioms don't gain any advantage in efficient execution.

 

[AHarvey]

As someone who doesn't know JavaScript I had to read up on what the parseInt function was, but I could already kind of guess what the first quoted code was going to do. I have no idea what the second one is doing.

Personally, not a fan of the shorthand, because if I was new to the language and didn't know what it was, how am I supposed to google it to check what it is? :S

 

[DodgeeRascal]

Readability.

I'm working on a legacy code base at work and fixes/enhancements take way longer than they should, purely based on the amount of time it takes to read through functions again and again to make sure you've understood them.

Even when I write anything for any personal projects keep code readability a priority.

 

[PaulM]

In your example of using + instead of parseInt I would definitely explicitly use the function you want (i.e. parseInt) rather than a unary plus. Especially considering +x is absolutely not the same as parseInt(x). That's one of the problems when people use certain shorthand, they might assume two peices of code are the same, but they're not necessarily correct.

I would say syntactic sugar is fine, but not if it's at the expense of readability, short ternary operations are easily readable so that's fine.

 

[sw1ft]

So readability is more important to most people, that makes sense.

I think there is a happy medium, making code so readable that it takes twice as long to write is, in my opinion, just as bad as using too much shorthand and taking half as long.

I've also been working on legacy code recently and had the same problems, so I try to be as sympathetic to that as possible as one day my code will be legacy code too. I'm not saying I'm an advocate for using shorthand throughout code, I am just open to including shorthand in our best practices.

It sounds like a small shift in my thought processes will slightly decrease my productivity in the short term but will mean our codebase will be much stronger for it.

 

[Dj_Jestar]

Developers spend 80% of their time reading code and only 20% writing code. (Uncle Bob's Clean Code as a source)

Go figure

 

[D.P.]

So readability is more important to most people, that makes sense.

I think there is a happy medium, making code so readable that it takes twice as long to write is, in my opinion, just as bad as using too much shorthand and taking half as long.

I've also been working on legacy code recently and had the same problems, so I try to be as sympathetic to that as possible as one day my code will be legacy code too. I'm not saying I'm an advocate for using shorthand throughout code, I am just open to including shorthand in our best practices.

It sounds like a small shift in my thought processes will slightly decrease my productivity in the short term but will mean our codebase will be much stronger for it.

If code is overly verbose and long winded then it fails to be good readable code.

Readable code doesn't mean doing things in the longest possible way.
As jester says, writing code should be a small part of your job as a programmer. More time will be spent in design, thinking, reviewing, testing, debugging, refactoring. Writing software in 1 week that has architectural issues and is hard for others to maintain is far less desirable than spending 2-3 weeks and having a well designed, scalable,e xtensivble software that is easy to maintain and understand.

 

[ZombieFan]

You will be saving time in the long run by making your code more readable. The time spend writing the code is tiny compared top the time other developers will read it in the years to come.

Remember - you should be writing code for other programmers to understand, not for the compiler to understand. Compilers will deal with any old crap. Programmers won't

 

[sw1ft]

As an update to this, I've changed my coding style slightly over the last couple of weeks to focus more on code readability and maintainability rather than using the quickest/most flashy way of doing things.

I've found that my productivity is mostly unchanged, though measuring this is difficult, but now reviewing code with others, especially less technical people, is a much nicer experience for everyone.

It may sound simple and obvious but there have been instances where I have gotten so wrapped up in using a bit of syntax that I've seen on Stack Overflow or something that I overlook the idea of writing code for programmers rather than compilers.

 

[Dj_Jestar]

Read "Clean Code" by Bob C. Martin.

Other books worth reading are "The Clean Coder" also by Uncle Bob, and "The Pragmatic Programmer" by Andrew Hunt and David Thomas. They don't focus on readability, but have significant parts about it.

 

[sw1ft]

Thanks for the suggestions, I'll look into all 3 of them now.

Are there any other suggestions of books/articles that focus on coding best practices rather than actual concepts? I'm finding myself more often in situations where I have too many ways of solving a problem so I need to reevaluate how I write the code rather than functionally how to do something,

 

[Magik5]

Readability vote here too.

Alternatively you could stick a comment at the end of the line:

} else if (+s===i) { // +s: parseInt(s)

But then that kinda defeats the point of writing code, fast. People who generally write super short hand I find do this not for speed, but to show off. Using your above example it may take you an 1/4 of a second to write

+s

vs maybe just over a second to type

parseInt(s)

. Over the course of a day may have saved 2-3minutes of typing which in reality is not that much of a gap.

 

[sw1ft]

I'm not sure if it's to show off, but maybe that's my being in denial.

Speed was one part of my reasoning but also for code simplicity, if you have a helper method that is used all the time, rarely edited and just does a job then I think using short hand is more acceptable, but you could argue debugging it could then be a PITA ...

I do know what you mean, it's a no-brainer now as others have pointed out and I now struggle to justify using shorthand in 99% of scenarios.

 

[D.P.]

As an update to this, I've changed my coding style slightly over the last couple of weeks to focus more on code readability and maintainability rather than using the quickest/most flashy way of doing things.

I've found that my productivity is mostly unchanged, though measuring this is difficult, but now reviewing code with others, especially less technical people, is a much nicer experience for everyone.

It may sound simple and obvious but there have been instances where I have gotten so wrapped up in using a bit of syntax that I've seen on Stack Overflow or something that I overlook the idea of writing code for programmers rather than compilers.

writing code is much like any other natural language communication. You need to write clear precise sentences hat are not too long or complicated. You need to use words and phrases that are sufficiently expressive but commonly understood by the reader/listener.