Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Programming

How Experienced And Novice Programmers See Code 238

Posted by Unknown Lamer from the m-x-run-direct-neural-interface dept.
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.
This discussion has been archived. No new comments can be posted.

How Experienced And Novice Programmers See Code More

How Experienced And Novice Programmers See Code

Comments Filter:

  • Code? (Score:5, Funny)

    by Anonymous Coward on Wednesday December 19, 2012 @02:52PM (#42338547)
    I see Blonde, Brunette,...

  • Contacting Server... (Score:5, Funny)

    by localman57 ( 1340533 ) on Wednesday December 19, 2012 @02:56PM (#42338587)
    At this moment, novice programmers think the network is down. Experienced programmers know the site from TFA has been slashdotted.

  • Comments (Score:5, Interesting)

    by JesseMcDonald ( 536341 ) on Wednesday December 19, 2012 @02:59PM (#42338619) Homepage

    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)

      by Anonymous Coward on Wednesday December 19, 2012 @03:07PM (#42338703)

      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)

        by dgatwood ( 11270 ) on Wednesday December 19, 2012 @03:20PM (#42338859) Homepage Journal

        Comments that describe what the code is doing are useless. Comments that describe why the code does what it does are invaluable.

        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)

          by bws111 ( 1216812 )

          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).

        • 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)

          by Bomazi ( 1875554 )

          This is comment on a single line of code taken from qemu/hw/ds1338.c:

          /* Attempting to write the OSF flag to logic 1 leaves the value unchanged. */
          data = (data & ~CTRL_OSF) | (data & s->nvram[s->ptr] & CTRL_OSF);

          Would you say that it is useless ?

          • Re: (Score:2)

            by suutar ( 1860506 )
            Well, I wouldn't comment it that way; I'd do "Attempting to write the OSF flag to logic 1 leaves the local value unchanged so update the local value by pulling that bit out of the nvram buffer" or some such. But maybe I'm too verbose.

      • Re:Comments (Score:5, Funny)

        by Sperbels ( 1008585 ) on Wednesday December 19, 2012 @03:21PM (#42338865)
        You don't find this useful?

        //if Foos is empty don't do anything
        if (Foos != null)
        //let's go through the collection and increment the counter
        foreach (Foo foo in Foos)
        //increment the count
        foo.count++;

    • Re:Comments (Score:5, Insightful)

      by Trepidity ( 597 ) <delirium-slashdot@@@hackish...org> on Wednesday December 19, 2012 @03:09PM (#42338721)

      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.

      • 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)

      by Anrego ( 830717 ) * on Wednesday December 19, 2012 @03:16PM (#42338809)

      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.

      • 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)

          by Anrego ( 830717 ) * on Wednesday December 19, 2012 @05:11PM (#42340667)

          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.

          • 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

      • A comment explaining why a line of code is commented out also never hurts.

    • 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

      • 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

        • 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.

      • You think comments are useless because you write shit comments.

        Actually, that's harsh. Why single the comments out?

      • A snippet from the Linux kernel which goes the other way:

        /*
        * The EFI specification says that boot service code won't be called
        * after ExitBootServices(). This is, in fact, a lie.
        */

    • Re: (Score:2)

      by purplie ( 610402 )
      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.

      • 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.

      • unless your program in written in brainfuck [wikipedia.org]

    • Re: (Score:2)

      by bluFox ( 612877 )
      Did you know that similar to the previous study, another effect found was that expert programmers rarely if ever look at code comments. On the other hand, novices spent majority of their time on comments if they are available instead of looking at the code. I can find the citation a little later since I don't have access to my bib db right now.

  • Motivation and experience make the difference (Score:5, Interesting)

    by davidwr ( 791652 ) on Wednesday December 19, 2012 @03:01PM (#42338635) Homepage Journal

    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)

    by loufoque ( 1400831 ) on Wednesday December 19, 2012 @03:03PM (#42338661)

    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)

      by Anrego ( 830717 ) *

      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.

      • Most of them didn't even heard about diff...

      • Re: (Score:3)

        by Quirkz ( 1206400 )
        Worse, if you're like me and only had maybe a semester of programming at school while pursuing another degree, and then got into it as a hobby, you're VERY unlikely to even know you should go looking for things like official version control and bug tracking tools or systems. You learn enough to do what you want, but you don't know what you don't know, and some of those things can be critical.

    • Re:Novice programmers overwhelmed (Score:5, Insightful)

      by Ignacio ( 1465 ) on Wednesday December 19, 2012 @03:25PM (#42338919)

      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.

      • 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.

    • 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

      • Most people with little or no experience with debuggers wait for the program to segfault and then ask for the stack trace.

  • Obligitory (Score:2, Funny)

    by 0racle ( 667029 )
    I don't even see code anymore. All I see is Blond, Brunette, Redhead ...

  • Matter of perspective (Score:5, Interesting)

    by sl4shd0rk ( 755837 ) on Wednesday December 19, 2012 @03:10PM (#42338737)

    A Novice sees it done wrong
    A Master sees it done differently

    • 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)

      by Aaden42 ( 198257 )

      A veteran sees it done OMGWTF were you thinking you fskck343ing moron!???!???

    • A novice sees the code not compiling.
      A master sees it compiling differently?
      WTF...

  • Alternate blog post (Score:5, Informative)

    by Necroman ( 61604 ) on Wednesday December 19, 2012 @03:10PM (#42338741)

    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)

      by Ibiwan ( 763664 )
      How weird. You'd think they'd use the same code for each category, in order to make a valid comparison...
      ...or if they did that, they'd post youtube videos properly reflecting that!

      • Re: (Score:2)

        by et764 ( 837202 )

        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

        • 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)

            by et764 ( 837202 )
            Sure. The study isn't complete though. He's planning to gather data for all of next semester. Hopefully by then he'll have enough to draw meaningful conclusions.

  • I'll hazard a guess: (Score:4, Insightful)

    by obarthelemy ( 160321 ) on Wednesday December 19, 2012 @03:23PM (#42338885)

    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)

    by assertation ( 1255714 ) on Wednesday December 19, 2012 @03:25PM (#42338917)

    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)

      by andy16666 ( 1592393 )
      I wouldn't trust anyone to know what they look at when they read code. Not because I think they're lying, but because other research shows that people often have no idea how they perform complex tasks. So I'd be very skeptical if even your most candid account of how you code or how you read code showed much correlation to how what you actually do when you perform these tasks.

      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,

    • 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)

    by idealistw ( 2798599 ) on Wednesday December 19, 2012 @03:39PM (#42339085)
    Just a FYI, the test is really poorly done because the code that the novice and the expert are looking at are different. I can read the Expert's code and figure out what the output should read in no time. The inlined code, on the other hand, I have to do the full iteration for each loop. It's really a test fail.

    • Re: (Score:3)

      by et764 ( 837202 )
      These are just two participant's answers. Each program in the test has several variants, and each participant gets one variant at random. The goal is to get enough people to gather meaningful statistics. This will include having both novices and experts doing each of the variants in the videos posted here.

  • Gimme a break... (Score:3, Interesting)

    by Elminster Aumar ( 2668365 ) on Wednesday December 19, 2012 @03:44PM (#42339179)
    Any tutorials or articles, etc. that start out referring to someone as "newbie", "newb", etc. should be automatically labeled as worthless. Every team of programmers--it doesn't matter if it's a team of 2, 10, 50...--always has someone that can be called a "weak link" simply because you're always going to have someone who just isn't as fast or efficient as everyone else. And if programming is more of an art form (which I personally believe it is due to having millions of ways to skin cats), then it's apt to claim that nobody can be as good as everybody. Everything depends on what exactly is being done, what technologies are being used, frameworks, functions, who's involved, what business logic is required, what data is being worked with, etc., etc., etc. I've seen people who sucked at back-end stuff rock it out with front-end and others, vice-versa. I've seen people excel with certain technologies turn around and completely blow with others but one reason some of these supposed GODS suddenly sucked has nothing to do with their understanding or capabilities but instead almost always had to do with how their resources were being used... There is no such thing as a newbie. It's an epiphany brought about by someone's nerby boner culture. Constantly using the phrase "newbie" and all that other juvenile bullshit is old news and something someone does when they're bored and looking to put people down just to make themselves feel better about their world. Stop referring to people like this because some of the most seasoned people could be painted with that brush depending on how you view things...

  • such a shame (Score:4, Funny)

    by Dark$ide ( 732508 ) on Wednesday December 19, 2012 @03:47PM (#42339225) Journal
    An article that could have been astounding is on a site that got Slashdotted. Perhaps they need some experienced web programmers.

  • 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]

Slashdot Top Deals

Love may laugh at locksmiths, but he has a profound respect for money bags. -- Sidney Paternoster, "The Folly of the Wise"

Close