Statische Code-Analyse ROLAND GRAF SIMON KRANZER

Begriffsklärung  Code-Analyse  Methoden und Techniken die a posteriori sicherstellen dass ein Software-System den geforderten Qualitätsanforderungen genügt.  Statische Code-Analyse  Die oben genannten Techniken bzw. Methoden sind von statischer Natur. Die Überprüfung erfolgt durch Sichtung der Quelltexte (bzw. des Intermediatecodes), ohne diese in ein ausführbares Programmzu übersetzen!

Statische Code-Analyse  Im Rahmen der Softwaretestverfahren ist die Statische Code- Analyse den White-Box-Test-Verfahren zuzuordnen (man benötigt den Quellcode). Die Analyse kann durch manuelle Inspektion erfolgen, aber auch automatisch durch ein Programm. Man spricht dann von statischer Analyse, da die zu testende Software in Form von Algorithmen und Daten in ihrer Formulierung und Beschaffenheit (statisch) dem Prüfer (oder Werkzeug) vorliegt. (WIKIPEDIA)  Vorläufer der statischen Analyse sind die Prüfverfahren der normierten Programmierung und die Werkzeuge zur Erkennung von Code-Mustern, die sogenannten Style Checker. Dynamische Code- Analyse setzt im Gegensatz zur statischen Analyse ein laufendes Programm voraus. Ein dynamisches Pendant zur statischen Code- Analyse zur Compilezeit ist z. B. das Profiling zur Laufzeit. (WIKIPEDIA)

Was nun?  Diskussion  Was unterscheidet statische, regelbasierte Code-Analyse von Design Guidlines und Werkzeugen zum Test auf deren Einhaltung von Tool zur statischen Code-Analyse?

Was kann statische Code-Analyse leisten?  Race Conditions  Pufferüberläufe  Speicherlecks  Formatguidlines Aufgrund einer nach wie vor nicht unerheblichen Anzahl an falsch erkannten, nur vermeintlichen Schwächen im Quellcode ist eine vollautomatische Korrektur durch die Werkzeuge zur statischen Code- Analyse bis zum heutigen Tag nicht Usus. Es werden Warnings generiert und vom/von Tester*in bzw. Entwickler*in beurteilt und ggf. behandelt.

Walkthrough  Code-Analyse in Visual Studio 2013  Image Ccartoon Effect  Hangman

PAUSE

Microsoft Code Analysis for Managed Code Rules  Design Warnings Warnings that support correct library design as specified by the.NET Framework Design Guidelines. Globalization WarningsWarnings that support world-ready libraries and applications. Interoperability WarningsWarnings that support interaction with COM clients. Maintainability WarningsWarnings that support library and application maintenance. Mobility WarningsWarnings that support efficient power usage. Naming Warnings Warnings that support adherence to the naming conventions of the.NET Framework Design Guidelines. Performance WarningsWarnings that support high-performance libraries and applications. Portability WarningsWarnings that support portability across different platforms. Reliability Warnings Warnings that support library and application reliability, such as correct memory and thread usage. Security WarningsWarnings that support safer libraries and applications. Usage WarningsWarnings that support appropriate usage of the.NET Framework. Code Analysis Policy ErrorsErrors that occur if the code analysis policy is not satisfied at check-in.

Examples  CA1000: Do not declare static members on generic types  CA1008: Enums should have zero value  CA1021: Avoid out parameters  CA1031: Do not catch general exception types  CA1032: Implement standard exception constructors  CA1040: Avoid empty interfaces  CA1047: Do not declare protected members in sealed types  CA1065: Do not raise exceptions in unexpected locations

Examples  CA1402: Avoid overloads in COM visible interfaces  CA1407: Avoid static members in COM visible types  CA1500: Variable names should not match field names  CA1505: Avoid unmaintainable code  CA1502: Avoid excessive complexity  Exkurs: Walkthrough – Code-Metrik in Visual Studio 2013  Simple Calculator  Etc, etc, etc.

C# Coding Conventions   Naming Conventions  Layout Conventions  Commenting Conventions  Language Guidelines

Secure Coding Guidelines How to: Run Partially Trusted Code in a Sandbox Explains how to run a partially trusted application in a restricted security environment, which limits the code access permissions granted to it. Securing State DataDescribes how to protect private members. Securing Method AccessDescribes how to help protect methods from being called by partially trusted code. Securing Wrapper CodeDescribes security concerns for code that wraps other code. Security and Public Read-only Array Fields Describes security concerns for code that uses public read-only arrays found in.NET Framework libraries. Securing Exception HandlingDescribes security concerns for handling exceptions. Security and User InputDescribes security concerns for applications that accept user input. Security and Remoting ConsiderationsDescribes security concerns for applications that communicate across application domains. Security and SerializationDescribes security concerns when serializing objects. Security and Race ConditionsDescribes how to avoid race conditions in your code. Security and On-the-Fly Code GenerationDescribes security concerns for applications that generate dynamic code. Security and Setup IssuesDescribes considerations for the testing and setup of your application. Code Access Security Describes.NET Framework code access security in detail and provides instructions for using it in your code. Role-Based Security Describes.NET Framework role-based security in detail and provides instructions for using it in your code.

Alternativen zu den Regeln von Microsoft Gendarme:   Example:  AvoidDeepNamespaceHierarchyRule 