Statische Code-AnalyseROLAND GRAFSIMON 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

http://msdn.microsoft.com/en-us/library/ee1hzekz.aspx

Design Warnings Warnings that support correct library design as specified by the .NET Framework Design Guidelines.

Globalization Warnings Warnings that support world-ready libraries and applications.

Interoperability Warnings Warnings that support interaction with COM clients.

Maintainability Warnings Warnings that support library and application maintenance.

Mobility Warnings Warnings that support efficient power usage.

Naming Warnings Warnings that support adherence to the naming conventions of the .NET Framework Design Guidelines.

Performance Warnings Warnings that support high-performance libraries and applications.

Portability Warnings Warnings that support portability across different platforms.

Reliability Warnings Warnings that support library and application reliability, such as correct memory and thread usage.

Security Warnings Warnings that support safer libraries and applications.

Usage Warnings Warnings that support appropriate usage of the .NET Framework.

Code Analysis Policy Errors Errors 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

http://msdn.microsoft.com/en-us/library/ff926074.aspx

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 Data Describes how to protect private members.

Securing Method Access Describes how to help protect methods from being called by partially trusted code.

Securing Wrapper Code Describes 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 Handling Describes security concerns for handling exceptions.

Security and User Input Describes security concerns for applications that accept user input.

Security and Remoting Considerations Describes security concerns for applications that communicate across application domains.

Security and Serialization Describes security concerns when serializing objects.

Security and Race Conditions Describes how to avoid race conditions in your code.

Security and On-the-Fly Code Generation Describes security concerns for applications that generate dynamic code.

Security and Setup Issues Describes 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.

http://msdn.microsoft.com/en-us/library/8a3x2b7f.aspx

Alternativen zu den Regeln von Microsoft

Gendarme:

http://www.mono-project.com/docs/tools+libraries/tools/gendarme/ Example:

AvoidDeepNamespaceHierarchyRule

http://bit.ly/1tIpw8t