12 Days of Coding Errors
•Télécharger en tant que PPTX, PDF•
0 j'aime•572 vues
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.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à 12 Days of Coding Errors
Similaire à 12 Days of Coding Errors (20)
Plus de Erika Barron
Plus de Erika Barron (20)
Dernier
Dernier (20)
12 Days of Coding Errors
- 1. Arthur Hicken – Parasoft 2013-12-20 December 2013 Parasoft © 2013 1
- 2. GoToWebinar Housekeeping Your Participation Open and 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 Text editors • VI • Emacs Modern editors: • Save Time • Reduce bugs • Increase understanding Parasoft © 2013 4
- 5. Results where they’re needed 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 Sensitive data should be encrypted Enforce reasonable passwords Sending Storing Parasoft © 2013 7
- 8. 5 SQLi Common Easy to exploit Easy to prevent Data validation Stored procedures Parasoft © 2013 8
- 9. 6 Unstable builds Non-repeatable builds Human steps required Artifacts not all under control Environment not under control Parasoft © 2013 9
- 10. 7 Memory Errors Overwrites Read overflow 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 Proper Rules Leaving noise leads to missing issues Proper Suppressions Parasoft © 2013 13
- 14. Doing too much Too many rules Too much code Unimportant rules Parasoft © 2013 14
- 15. 11 Memory Leaks All software leaks Resources, not just memory Proper API use Runtime debugger with good test suite Parasoft © 2013 15
- 16. 12 Null Pointers Affect stability Important for APIs 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 in January 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
Notes de l'éditeur
- 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.
- Healthcare.govCyber Monday at Motorola
- 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") ){ .....}
- LinkedInProgrammer passwords:Plain text passwordsUser passwords:Same password multiple sites8 char passwordDictionary password
- 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
- 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?