Download to read offline
Uploaded byErika Barron
12 Days of Coding Errors
The document discusses common software issues and how to prevent them. It covers overloaded systems, text editors, accidental assignments, plaintext passwords, SQL injection, unstable builds, memory errors, unhandled exceptions, race conditions, false positives, memory leaks, and null pointers. The presentation provides tips on testing components in isolation, using modern editors to reduce bugs, encrypting sensitive data, validating user input to prevent SQL injection, making builds repeatable, handling exceptions properly, and avoiding null pointers.
12 Days of Coding Errors
- 1. Arthur Hicken –Parasoft 2013-12-20 December 2013 Parasoft © 2013 1
- 2. GoToWebinar Housekeeping Your Participation Openand hide your control panel Join audio: • Choose “Mic & Speakers” to use VoIP • Choose “Telephone” and dial using the information provided Submit questions and comments via the Questions panel Note: Today’s presentation is being recorded and will be provided within a week. Parasoft © 2013 2
- 3. 1 Overloaded System Know the load you need Normal Peak Test before deploying Isolate each component Service Virtualization Parasoft © 2013 3
- 4. 2 Text Editors Texteditors • VI • Emacs Modern editors: • Save Time • Reduce bugs • Increase understanding Parasoft © 2013 4
- 5. Results where they’reneeded Email is not an IDE Browser is not an IDE Tasks Automatically Distributed Parasoft © 2013 5
- 6. 3 accidental assignments if (a = b) {} If a.equals(b){ Parasoft © 2013 6
- 7. 4 Plaintext Passwords Sensitivedata should be encrypted Enforce reasonable passwords Sending Storing Parasoft © 2013 7
- 8. 5 SQLi Common Easy toexploit Easy to prevent Data validation Stored procedures Parasoft © 2013 8
- 9. 6 Unstable builds Non-repeatable builds Humansteps required Artifacts not all under control Environment not under control Parasoft © 2013 9
- 10. 7 Memory Errors Overwrites Readoverflow Write overflow Lucky pointers Uninitialized memory Buffer underrun Dangling references Parasoft © 2013 10
- 11. 8 Unhandled exceptions When to handle, when to re-throw Run-time vs compile-time checking Empty handlers Parasoft © 2013 11
- 12. 9 Race Conditions Hard to find Hard to reproduce Careful API use Parasoft © 2013 12
- 13. 10 False Positives Proper Configuration ProperRules Leaving noise leads to missing issues Proper Suppressions Parasoft © 2013 13
- 14. Doing too much Toomany rules Too much code Unimportant rules Parasoft © 2013 14
- 15. 11 Memory Leaks Allsoftware leaks Resources, not just memory Proper API use Runtime debugger with good test suite Parasoft © 2013 15
- 16. 12 Null Pointers Affect stability Important forAPIs Can be prevented Parasoft © 2013 16
- 17. The Whole List 1 - Overloaded system 2 - Text editors 3 - Accidental assignments 4 – Plaintext passwords 5 – SQLi 6 – Unstable builds Parasoft © 2013 7 – Memory errors 8 – Unhandled exceptions 9 – Race conditions 10 – False positives 11 - Memory leaks 12 - Null pointers 17
- 18. Next Coming inJanuary New Years resolutions for Software Development Parasoft © 2013 18
- 19. Web http://www.parasoft.com/jsp/resources Blog http://alm.parasoft.com Social Facebook: https://www.facebook.com/parasoftcorporation Twitter: @Parasoft @MustRead4Dev LinkedIn: http://www.linkedin.com/company/parasoft Google+ Community: Static Analysis for Fun and Profit Parasoft © 2013 19
Editor's Notes
- #3 Give Attendees a closer look at the control panel and how they can participate. Text may be adjusted to suit your event needs.Note: Hand Raising is enabled (see slide 3)Visit the “Options” menu in the Organizer control panel a check to allow attendees to Raise Hands.
- #4 Healthcare.govCyber Monday at Motorola
- #7 8. Comparison assignment ( = rather than == )This is an easy error to make. If you're used other languages before, such as Pascal, you'll realize just how poor a choice this was by the language's designers. In Pascal, for example, we use the := operator for assignment, and leave = for comparison. This looks like a throwback to C/C++, from which Java draws its roots.Fortunately, even if you don't spot this one by looking at code on the screen, your compiler will. Most commonly, it will report an error message like this : "Can't convert xxx to boolean", where xxx is a Java type that you're assigning instead of comparing.7. Comparing two objects ( == instead of .equals)When we use the == operator, we are actually comparing two object references, to see if they point to the same object. We cannot compare, for example, two strings for equality, using the == operator. We must instead use the .equals method, which is a method inherited by all classes from java.lang.Object.Here's the correct way to compare two strings.String abc = "abc"; String def = "def";// Bad wayif ( (abc + def) == "abcdef" ){ ......}// Good wayif ( (abc + def).equals("abcdef") ){ .....}
- #8 LinkedInProgrammer passwords:Plain text passwordsUser passwords:Same password multiple sites8 char passwordDictionary password
- #15 Don’t start with too many rulesStatic Analysis is about processIt’s incrementalAvoid biting off more than you can chewAvoid any rule you won’t stop the build for
- #20 Questions:1) When you have a tool that finds possible null pointers, aren’t most cases just false positives?2) Do new IDE’s really work any better than my old setup? I’m pretty effective already.3) I have a really hard time finding a thread problem in my application – what can I do?