SyneraCodeAnalyzer 1.0.1

This is a code analyzer specifically made for the development of add-ins for Synera. If you are not familiar with add-in development in Synera, please refer to our developer documentation or our example project on Bitbucket.

Synera Code Conventions

The following paragraphs document the code conventions and rules that are currently implemented in SyneraCodeAnalyzer. All rule violations and warnings, if any, will be shown in the Error List window and the SyneraCodeFixProvider will show suggestions for fixing them automatically. You may also choose to fix all instances of a specific rule violation across a document, project or solution. This documentation is intended for cases where the explanation provided by the code analyzer is not enough.

Hint: Suggestions from the SyneraCodeFix provider can be accessed by pressing Ctrl + .

Rules

Below is a list of all rules. More detailed explanations for each rule follow in the subsequent chapters.

• SYN1xxx - these rules have to do with code and naming conventions

  • SYN1001 - Synera naming conventions for private fields.
  • SYN1002 - Synera conventions for member declaration order.

• SYN2xxx - these rules have to do with architecture decisions and avoiding runtime issues.

  • SYN2001 - Synera convention for GuidAttribute usage.
  • SYN2002 - Synera convention for default constructor implementation.
  • SYN2003 - Synera convention for serializable datatypes.
  • SYN2004 - Synera convention for localization of datatypes.
  • SYN2005 - Synera convention for overriding the ToString() method.
  • SYN2006 - Synera convention for sealed modifier usage in Synera.Core.Graph.INode non-abstract implementation.

SYN1001 - Private field naming conventions

• All private static fields should have names starting with a double underscore (__).
• All non-static private fields should have names starting with a single udnerscore (_).
• All private fields should have names (which begin after the underscores) in camelCase.

Examples

private static int __myStaticField;
private int _myField;

Refactoring all fields is a huge and unpleasant refactoring task, so you can just use the code-fix provider to automate this across the project.

SYN1002 - Member declaration order

The order in which members of a class or interface are declared should conform to the multi-level sorting described below:

• At the first level, members should be declared in the order const members, then static fields and then all the other fields.

• At the second level, nested type declarations, i.e. nested enums, structs and classes should come before any non-static class member.

• At the third level, i.e. within static and non-static groups, readonly members should be declared before non-readonly members.

• At the fourth level, i.e. within the readonly and non-readonly groups from level 2, the members should be sorted in the following order:

  • [any other type of member]
  • Nested classes
  • Nested structs
  • fields
  • properties
  • event fields
  • constructors
  • destructors
  • methods

• At the fifth level, i.e. within groups of fields etc., the members should be sorted by their access level in the following order:

  • public
  • internal
  • protected
  • private

This kind of multi level sorting could turn into a very tedious refactoring task. So you are not expected to do this manually. The SyneraCodeFixProvider should automate the task of sorting all the members.

SYN2001 - GuidAttribute usage

Because Synera loads a lot of types from core libraries and add-ins at runtime, we need some classes to implement a GuidAttribute to uniquely identify themselves. If these are not implemented, it could result in unexpected behavior at runtime.

This rule enforces the developer to implement this attribute for any non-abstract class that implements one or more of the following interfaces:

• Synera.Core.Graph.ICanvasObject
• Synera.Kernels.IKernel
• Synera.Core.UI.IWidget
• Synera.Kernels.ITranslator

For convenience you can choose to let the SyneraCodeFixProvider fix this problem for you by adding a System.Runtime.InteropServices.Guid attribute with a new guid for the class in question.

SYN2002 - Default constructor implementation

Because Synera instantiates a lot of objects from core libraries and add-ins at runtime, certain classes are required to implement default constructors that are public and parameterless. This rule enforces such a constructor for any non-abstract class that inherits/implements any of the following types:

• Synera.Core.Graph.ICanvasObject
• Synera.Kernels.IKernel
• Synera.Core.UI.IWidget
• Synera.Kernels.ITranslator
• Synera.Core.ApplicationService.Commands.IApplicationCommand
• Synera.Core.Graph.Data.IGraphDataType
• System.Configuration.ApplicationSettingsBase
• Synera.Core.ApplicationService.Scripting.IScriptInterpreter
• Synera.Core.ApplicationService.Algorithms.IAlgorithm
• Synera.Optimization.IOptimizer
• Synera.Kernels.Fem.Meshing.IMesher

Unlike the other rules, there is no automated code-fix implemented for this at the moment.

SYN2003 - Serializable datatypes

Synera depends on certain datatypes being serializable and deserializable to provide a consistent experience to the user across the application. This rule makes sure that all concrete classes that implements the interface Synera.Core.Graph.Data.IGraphDataType are serializable.

These types should implement one of the following serialization mechanisms:

• Implement Synera.Core.Serialization.ISerializableObject interface.
• Implement Synera.DataTypes.Serialization.ISerialByteMap interface.
• Implement System.Runtime.Serialization.ISerializable interface.
• Use System.Runtime.Serialization.DataContractAttribute attribute.
• Use System.SerializableAttribute attribute.

SYN2004 - Localization rule

In the interest of delivering a consistent user experience, all datatypes exposed to the user should have localization attributes. All classes and interfaces implementing the interface Synera.Core.Graph.Data.IGraphDataType are required to have a localization attribute.

SYN2005 - ToString override rule

In the interest of delivering a consistent user experience, all datatypes exposed to the user should override the ToString method to display meaningful information. All non-abstract graph datatypes that implement the interface Synera.Core.Graph.Data.IGraphDataType should override the ToString method, unless a parent class already overrides it.

SYN2006 - Sealed modifier for Synera.Core.Graph.INode

Synera.Core.Implementation.Graph.CanvasObject.Category and Synera.Core.Implementation.Graph.CanvasObject.LicenseFeatureCodes have protected setters, and it basically means, that any Node can be inherited and those properties can be cleared. To remove such possibility we have to mark Synera.Core.Graph.INode implementation classes as sealed to avoid inheritance.

This rule enforces the developer to add the sealed modifier for any non-abstract class that implements the Synera.Core.Graph.INode interface.

For convenience you can choose to let the SyneraCodeFixProvider fix this problem for you by adding a sealed modifier for the class in question.