Syntactic Sugar/Shorthand code

Associate
Joined
13 Aug 2008
Posts
221
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:

Code:
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.

Code:
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.
 
Associate
OP
Joined
13 Aug 2008
Posts
221
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.
 
Associate
OP
Joined
13 Aug 2008
Posts
221
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.
 
Associate
OP
Joined
13 Aug 2008
Posts
221
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,
 
Associate
OP
Joined
13 Aug 2008
Posts
221
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.
 
Back
Top Bottom