Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

Earlier I've asked similar question at StackOverflow and was ruthless downvoted. Yet I believe it to be absolutely viable and useful. At least for me as a software developer.

There are many holy war discussions concerning code style, readability and so on.
Yet the only book which references real ergonomic research I've read so far is Human Factors (6 volumes in Russian translation) by Salvendy. That's too little. I doubt persuasiveness should be based on subjective perception of readability.

Consider these pieces of code:

if (bla-bla) return;

if (very-long-bla-bla-bla) return;

if (bla-bla) 
    return;

if (bla-bla)
{
    return;
}

if (bla-bla){
    return;
}

Semantically equivalent but from the point of readability is quite different.
When I scan code I usually look at the left side of the screen and expect control flow statements to appear there so it is possible to miss 'return' in first two examples. And it really happens from time to time when I read other developers code.
Well, the research states that vertical scan is more performant than horizontal when width is not too small. But how to compare indented return and return surrounded with braces?

Another my concern is short term memory and visible part of the routine. If code introduces many 'things' (remember those 7+-2) I prefer to see all of them at once without scrolling back and forth in order to remember what something is used for.
Hence, reasonable to ask if portrait display orientation is better than landscape?

Each programming language has its idioms and code formatting conventions but I never saw the justification for adopting and preferring one to the other.
I appreciate if someone share his knowledge and provide some useful links to the results of scientific research in this subject. Thanks.

p.s. I'm sure it is legal to treat the developers reading my code as users and the result of this process as their experience. ;)

Update:

I disagre with the comments stating that this question is about readability only. Absolutely not.
I can continue with examples of language design:
The famous C/C++ '==' and '=' operators and special style if (value == variable) for checking the euality against constant values. Still leaving place for errors when comparing variables.
It is a matter of how easily a mistyping can introuduce hard to spot error.

Another example is API design in general.
In C# List<T> could contain only one overloaded Add method accepting either T or IEnumerable<T> then the following code would be possible:

foreach (var item in items)
{
    list.Add(items); // may be item?!
}

but List<T> has Add() and AddRange().

We heavily use the help of autocompletition - sometimes it misleads us and sometimes the error is left unnoticed by developer and compiler as well.

Dynamic languages.
Whenever you use dynamic in C# you should forget about IntelliSense, it just doesn't work. It probably could be helpful with some powerfull analysis but it doesn't.
So does dynamic language demand higher load on memory?

Another question is whether programming language and native natural language / culture interfere with each other. Starting from read write direction and finishing with semantics perception.
In Russuian books 'Stream' and 'Thread' are often translated as the same word: 'поток'. In some literature 'I/O' (ввода/вывода) из аdded to the 'Stream' to distinguish from 'Thread'. I do not know whether it influences the comprehension but I suspect it is at least at the stage of learning.

Update 2

These videos partially address my question:

http://vimeo.com/97329157

http://vimeo.com/97471514

share|improve this question

closed as off-topic by Matt Obee, Erics, Benny Skogberg MCSA, DA01, JonW Dec 2 '13 at 11:48

  • This question does not appear to be about user experience within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

2  
IMHO it's not a question for neither StackOverflow nor UX (as reading source code is not typically considered to be a part of user experience, personally I think your postscriptum is bit of a stretch ;)). Programmers StackExchange is probably the right choice, though code style matters have been discussed to death there. My 2 cents on this very subject: programmers.stackexchange.com/a/112723/29029 –  Konrad Morawski Dec 1 '13 at 14:52
3  
@Morawski: but reading code is part of the developer's user experience. My user experience of reading code is greatly affected by having a coding standard (whichever standard is decided on) and everybody adhering to it. Or perhaps I should say my user experience of reading code is greatly affected by code not adhering to the standard that was agreed upon. –  Marjan Venema Dec 1 '13 at 16:05
1  
@MarjanVenema I can read a novel in PDF, and then you can say that reading this novel becomes a part of my user experience (while I'm using eg. Foxit Reader), but does it mean that creative writing questions, too, fall in the scope of UX? : ) What doesn't, then? –  Konrad Morawski Dec 1 '13 at 16:07
2  
I also think this is a serious and interesting part of HCID - code readability is critical for programmers. It is as valid as asking what is the optimal length of a line of text? Or how many words in the title of a search result are most effective (answer: 7 ). This topic is little researched and in fact on of the topic I'd like to research in the near future. I don't really see it off-topic. It is much more important than many other questions posted on this forum. –  Izhaki Dec 1 '13 at 20:17
2  
This question appears to be off-topic because it is about Programming semantics, which belongs to Programmers.SE –  Benny Skogberg MCSA Dec 1 '13 at 21:56

3 Answers 3

Convention (in whatever context you're working in) trumps all. Whatever your working group has decided upon should be observed. If you're in the process of determining coding conventions there's plenty of good anecdotal, language specific, advice available on the internet.

I know of no studies that suggest a specific coding style is easier to read than others, but as mentioned there is much anecdotal evidence/opinions on the subject, and it's usually language specific.

For instance Javascript looks somewhat like C/Java but has some semantics C/Java programmers wouldn't expect:

return {
    x : "x"
};
// in not semantically the same as
return
{
    x : "x"
};
// search for "semicolon insertion gotchas" for explanation

I suspect in this area of determining which coding convention is "best", expert experience would tend to yield more useful information than empirical studies. Exactly why I feel this way, I can't say - it's really just a guess. Maybe there are just too many variables for a study to control.

I gave this question a +1 because (even though the question is vague) programming language syntax (and semantics of course) is a UX problem, and an often ignored one. Too many computer languages are using 40 year old syntax. The UX of programming is too repressed. Not always repressed (e.g. Python), but the inertia (especially web languages) seems to be going the wrong way.

share|improve this answer
    
I disagree with the view provided. First, there is no real convention - as a programmer, you'll see a multitude of code styles - it is hard to find two companies that adhere to the same guideline. Second, I believe that in UX the whole point is to improve things, even if the users are already well accustomed to a flawed design. –  Izhaki Dec 1 '13 at 20:21
    
Could you please clarify 'UX of programming' and Python as example. What do you mean? –  voroninp Dec 1 '13 at 20:56
1  
@voroninp - Python abandoned traditional (C inspired) syntax and gave whitespace (indentation) a syntactical significance. This means (among other things) there's less room for different formatting styles and it's (arguably) easier to read. –  obelia Dec 1 '13 at 22:38
    
@izhaki - I didn't mean to imply there's a real convention (unless of course if it's formally specified, and then it's not a convention). There's expert commentary on conventions readily available, and there are languages that try not to rely so much on convention. –  obelia Dec 2 '13 at 7:21

My answer will not be complete - bits and pieces really, I just want to hint at two aspects that I feel are worth not overlooking.

(As I noted in comments, I've shared a few thoughts on the subject before - here).

When I scan code I usually look at the left side of the screen and expect control flow statements to appear there so it is possible to miss 'return' in first two examples. And it really happens from time to time when I read other developers code. Well, the research states that vertical scan is more performant than horizontal when width is not too small. But how to compare indented return and return surrounded with braces?

Surrounding it with braces is a habit that helps to protect yourself against introducing a bug.

Let's say you need to call stream.Close(); before leaving the method. Here's our code:

if (bla-bla) 
    return;

Okay, let's insert stream.Close:

if (bla-bla) 
    stream.Close();
    return;

And oops, I just broke it. Only calling stream.Close is now dependent on whether bla-bla was true. return is not conditional anymore, so we'll jump out of the method in any case and the code below will never execute.

Had our code looked like this:

if (bla-bla)
{
    return;
}

It couldn't happen.

I think it draws attention to an important point. In case of code, which tends to be edited a lot, it's not just about "static" readability.

It's also about ensuring that this readability is persistent and less likely to get affected by future changes, refactoring etc.

Another my concern is short term memory and visible part of the routine. If code introduces many 'things' (remember those 7+-2) I prefer to see all of them at once without scrolling back and forth in order to remember what something is used for. Hence, reasonable to ask if portrait display orientation is better than landscape?

It makes me think of another important aspect: source control.

Programmers don't only read code in code editors / IDEs. Working with source control is essential. The longer code lines are, the harder it gets to keep track of changes, to compare code, to merge changes automatically.

If your code looks like this:

if (header instanceof TextView) ((TextView) header).setText(data.getTitle());

It's only one line, all right. You saved some vertical space. But now the probability that two programmers change the same line (one renamed header to mainHeader, another one had to change getTitle to getDescription) increased, and source control will not be able to tell how to combine these changes automatically, and the developer - which may be a third person - has to resolve the conflict manually.

If the same code was laid out in multiple lines as follows:

if (header instanceof TextView) {
    String title = data.getTitle();
    ((TextView) header).setText(title);
}

It wouldn't have been a problem. One developer modified lines 1 and 3, the other - only line 2.

So this is another important aspect: readability in the VCS / diff. It is much harder to struggle with messy code when resolving conflicts: there may be dozens of such cases at once (and you can't move on until you solve them all), each in a different file so you don't know the context etc.

Then there's also readability when debugging - eg. if four method calls are squashed into one line, it's less convenient for me to debug it step by step...

So, to sum up, there are different contexts in which one approaches code, and this is something one should be aware of when attempting to evaluate its readability.

share|improve this answer
    
Somewhat related article about changes understanding by MS Research: research.microsoft.com/en-us/groups/sa/… –  voroninp Dec 2 '13 at 14:01

I can't answer about any usefulness in sense of code, but there surely can be some methods to improve code for perception. You should simply think about the code as the written product, that is read by human user (i.e. another programer or someone else), so among others, answer yourself to these questions:

  1. Who is the reader of code? Is it you, the author? Amateur programer or expert?
  2. How can you help to the reader to better understand the code, it's goals, tasks it solves and tricks it uses?
  3. Is there some kind of mentioned in the answer above conventions, that are probably well known among other users and support some standards — in variable names, code formatting, etc.?
  4. Do you embed in your code smooth descent from common, "bird's eye view" description of code structure and organizaton to explanations of local, concrete points (for instance, in comments, or in general descriptions)?

Answering these questions is good to feel and understand the code as the product being used, so you'll certainly find better solutions in commenting, organization, readability and so on to make it more usable.

share|improve this answer
1  
There is a problem with conventions. I suspect that motivation can suffer if they're set authoritatively without conscious acceptance by all team members. On the other side the larger the team the more tastes diverge. I tend to persuade with robust facts because I believe understanding leads to awareness and involvement. –  voroninp Dec 1 '13 at 21:11

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