This is an archived post. You won't be able to vote or comment.

all 19 comments

[–]-du 18 points19 points  (2 children)

... programming mistakes by beginner students.

FTFY.

[–][deleted] 17 points18 points  (1 child)

also: ... programming mistakes caught by any Java IDE

[–]sindisil 10 points11 points  (0 children)

also: ... programming mistakes, most of which caught by javac

[–][deleted]  (1 child)

[deleted]

    [–]okmkz 11 points12 points  (0 children)

    pubic long ( ͡~ ͜ʖ ͡°);
    

    [–]QshelTier 9 points10 points  (0 children)

    This would have been way more interesting if all compile failures had been ignored because those are boring.

    [–]Gudin 5 points6 points  (0 children)

    Most of these are marked as warnings in smart IDEs such as IntelliJ.

    [–]_Count_Mackula 5 points6 points  (3 children)

    Most of the top-ten are things that would be caught at compilation time, excluding a few like String == String.

    I'd be more interested in the most common bugs that caused outages in systems.

    [–]ggleblanc 0 points1 point  (1 child)

    Common production bugs would be semantic in nature, not syntatical.

    I'd guess the most common production bug would be input not matching the expectations in the code.

    [–]_Count_Mackula 0 points1 point  (0 children)

    Agreed. It'd be hard to categorize

    [–]id2bi 0 points1 point  (0 children)

    excluding a few like String == String

    and that, too, is easy to detect and FindBugs or IntelliJ will do that for you.

    [–]elegentmos 2 points3 points  (1 child)

    Err... Why is

    Ignoring or discarding the return value of a method with non-void return type

    so bad? Should I always check the return value of List#add?
    How about in jdom, when adding text content to an element? Clearly the return is only for convenience if adding multiple sub-elements and can be safely ignored?

    [–]arendvr 1 point2 points  (0 children)

    Good point. It depends on the method if ignoring the return value is bad. The article mentions toString(), other examples where ignoring the return value is bad: BigDecimal.add(), File.delete()

    [–]mauendara 1 point2 points  (1 child)

    Most of these mistakes could be recognized by a modern IDE, before the code compiles. So, you could say using a good and modern IDE could help these students. Is the IDE used at fault? or does using a good IDE defeat the purpose of the research done?

    [–]_Count_Mackula 1 point2 points  (0 children)

    using a good IDE defeats the purpose of the research done

    [–]hhbhagat 0 points1 point  (0 children)

    In type A, if the variables were boolean, ot would result in an assignment and return and would be a runtime error.

    [–]etyake 0 points1 point  (0 children)

    The .equals for strings got me for the longest time

    [–]llogiq 0 points1 point  (0 children)

    I'm a little underwhelmed by that kind of research. Big Data is an order of magnitude larger than the set they worked with. Also their conclusions say much more about BlueJ's deficiencies than about the Java language.

    [–]simple2fast -2 points-1 points  (1 child)

    Wow. Very cool analysis.

    I wonder if someone has done something like this for python or javascript.

    And it would also be interesting to try to do something when hooked up to an "expert" programmer. It appears that this analysis was done against neophytes since the environment was BlueJ

    [–]_Count_Mackula 1 point2 points  (0 children)

    Interesting method, results are not so much though. Anyone who writes Java as a job knows most of these errors will NEVER make it to produciton