back to article Facebook: Your code sucks, and we don't even have to run it to tell

Facebook has released the source code to Infer, its static analysis tool, under the open source BSD license. Static analysis tools like Infer are used as a complement to traditional dynamic software testing by scanning the source code of software to spot trouble spots without actually executing the code. In a Thursday blog …

  1. Anonymous Coward
    Anonymous Coward

    Finally some serious stuff.

  2. Mark 85

    1% Finished?

    I'm wondering if they hope the open source community will finish it for them? A better tool that won't cost them any more than they have already spent.

    1. DanDanDan

      Re: 1% Finished?

      That's kinda the point of Open Source. We all (developers) need a good tool to check our code, so let's *all* work together on it to share the resource investment so we can *all* benefit. I like it. What's your criticism? They've done 1%, now all we need is another 99 companies to come along and work on it and it'll be done. I don't think that's unfair.

  3. Anonymous Coward
    Facepalm

    "Each month, hundreds of potential bugs identified by Facebook Infer are fixed by our developers..."

    What's a potential bug?

    1. Destroy All Monsters Silver badge
      Holmes

      That's a bug that is not apparent, for example a null-pointer exception that has not manifested yet. It generally indicates the use of imperative languages firmly rooted in the 60s, scant knowledge of development hygiene and/or the presence of hot-shot programmers who are actually too green to know what they are doing.

    2. Anonymous Coward
      Anonymous Coward

      And how many bugs remain undetected? Sure seems like a lot.

    3. razorfishsl

      Anything coded in Filemaker

    4. Michael Wojcik Silver badge

      Well, you can have a "potential bug" if you have a code path containing an invalid operation that's not reachable in the system as it now exists, but could be made reachable by a future change, for example. I see a lot of these in real-world code, particularly in rarely-exercised branches like error handling for failure modes that are difficult to reproduce. You can also find them in partly-implemented features that aren't enabled yet and so forth.

      Another example is code that relies on unspecified behavior which may change, e.g. due to a toolchain upgrade or changes in build configuration. Use of uninitialized variables in C programs is a typical example - often the actual run-time behavior will be different in "debug" and "optimized" builds.

      One of the benefits of static analysis (over dynamic analysis1) is that it can identify possible bugs in such dormant code, before they're activated by changes during maintenance and enhancement.

      1Which of course has its own advantages over static analysis.

  4. David Schmidt

    Nothing like reinventing the wheel...

    Findbugs? PMD? etc. etc. .etc... Sure am glad they didn't contribute to any already existing framework.

    1. streaky

      Re: Nothing like reinventing the wheel...

      Assuming that the existing tools are actually fit for purpose much? It's surprising how sometimes you start with a tool; thinking you're gonna modify it to be better and end up just starting from scratch because what's there is either crap or you can't get it to do what you want.

      Then again even when you do some projects pointedly refuse to accept submissions.

      1. AMBxx Silver badge
        Big Brother

        Re: Nothing like reinventing the wheel...

        But the existing tools don't insert facebook tracking code into otherwise innocent code.

        I'll get my tinfoil hat.

    2. Michael Wojcik Silver badge

      Re: Nothing like reinventing the wheel...

      Even the fastest static-code analyzers for C-family procedural languages can't offer the kind of speed Facebook is claiming for Infer on large code bases. That's rather the point of what they're claiming as innovative (separation logic and bi-abduction; read the materials linked in the article). Static checkers like cppcheck are plenty fast enough for a separate check stage, but not really fast enough for continuous near-real-time operation while programmers are writing code. Infer might be.

      Personally, I'm not terribly fond of real-time error detection in the IDE while I'm writing code, but a lot of developers seem to like it. So that appears to be fairly novel and valuable to some people.

      And Findbugs is for Java, and PMD only does source analysis on Java, Javascript, and a few other targets, so they're really not comparable anyway. Splint or cppcheck would have been better examples.

  5. Terafirma-NZ

    And yet the app still continues to jump to the top halfway through reading something because there is a new post.

    Having a tool like this shows that it must be a group of teenagers writing code and some poor devs got sick of fixing the same problems over and over again I mean you wouldn't build a tool like this if every bug was new and unique but rather because the same issues kept being repeated.

  6. This post has been deleted by its author

    1. ratfox
      Terminator

      Re: I hope they ran the tool on itself.

      Nice try, human.

  7. Douchus McBagg

    heh, the potential for an upsell

    so

    "Each month, hundreds of potential bugs identified by Facebook Infer are fixed by our developers before they are committed to our codebases and deployed to people's phones,"

    could they sell this to google then?

  8. Michael H.F. Wilkinson Silver badge
    Joke

    And once they add the GPP* feature to it

    it might commit hara-kiri on seeing some of the code I have had to grade, and, to be brutally honest, have written at some points in time. Scientific code is often VERY ugly (but, hey, the article is documentation enough, isn't it? ;-) )

    *GPP: Genuine People Personality is a registered trademark of Sirius Cybernetics. Please only use after clearance with the Sirius Cybernetics Complaints Division. Share and Enjoy!!

    1. DNTP

      Scientific code is often VERY ugly

      This is true as heck and I am one of those scientists horribly guilty of this. Code written for a one-off project? Yup. That's completely undocumented? Check. That somehow gets migrated onto the pipeline server as a shortcut for other people who don't know ANY programming? Obviously.

      Hello world, I'm sorry for doing this but there was no other way (except hand annotating result tables with tens of thousands of lines).

      1. Michael Wojcik Silver badge

        Re: Scientific code is often VERY ugly

        I'll let you in on a secret: business code is often very ugly, too. There might be a lower incidence of one-off programs that end up reused after all, but all the other ills of poorly-written software are common.

        Writing maintainable software is in some respects like every other sort of writing: doing it well means a lot of additional work, including organizing, drafting, rewriting (anathema to many programmers), and so on. In fact, you can take many models for the text-writing process, or similar models such as Aristotle's rhetorical canons, and find close equivalents for aspects of creating maintainable software.

        In other ways, of course, writing software is very different from writing prose. But programmers often forget that when they write software, they're writing for two audiences - machine and human - and neglect the latter.

  9. Olius

    "Please do our homework for us"

    This is very funny...

    "Facebook says it's releasing Infer as an open source project now in hopes that community participation will help it advance the tool beyond its current state, which its engineers describe as "1 per cent finished." "

    Translation - "We tried to reinvent the wheel without realising how hard this problem is to solve and we got the the end of our knowledge on the subject. Help?"

    1. Michael Wojcik Silver badge

      Re: "Please do our homework for us"

      If you'd read (and understood) the linked material on separation logic and bi-abduction, you'd know how wrong you are. But I realize it's easier to be rude than correct.

      1. Olius

        Re: "Please do our homework for us"

        You're right, I didn't read them. I was making a funny from the fact that the article states that there are several more complete, though slower, tools out there for this (hence they are reinventing the wheel) and that facebook themselves admit that this tool is only 1% complete (implying they are trying to reinvent an incredible complex wheel)

  10. Doctor_Wibble
    Pint

    It's all true!

    You don't have to run code to know if there are bugs in it. If there's more than around ten lines of code, it has bugs.

    Job done, you're welcome, please deliver my £64,000 consultancy fee in small notes via wheelbarrow and preferebly during a light breeze for maximum effect.

    Beer icon, because that's what money is for. And pies.

    And chips, followed by coffee and cake to make my five-a-day.

    1. Hans 1
      Coffee/keyboard

      Re: It's all true!

      >You don't have to run code to know if there are bugs in it. If there's more than around ten lines of code, it has bugs.

      You must be working for Adobe ... on the flash plugin, maybe ?

      1. Doctor_Wibble
        Facepalm

        Re: It's all true!

        Adobe? Thankfully no, but I just spotted that it is now on public record that I can't spell 'preferably'...

  11. Yugguy

    A billion people

    Of which I am NOT one.

  12. Tree

    Sell this to Microsoft

    Microsoft wants to monetize the users, too. Why else is Windows 10 being forced on people? They will need to worry about the same bugs as Facebutt.

  13. razorfishsl

    Face book corrects thousands of bugs a month.........

    Due to not getting to the root of the problem:

    int name1 =0

    String name2

    Input "input your name", name2

    If name2 = "bob"

    name1 =1

    endif

    if name2="dave"

    name1=232323

    endif

    # repeat as needed

    ....................

  14. Christian Berger

    There would be a very simple metric

    Just count the number of lines/characters/syntax elements between matching ends of a "block". This block can be defined by matching brackets, or implicit brackets.

    So something like if (k==0) {dosomething();}; would lead to something like 3 syntax elements for the first brackets and one syntax element for the second set. (alternatively you could count characters which is less precise but way simpler)

    This way the more local your code is, the lower the numbers which correlates nicely with readability.

    Of course this makes no statement about actual bugs in the code. However bugs are much easier to find in readable code than they are in unreadable code. Plus this is so simple that editors could include it to evaluate your code as you type.

    1. Michael Wojcik Silver badge

      Re: There would be a very simple metric

      Researchers studying software engineering have devised dozens of such metrics. Surprisingly, not one has proven to be a silver bullet.

  15. becky_ash

    I can't spell to save my life I have to open about six pages to get the right spelling at school the teachers just did this jiggerary pokery and then I had the correct spelling all the way through its too late now another asshole has been added.

  16. becky_ash

    Just type in Google 64 environment 76 teaching 42 systemic failure.

  17. becky_ash

    And the app me site

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like