How Experienced And Novice Programmers See Code 238
Esther Schindler writes "We always talk about how programmers improve their skill by reading others' code. But the newbies aren't going to be as good at even doing that, when they start. There's some cool research underway, using eye tracking to compare how an experienced programmer looks at code compared to a novice. Seems to be early days, but worth a nod and a smile."
Reader Necroman points out that if the above link is unreachable, try this one. The videos are also available on YouTube: Expert, Novice.
Code? (Score:5, Funny)
Re:Code? (Score:5, Insightful)
Re: (Score:3)
I see lack of comments, lack of comments, and god damned polish notation.
Hungarian notation? I assume because of the "lack of comments".
Re:Code? (Score:5, Funny)
I see lack of comments, lack of comments, and god damned polish notation.
Hungarian notation? I assume because of the "lack of comments".
aHungarian nnotation? nI vassume abecause cof cthe alack cof ncomments
FTFY
Re: (Score:3)
Re: (Score:3)
DontYou_hateThose_nProgrammersWho_just_use_whats_con_feckin_venient?
Link to google cache and video (Score:2)
View: http://www.youtube.com/watch?v=Jc8M9-LoEuo [youtube.com]
Cache:
http://webcache.googleusercontent.com/search?q=cache%3Asynesthesiam.com%2F%3Fp%3D218&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a [googleusercontent.com]
Re: (Score:2)
aHungarian nnotation? nI vassume abecause cof cthe alack cof ncomments
FTFY
Did you mean:
aHungarian nnotation? nI vassume abecause pof a'the nlack pof ncomments
Re: (Score:2)
In weakly-typed languages such as JavaScript, it certainly helps
Unless you grew up on Smalltalk and therefore know that this fetish is useless anyway.
Re: (Score:2)
This [wikipedia.org] is what he's talking about.
About fifteen years ago one of the PC (politically correct) clowns ragged my boss at a lunch for saying something about reverse polish notation because she thought it was a pollack joke! He and I had a good laugh about that one.
Re: (Score:2)
There's something fishy about that statement.
Re: (Score:2)
What is polish notation? Did you mean Polish notation?
Re: (Score:2)
polish: what you do to make wood shine
Polish: having to do with people or things from Poland
Re:Code? (Score:4, Insightful)
Polish: Making wood shine at the beginning of a sentence.
Re: (Score:2)
True. However, the word in question was in the middle of a sentence:
"... and god damned polish notation."
Re: (Score:2)
That's why it'd be better to call us Polacks rather than wood shine and the stuff strippers dance around.
Re:Code? (Score:5, Informative)
Polish notation is the one where it looks like Yoda speaking. Hungarian is where it looks like R2D2 dictated it.
Re:Code? (Score:5, Insightful)
An experienced coder just sees everything as unintelligible crap that only a moron would write.
Re: (Score:3, Insightful)
I feel immense shame, horror and bewilderment when I look at my old code. Did I really write this rubbish?
Re: (Score:2)
Contacting Server... (Score:5, Funny)
Re: (Score:2)
Re:Contacting Server... (Score:5, Funny)
Re:Contacting Server... (Score:5, Funny)
We read the article, just not before we comment. Usually I middle-click to open the article in a new tab, then read the comments. That way I know which parts of the article to indignant about when I get to them.
Re:Contacting Server... (Score:5, Funny)
TFA? I usually say FTA and comment away...
Re: (Score:2)
If nobody reads TFA then why is it down, and how does anyone here know it's down?
FTR, I read it. It was mildly interesting, but not overly so. This one's safe to discuss without reading TFA.
Re: (Score:3)
Heh heh heh.
And then there are dumb programmers. I was working on a server product, which could be accessed by a browser. IE something.something used to put up a generic "... or contact Microsoft support" message when the server being contacted wasn't responsive. We were debugging a server, so of course it wasn't responsive. This dummy was seriously arguing with me that the right course of action was to call Microsoft support.
(He wan't a novice. He was experienced, in the sense that he has been pressing but
Re:Contacting Server... (Score:5, Funny)
Re:Contacting Server... (Score:5, Funny)
You mean the enemy's gateway is down...
Re: (Score:2)
Holy crap, a Slashdotting. I thought those days were long gone.
Re: (Score:2)
Re: (Score:3, Informative)
My network admins were obviously not prepared for Slashdot.
Re: (Score:2)
Comments (Score:5, Interesting)
I imagine one of the first things a programmer learns about reading code, if they're going to be any good at it, is to skip over the inline comments. Reading them will only prejudice your interpretation of the code in favor of the original authors expectations, preventing you from seeing what the code is actually doing.
Comments are useful when you come across a block of code you can't otherwise understand, but the rest of the time they tend to either duplicate information which is already in the code, or confuse matters by being vague, misleading, or just plain wrong.
High-level documentation of modules and functions is invaluable, of course, but those comments should be in a block of their own, or even a separate file, and not be mixed in with the rest of the code.
Re:Comments (Score:5, Insightful)
Comments that describe what the code is doing are useless. Comments that describe why the code does what it does are invaluable.
Re:Comments (Score:5, Insightful)
Depends on the level of granularity. Comments that describe what a single line of code does (or even a small number of lines of code in many cases) are useless.
Comments that describe the behavior of a suitably large block of code (e.g. a function or a block within a particularly complicated function) can help you quickly understand the structure of a program as a whole. This is critical when working with sufficiently large bodies of code, because you're unlikely to have time to read every line of code before you start hacking away at it. For sufficiently complex projects, they can also be pulled out by tools such as HeaderDoc or Doxygen and converted into documentation.
At a semi-coarse granularity, comments that tell you what a block of code within a function does can make it much easier to find the code you need to change when something doesn't work. Thus, even those comments can be useful, so long as each comment covers at least a handful of lines of code and so long as the "what" isn't instantly obvious at a glance.
Re: (Score:3)
I think there are cases where a comment on a single line is very worthwhile. In particular, when it is not obvious why such a line would be there (eg This is here because sometimes device xxx produces incorrect input - don't mess with it).
Re: (Score:2)
Comments that describe what a single line of code does (or even a small number of lines of code in many cases) are useless.
If you're writing a line of code that works around language or system quirks, produces unexpected side effects, or just plain looks intuitively wrong, the next guy is really going to appreciate it if you comment that thing.
Of course, if you write " /* sets A equal to B */" then he's going to duck tape a dead fish to the bottom of your office chair.
Re: (Score:3)
This is comment on a single line of code taken from qemu/hw/ds1338.c:
Would you say that it is useless ?
Re: (Score:2)
Re:Comments (Score:5, Funny)
if (Foos != null)
foreach (Foo foo in Foos)
foo.count++;
Re:Comments (Score:5, Funny)
I see we had the same college TAs and professors.
Re: (Score:3, Funny)
No, this is what I get to read // Add 2 seconds to the timer because 1 second is way too short for this situation
timer.add(90);
Re: (Score:2)
Errors in the comments (s/increment/decrement/) would have been a nice touch.
Re:Comments (Score:5, Insightful)
If I'm reviewing untrusted third-party code, or code which is suspected to be buggy, I agree, but it really slows things down, even at an expert level, to completely ignore comments, if it's a setting where I'm working with people I know to be good engineers, and am not actively debugging/auditing their code. There has to be some amount of trust to make large projects work, and trusting that my colleagues are writing sane and reasonably accurate comments is one form of it. If it turns out to be wrong in a certain case, well, that's what tests are there to discover.
Re: (Score:3)
It depends on how well structured the code is. If the functions are small and simple, then the function-level comments should be sufficient in most cases. It's OK to rely on a function doing what the comments claim it should do while reading higher-level code. I don't expect people to review the code for strcpy() every time it's used.
On the other hand, if you're reviewing code with large, monolithic functions, it may need some comments inside the function (roughly where the function boundaries should be) to
Re:Comments (Score:5, Insightful)
Those inline comments are good (when done properly) when trying to quickly grok through a large codebase. That "done properly" bit is important. Obviously a comment that just states what the following line does is pointless.. but a one liner generalizing a 9 or 10 line block of code means 9 or 10 lines of code you can skim over.
Obviously if troubleshooting code or auditing you want to focus on the code, but then the comments still serve as a good tool to indicate potential problems by as you said, showing what the authors intention was. If the code doesn't match the comment.. the code might very wlel be wrong.
Re: (Score:2)
Those inline comments are good (when done properly) when trying to quickly grok through a large codebase. ... a one liner generalizing a 9 or 10 line block of code means 9 or 10 lines of code you can skim over.
Agreed, but often those 9 or 10 lines could be refactored into a separate function, which would allow the inline comments to be replaced with function-level documentation. The general rule is to break up functions at no more than twice that size, where feasible.
Re:Comments (Score:4, Interesting)
I actually find in some cases this reduces readability.
If it's a very encapsolated chunk of code or a chunk that can be reused elsewhere and has a very clear "x goes in, y comes out" feel then fine. At a certain point though you end up with a bunch of functions that are only called from one spot, are too specific for reuse, and the only thing you gain is a requirement for the programmer to do a lot of scrolling. You also add overhead, but I'm not one to mind a little overhead for maintainability.
Much as it goes against a lot of traditional teaching and widely held rules, I tend to think that sometimes a large function actually ends up being more readable because the programmer can just read through step by step what is happening without the need to jump around.
Re: (Score:2)
I'll admit that I've seen some cases like that myself. In the absence of a decent abstraction boundary, there's no point in breaking a function up such that you still need to know the inner details of several parts to understand any of them. The point is to abstract away the details, not just split the code up to avoid exceeding some arbitrary line count. However, I would still say that it's possible to write most programs, readably, in terms of functions averaging less than 20-30 lines each.
(I routinely wo
Re: (Score:2)
A comment explaining why a line of code is commented out also never hurts.
Re: (Score:2)
It's commented out because it has //, /* */, or whatever the particular language uses for comments. Duh.
Re: (Score:2)
Re: (Score:2)
Believe it or not, that's very informative. That tells you it's redundant, rather than risky or damaging.
Re: (Score:3)
Comments Lie, Code Doesn't
Every once in a while I see some well commented code, and it leads to to a massive blunder because the comments are wrong.
Some of the ones have got me. /**
Save Starts Here
**/
Which I figured would be a good part to add save my changes. /**
After testing and realized it didn't work correctly I changed the comment to.
Real time check to insure data is correct
**/
In an other function 500 lines down. I added /**
Saves data after authenticated as formatted correctly
**/
Another good one was in
Re: (Score:2)
This only happens because people ignore that comments are important.
Or, put another way: the code isn't finished until it's documented. Sure, it runs, but it's not COMPLETE.
A sloppy programmer that programs bugs into code is the same a sloppy programmer that doesn't update the comments.
In any case, comments aren't a replacement for reading the code, they're to help you quickly interpret the code and the INTENT of the programmer that put it there. Documenting the algorithm is much more useful than documentin
Re: (Score:2)
The best code doesn't need a single line of comment, because it's written clearly enough.
It should be terse, have functions and variables have meaningful (but not too long!) names, obvious structure, use just the right amount of syntactic sugar but no more, etc.
Re:Comments (Score:4, Informative)
People who preach self-documenting code can't write good comments. They frequently don't write great code either.
Code tells me what it does. It tells me jack-fuck-shit about why it does it that way.
Re: (Score:2)
If that's not obvious, it's a valid use for a comment. What is wrong are those "no shit, Sherlock" comments that pepper most code bases.
Re: (Score:3)
You think comments are useless because you write shit comments.
Actually, that's harsh. Why single the comments out?
Re: (Score:3)
* The EFI specification says that boot service code won't be called
* after ExitBootServices(). This is, in fact, a lie.
*/
Re: (Score:2)
Re: (Score:2)
Comments aren't supposed to (redundantly) tell you what the code does. They're to tell you why the code had to be written, or the reason one coding choice was made over another, or known issues and todos.
Not all code is quite as self-evident as that. Even in the less cryptic languages. However, I agree that when the comments are redundant, they are not merely useless, they add noise to the equation.
Most comments - as I and others here have often noted - shouldn't be telling "what" code does, but why it is doing it and what it produces.
Re: (Score:2)
unless your program in written in brainfuck [wikipedia.org]
Re: (Score:2)
Re: (Score:2)
Motivation and experience make the difference (Score:5, Interesting)
My personal story:
When I was but but a wee lad skill-wise, I read other people's code so I could figure out how it worked. I knew WHAT it was doing, just not HOW.
Now when I read other's code it's usually either to figure out what it's doing or, more likely, what it's NOT doing that it's supposed to be doing.
There's another difference:
Now I can skip over the code that isn't "interesting" and zero in on where I think the bug is or where I think the "undocumented feature" is. My younger self had the luxury of time to study every line and learn as he did so.
By the way, when I'm trying to learn something totally new, I do revert to "the way of the young learner." Why? Because it works when I'm starting nearly from scratch.
Novice programmers overwhelmed (Score:4, Insightful)
Novice programmers are simply overwhelmed by vast amounts of code, and have no idea how to do large-scale software development.
When you teach them about tools that allow you to find your way through the code, they're all impressed.
Universities simply aren't teaching these boys right.
Re: (Score:3)
I'll agree this is something I've seen.
Even simple stuff like version control and bug tracking.. a lot of guys coming out of school who have never even heard the terms, much less learnt how to employ them effectively.
But then it comes down to the whole "university isn't a trade school" thing, even though most people taking computer science are aiming to be coders.
Re: (Score:2)
Most of them didn't even heard about diff...
Re: (Score:3)
Re:Novice programmers overwhelmed (Score:5, Insightful)
Unfortunately if you give them the most advanced tools possible then they never actually *leave* the novice state since they're too used to their tools doing all the work for them.
Re: (Score:2)
Then that means they're bad tools.
Good tools are loosely-coupled, easily combined, scalable, adaptable and programmable.
An IDE, if that's what you meant, is definitely not a good tool.
Re: (Score:2)
Many of these tools will overwhelm the novice by themselves.
You give a novice a debugger they will put their break point on line 1 (or int main(char argc, char **argv) )
and step through every freaking line in the program until completion. You give the tool to an expert even if they have never used a debugger before (they probably got by by putting random print statements in) they will put break points right where they expect the code to break, or to a function that they are unable to handle in their heads.
T
Re: (Score:2)
Most people with little or no experience with debuggers wait for the program to segfault and then ask for the stack trace.
Re: (Score:2)
Advanced debugging involves using break points, stepping, and printing current value of variables.
Re: (Score:2)
All you do with an IDE you can do better by combining dedicated tools together.
As IDEs go, Eclipse is pretty decent though. Almost usable.
Any case, whatever makes you more productive is fine, as long as you know the tools well enough to adapt them to any situation.
Obligitory (Score:2, Funny)
Matter of perspective (Score:5, Interesting)
A Novice sees it done wrong
A Master sees it done differently
Re: (Score:2)
A Novice sees it done
A Master sees it done differently or done very wrong
This has been my experience working with a wide range of experience levels (although the transition isn't quite linear). There are many ways to do things that are still good, but sometimes that code should never have existed.
Re: (Score:3)
A veteran sees it done OMGWTF were you thinking you fskck343ing moron!???!???
Re: (Score:2)
A novice sees the code not compiling.
A master sees it compiling differently?
WTF...
Alternate blog post (Score:5, Informative)
The guy who was tested in the video has a blog post up (and his server actually works): http://blog.theincredibleholk.org/blog/2012/12/18/how-do-we-read-code/ [theincredibleholk.org]
Direct youtube links to the videos:
Video 1 [youtube.com]
Video 2 (Novice) [youtube.com]
Re: (Score:3)
Re: (Score:2)
The experiment is testing several things. The primary thing is to see if different ways of writing a program lead to quantifiable differences in how programmers understand the code. This is why the novice saw a version with the functions inlined while I saw the version with function calls. The system just gives each person one of several variants for each program at random.
A secondary effect is to measure how novice and experienced programmers differ. This relies on having plenty of people so that you end u
Re: (Score:2)
I don't think Mike had a video of a novice with the same variant I had, so he posted a different variant instead.
Which raises the question: if the sample size is so small that some combinations weren't even tested, then how can we draw any concrete answers from it?
If what you said is correct (or he only had 1 or 2 such videos), then all this really tells us is how these specific programers read these specific source code samples.
Re: (Score:2)
I'll hazard a guess: (Score:4, Insightful)
Young programmers see code as a way to show how good they are
Old programmers see code as something that puts money in the bank.
What off topic ?
Skipping (Score:5, Informative)
I don't know if this correct or PC, but when I first started I read code like a book. Every single word, left to right, down to the next line.
Now I skip.
I look where arguments go in, where they come out, where functions are called.
If I go into a code block, I look where the result is first and back track as needed
I look at the connections and only go deeper when I need to.
If I have to read legacy procedural code, I do what I do when I read the web. I ignore sub levels of information until I finish a level. On a web page I read the content, ignore the side bars and I don't click on links until I am done with that page. In procedural code I read top down and ignore nested blocks until I see what is going on the first level.
Re: (Score:3, Insightful)
This is one of the things that makes teaching so difficult. If it were just a matter of explaining what you do, it would be simple,
Re: (Score:2)
Some eyetrackers measure rapid eye movements that are mostly unconscious. In other words, you don't really know what your eyes look at in the flick of a second. If you first wear one of those head-mountable eye trackers and a woman is nearby it can be embarrassing and amusing to everyone. Or, so I've been told. I haven't tried one myself yet.
The Inlined code is more difficult to read. (Score:4, Funny)
Re: (Score:3)
Gimme a break... (Score:3, Interesting)
such a shame (Score:4, Funny)
Another Mirror (Score:2)
Mike just posted a mirror of his post on another server. Hopefully this will hold up better under load.
http://www.cs.indiana.edu/~mihansen/modeling-programmers.html [indiana.edu]
Re: (Score:2)
That's actually pretty scary.
Re: (Score:2)
It's different because significantly more of the processing and display logic is distributed to the clients. Additionally clients have local storage and processing capacity which if programmed correctly may continue to operate in some fashion in the face of network failure.
Also, it's not freaking COBOL, not that I find Ruby or Python much preferable (Aaaaand there goes my good karma)
Re: (Score:2)
The algorithms required to make a mainframe work vs. a distributed system are vastly different. Your failure to recognize this is probably why your thoughts are outdated.
Mainframes are distributed systems in a big iron box. There's a reason you can hot swap CPUs and RAM in a mainframe. It's because everything is redundant, distributed, and aware of other components.
The cloud is mainframe that sacrifices speed for physical separation (to prevent failures due to loss of power, or disasters). The algorithms are only "vastly different" if you're too dumb to see past IPv4 and understand what the damned thing is actually doing and why.
Re: (Score:2)
> I would say that this is similar to a chessmaster who has solved countless chess puzzles.
Chess masters recognize patterns in chess like they recognize faces. Show them a realistic pattern for a few seconds and they can remember it. Show them a random pattern and they won't remember it.
You can test this with programmers. Create a pattern, e.g. a common for loop:
for( int i = 0; i 10; i++ )
{
print i;
}
Show this to a person for a couple of seconds and ask them to rewrite it out from their mem