Slashdot Mirror
Meet the Bots That Review and Write Snippets of Facebook's Code (ieee.org)
Wave723 writes: To make its developers' jobs more rewarding, Facebook is now using two automated tools called Sapienz and SapFix to find and repair low-level bugs in its mobile apps. Sapienz runs the apps through many tests to figure out which actions will cause it to crash. Then, SapFix recommends a fix to developers, who review it and decide whether to accept the fix, come up with their own, or ignore the problem.
Well, the animated gif (what a terrible way to provide concrete examples) suggest a far more simplistic helper than people are imagining.
Basically their example of it doing it's thing is just finding all instances where a method is called on something and prefacing that with 'if null, return immediately without data'.
Of course I've spent a non trivial time working in a language that pretty much lives that way: Perl. In perl if you go off the reservation, it just keeps on going... somewhere.
Funny thing happens, you don't get 'null pointer exception' behaviors, but you do end up with much harder to fix behaviors resulting from that undefined behavior propagating until it finally explodes in weird behavior for the user. Your application manages to avoid crashing, but the user would have probably been better off if the application crashed. At first I did think it was a blessing because it did save me a lot of tedium since *most* of the time something undef and false was what I'd want a screwup to look like, but now I appreciate a language that breaks immediately when there's any ambiguity possible.
XML is like violence. If it doesn't solve the problem, use more.
I worked on software like this, that didn't punish the caller (with an exception) when called with bad data. And you're right, the code will just keep going until it hits a brick wall somewhere leaving you scratching your head what went wrong.
The root cause of this is that the models used did not verify data was valid in them, in fact, nobody really knew whether some value would always be present or in what format it would be.
What was worse, the unit tests accompanying this code were the primary source of badly filled models requiring the bad data checks all over the place in the first place to keep them running.
When I became tech lead of my own project, I added verification to all data models used (upon construction) so it would be impossible to store bad or even unexpected data in them. This not only helped us learn what kind of data we could expect and what assumptions we were making about it, but we also discovered blatant bugs in dependent system that would feed us bad data as we would verify it before acting upon it further.
The nice part was that all this bad data checking happened in one spot, localized to the model involved, and all the other code could make assumptions about it without needing to do null checks or other checks. Cleanest code I ever saw.
The bot in the article is just promoting very bad coding practices, and making the problem worse. So much for AI.