views:

363

answers:

19

I heard people say they can understand their python code a year later but not their XYZ code. Why? I dont know what is good about python syntax or what is bad about another. I like C# but i have a feeling VB.NET code is easier to read. I am doing language design so what do you find makes code/syntax/language readable or not readable?

+1  A: 

A word required when one character will suffice - a stone in the garden of Pascal and VB.

Compare:

Block ()
Begin
  // Content
End

vs.

Block
{
  // Content
}

It requires extra brain processing to read a word and mentally associate it with a concept, while a single symbol is immediately recognized by its image.

It is the same thing as the difference with natural languages, usual textual languages vs. symbol languages with hieroglyphs (Asian group). The processing of the first group is slower because basically a text is parsed to a set of concepts while hieroglyphs represent concepts themselves. Compare it with what you already know - will a serialization/deserialization from an XML be faster than a custom search over a binary format?

Developer Art
All of those superfluous {'s and }'s, isn't indention enough to identify a block?
Juliet
I'm not sure which example you think is more readable.
Ed Swangren
Hmm, No! Thinking is language (natural language). You don't think and thus don't express yourself in symbols but in words/language, so understandable, word-based code will be easier to read whereas symbols require another process of abstraction!
Dario
@Dario - I disagree. `{` and `}` are very clearly opposites, and it's very easy for both humans and text editors to match corresponding brackets, compared to matching corresponding `begin` / `end` keywords.
Chris Lutz
@Juliet - Not everyone likes to use the same level of indentation. I personally want to kill people who indent with 8 spaces, or with tabs. How should a language treat tabs mixed with spaces? These are all issues that require you to make arbitrary choices (and thus inspire holy wars between the One True Brace Style and whatnot) that are not necessary if you leave indentation up to the programmer and require syntactic delimiting of blocks.
Chris Lutz
-1 only because that's all I can do to it. Not just wrong, but *horribly* wrong. Don't be Candide, blithering around thinking your world is the best of all possible worlds.
T.E.D.
I disagree with this assertion.
Ankur Goel
Readability of single characters suffers in my opinion compared to keywords. A passage of code surrounded by `begin` and `end` is clearer than heaps of braces, parentheses and brackets (also compare how well you can discern `}` and `)` in your favorite font).
Joey
+6  A: 

Experience.

mos
+1 for the right answer. Proper indentation may help you read code, but only because you're used to using it in other languages, so mandating indentation is no help to someone with no experience indenting code.
Chris Lutz
+6  A: 

IMO, one of the big things is significant white space. Block indention goes a long ways and languages like Python and F# that provide a level of significant white space can help with readability.

Code like Java and C# tend to be structured and the readability becomes a focal point of how it was coded to begin with and not of the language itself.

JamesEggers
Honestly, I've seen a lot of really bad code, but I have yet to see code that was badly indented (to the degree that it hurt readability). Is it really that common?
Edan Maor
@Edan Mayor - Try looking at an idiot's version of sending an e-mail in PHP...bet you can't guess what I'm doing right now...
Topher Fangio
Sometimes, but also just if you are looking at code that has different indenting style or { placement than you are used to, it can make the code harder for you to read.
crashmstr
Part of the reason significant indentation is so nice is that our brain already parses code that way, so it's just bringing the compiler in line. Nobody wants to count braces or ENDs or whatever, so block delimiters are essentially line noise in well-indented code.
Chuck
Edan Maor
@crashmstr - Anyone who gets thrown off by brace styles when coding has bigger problems to deal with. Plus, there are tools that exist to "fix" indentation, so you never need to deal with someone else's ugly style.
Chris Lutz
If that is honestly how you feel, then you should *love* the language Whitespace - http://compsoc.dur.ac.uk/whitespace/
T.E.D.
@T.E.D. - Who are you talking to?
Chris Lutz
@Edan I one had the misfortune of trying to debug someone's MXML for Flex which was not properly indented, in ANY sense of the word. Had I not taken the twenty minutes to re-work his white-space into something manageable, that document would have taken me a minimum of an extra hour.
Christopher W. Allen-Poole
@Christopher W. - Considering how common XML parsers are, why didn't you just write a program to indent it for you? As long as his XML parsed, you can easily make a tool to indent it, or find one on the internet.
Chris Lutz
@T.E.D. Whitespace is the extreme case of significant whitespace.As for indention vs braces, reading bad code was a huge amount of nested loops/conditionals is easier to read in languages like Python and F# than VB, C#, or Java....plus you don't have a ton of extra closing braces or End Ifs as they indent back. The nesting stops and everything returns to normal w/o any extra lines for single closing braces and readability. Just a blank line and you're ready to move on.
JamesEggers
As far as I know, Whitespace is actually not an example of significant *indentation*. Nothing is being intended.
Chuck
@JamesEggers - Yeah, but many text editors and other tools can help you indent your code so that you can read it the same way. And I find the closing braces at the end to be a rather helpful "Hey, the big loop is over" sign.
Chris Lutz
@Chris Lutz I'm not arguing the convention of closing braces and such. I'm just stating seeing a single blank line at the end of a loop or other block of code can be sometimes easier to read than 4-5 lines that each have an indented closing brace on them. Granted the example points to bad coding habits if there's that many closing brace. Personally, a single if statement is fairly easy to read in any language..it's when you add the complexity and smells where some languages become less about coding practices like single responsibility of methods to make them more readable.
JamesEggers
A: 

I will try saying that a code is readable by its simplicity.

You got to get at first sight what it does and what its purpose is. Why write a thousand lines of code when only a few does what is required?

This is the spirit of a functional language like F#, for instance.

Will Marcouiller
A: 

It's all about clean code.

Keep it small, simple, well named, and formatted.

class ShoppingCart { 
  def add(item) {
    println "you added some $item"
  }

  def remove(item) {
    println "you just took out the $item"
  }
}

def myCart = new ShoppingCart()

myCart.with {
  add "juice"
  add "milk"
  add "cookies"
  add "eggs"
  remove "cookies"
}
JaredCacurak
the code above is Groovy
JaredCacurak
It's also Ruby except for like 2 lines.
jleedev
A: 

For me its mainly the question of wether the language allows you to develop more readable abstractions which do prevent getting lost in details.
This is where OOP comes in very handy with the hiding of details. If i can hide the details of a task behind an interface that has the behavior of a common concept (i.e. iterators in C++) i usually don't have to read the implementation details.

Georg Fritzsche
+3  A: 

Generally what makes Python considered readable is that it forces a standardized indentation. This means that you'll never be forced to wonder whether you're in an if block or a function, it is clear as day. Even poorly written code therefore becomes obvious.

One language which I generally consider difficult to read is PHP for the same reason (or rather, its opposite). Since programmers are allowed to indent at will, and store variables anywhere, it can get convoluted very quickly. Further, since PHP historically did not have case sensitive function names (PHP < 4.4.7 I believe), this means that there really isn't a consistency in the implementation of the core language either... (Don't get me wrong, I like the language, but a bad coder can REALLY make a mess).

JavaScript also has a lot of problems with undisciplined developers. You'll find yourself wondering where variables have been defined and what scope you're in. Code will not be in one consolidated place, but rather spread across multiple files, and often lurking where unexpected.

ActionScript 3 is a bit better. Generally, there has been a move to have everyone use similar syntax's, and Adobe has gone so far as to define its standards and make them accessible and common. It does not take much to see how the ECMAScript implementation which is supported by a for-profit company is superior to the generalized one.

Christopher W. Allen-Poole
A: 

I think, language design (for normal languages, not brainfuck :) ) not matters. To make code readable you should follow standards, code conventions, and don't forget about refactoring.

Anatoliy
(Real) languages like J can be unreadable due to language design, no matter how well you code.
Chris Lutz
+1  A: 

I heard people say they can understand their python code a year later but not their XYZ code. Why?

Firstly, I don't think that people say that based solely on syntax. There are a lot of other factors to take into consideration, to name just a few:

  1. The fact that some languages tend to promote only one right way to do something (like Python), and others promote many different ways (Ruby for example, from what I hear [disclaimer: I am not a Ruby programmer])
  2. The libraries the language has. The better designed ones tend to be incredibly easy to understand without needing documentation, and this also tends to help remember. A language with good libraries will therefore make things easier.

Having said that, my personal take on Python is the fact that many people call it "executable pseud-code". It supports a wide variety of things that tend to appear in pseudo-code, and as an extension, are the standard way to think about things.

Also, Python's un-C-like syntax, one of the features that make it so disliked by so many people, also makes Python look more like pseudocode.

Well, that's my take on Python's readability.

Edan Maor
+1  A: 

IMHO, the more a computer language resembles a spoken language, the more readable it is. For extreme examples, take languages like J or Whitespace or Brainfuck... completely unreadable to the untrained eye.

But a language that resembles English can be more easily understood. Not that this makes it the best language, as COBOL can attest.

JRL
That's NOT true. Speaking and programming requires different kind of brain activity. Therefore different languages will be better for each of them. However, you've hit the right point: you should have trained eye to understand any language.
Pavel Shved
I'm not sure it should completely resemble a spoken language. At some point, having too many words gets in the way, your code should be succinct. If adding a few spoken words helps increase your ability to understand, or lessens the amount of programming characters that you need to remember, I believe that it is a good thing. Just don't go overboard trying to make it like English :-)
Topher Fangio
+1  A: 

I think it has more to do with the person writing the code rather than the actual language itself. You can write very readable code in any language, and unreadable code in any language. Even a complex Regular expression can be formatted and commented so as to make it easy to read.

Kibbee
+1  A: 

a coworker of mine use to have a saying: "You can write crap code in any language." I liked it and wanted to share today. What makes code readable? Here are my thoughts

  1. The ability to read the syntax of the language.
  2. Well formatted code.
  3. Meaningfully named variables and functions
  4. Comments to explain complex processing. Beware, too much commentes can make the code hard to read
  5. Short functions are easier to read than long ones.

None of these have anything to do with the language, it's all about the coder, and the quality of their work.

Jay
+2  A: 

To be honest when it comes to what makes a language readable it is really seems to boil down to a combination of simplicity and personal preference. (Of course - it is always possible to write unreadable code in any language if you try hard enough). Since personal preference can't really be controlled, it comes down to ease of expression - the more complicated it is in a language to use simple features, the more difficult that language is likely to be in general from a readability standpoint.

Streklin
+5  A: 

Code is readable when its written in a style of explicit "stating what you want to do". This only depends on the language in sofar

  • it allows you to express what you want (functional-programming!)
  • it doesn't emphasize on cryptical statements

The rest depends on the style you use to write code (even Perl can be understandable!), but certain languages make it easier to hacky statements.

Clear:

expr = if not (ConditionA and ConditionB) then  ...  else  ...

Unclear:

expr = (!(conditionA && conditionB)) ? ... : ...

Clear:

foreach line in lines:
    if (line =~ /regex/):
        // code

Unclear:

... if /regex/ foreach(@lines);

Clear:

x = length [ x | x <- [1..10], even x ]

Unclear:

int x = 0;
for (int i = 1; i <= 10; ++i)
    if ((i&&1)==0) ++x;
Dario
For the record, Perl won't allow something like `if /regex/ foreach(@lines)` - it only allows one postfix control statement. You cna work around this with `/regex/ and do_something() foreach @lines` but I agree that it's better to do it the other way. Also, Perl's `for` loops allow you to specify a variable, it's just that any real Perl programmer should know when and how to properly use `$_` - so the only real time there's anythng wrong with using `$_` is when you're learning Perl.
Chris Lutz
+2  A: 

Readability is a function that takes a lot of inputs. I don't think it's really possible to compile a full list of things that can affect a language's readability. The most general way to describe it is "minimizing cognitive load." A few major factors:

  • Subtleties of meaning. If two code snippets look very similar at a glance but do different things, it hurts readability because the reader has to stop and deduce what's actually happening.
  • Meaningless code — aka boilerplate. This doesn't necessarily mean code that does nothing, but code that doesn't tell me anything about what we're actually doing. Every bit of code that doesn't express the actual intent of a function or object reduces readability by that much.
  • Cramming meaning — aka golf. This is the opposite of the boilerplate problem. It's possible to compress code so far that the reader is forced to stop and examine it pretty much character by character. The exact line where this occurs is somewhat subjective (which is part of why some people love Perl and some people hate it), but it's definitely a real phenomenon.
Chuck
+1 for boilerplate. I **hate** it when I have to scroll through zillions of lines of it to get to the tiny section of code where the real logic is.
dsimcha
+3  A: 

The programmer makes code readable or unreadable, not the language. Thinking otherwise is just fooling yourself. This is because the only people who are qualified to judge readability are those who know the language. To the non-programmer, all languages are equally unreadable.

Adam Bellaire
I'm not sure I agree with that. Many languages have a syntax that allows an uneducated (at least with concern to programming) person to be able to read good code and have an idea of what it is supposed to do. Unfortunately, not everybody is a "good" programmer.
Topher Fangio
@Topher: I would argue that a "bad" programmer using a "readable" language could very easily write a solution that the uneducated person *thinks* they understand well, only to find later (at the worst possible time) that their understanding was quite wrong.
Adam Bellaire
A: 

Concerning the syntax, I think it it imperative that it be fairly descriptive. For instance, in many languages, you have the foreach statement, and each one handles it a bit differently.

// PHP
foreach ($array as $variable) ...

// Ruby
array.each{ |variable| ... }

// Python
for variable in array ...

// Java
for (String variable : array)

Honestly, I feel that PHP and Python have the clearest means of understanding, but, it all boils down to how smart and clear the programmer wants to be. For instance, a bad programmer could write the following:

// PHP
foreach ($user as $_user) ...

My guess is that you would have almost no idea what the heck the code is doing unless you tracked back and attempted to figure out what $user was and why you were iterating over it. Being clear and concise is all about making small chunks of code make sense without having to trace back through the program to figure out what variables/function names are.

Also, I would have to completely agree with whitespace. Tabs, newlines and spacing in-between operators really make a huge difference!

Edit 1: I might also interject that some languages have the syntax and tools readily available to make things more clear. Take Ruby for example:

if [1,2,3].include? variable then ... end

verses, say Java:

if (variable != 1 || variable != 2 || variable != 3) { ... }

One of these (IMHO) is certainly more clear and readable than the other.

Topher Fangio
A: 

The literacy level of the reader.

Lance Roberts
A: 

Two distinct aspects, really. First is syntax and whitespace. Python enforces a whitespace standard, dropping unnecessary {, } and ; characters. This makes it easy on the eyes. Second, and most importantly, clarity of expression- i.e. how easy is it to map code back to the way you think. There are several features (and non-features) in programming languages that contribute to the latter point:

  1. Disallowing jumps. The goto statement in C is a typical example. Code that doesn't keep running out of structured blocks is easier to read.
  2. Minimizing side-effects. Global variables are evil, remember?
  3. Using more tailored functions. How can your head track a for loop with 5 iteration variables? The Common Lisp loop is much easier to read (although VERY difficult to write, but that's a different story)
  4. Lexical closures. You can figure out a variable's value by just looking at it, as opposed to running the code in your head, and then figuring out which statement is shadowing which.

A couple of examples:

(loop
   do for tweet = (master-response-parser (twitter-show-status tweet-id))
   for tweet-id = tweet-id then (gethash in-reply-to tweet)
   while tweet-id
   collecting tweet)

and

listOfFacs = [x | x <- [1 ..], x == sumOfFacDigits x]
    where sumOfFacDigits x = sum [factorial (x `div` y) | y <- [1 .. 10]]
Ramkumar Ramachandra
There is no reason not to put `goto` in a language. No one will use it in real code due to stigma, unless it's obfuscated, just plain terrible, or they actually know what they're doing (in which case they'll document it).
Chris Lutz