Coding Standards

This page contains coding standards specific to developing applications within the Application Forms framework.

Contents

• Background
• Implementation Guidelines
• Implementation Style

Background

 The standards are expressed as

• Do
  This is the way of doing and should always be followed
• Consider
  This is generally the best way to do and should be followed unless you have a good reason not to and the consequences are understood.
• Do not
  This is something that never should be done.
• Avoid
  This is something that generally should not be done, but can be ignored if there is a good reason and the consequences are understood

Application Forms applications means window, control or functional classes derived from classes, or mainly using classes, in the Ifs.Fnd.ApplicationForms.* namespace or the PPJ.Runtime.* namespace.

The Application Forms framework may at any time prevent violations to these guidelines by protecting members, adding runtime or design-time checks to the framework code.

Implementation Guidelines

• Do use framework functionality within Ifs.Fnd.ApplicationForms.* namespace
• Do use framework functionality within PPJ.Runtime.* namespace if no corresponding functionality is provided in the Ifs.Fnd.ApplicationForms.* namespace
• Do use framework functionality within the following .NET standard namespaces

  System (core classes like string, int32 etc)

  System.Collections.* (Lists, Hashtables etc)

  System.Globalization (Calendar formats, Number formatting etc)

  System.IO (File access etc)

  System.Text (Text encoding, like UTF-8, ASCII etc)

  System.XML (XML access)

• Do use framework functionality within the following IFS namespaces

  Ifs.Fnd.FndXgantt and related classes

• Do not access underlying controls to ApplicationForms/PPJ classes, like C1.FlexGrid, System.Windows.Forms.TreeView, System.Windows.Forms.ListView etc
• Do not use classes, interfaces and methods within the following Microsoft .NET namespaces or sub-namespaces

  System.Windows.Forms.* (Base UI Controls. Must be accessed through PPJ.Runtime.* or Ifs.Fnd.ApplicationForms.*)

  System.Drawing.* (Drawing primitives)

  System.Web.* (ASP.Net runtime engine)

  System.Reflection.* (Dynamic programming)

  System.Security.* (Code access security)

  System.Threading.* (Parallel programming)

• Avoid using classes, interfaces and methods within the following Microsoft .NET namespaces or sub-namespaces

  System.Data.* (ADO.Net data access)

  System.Runtime.* (Platform invokes etc)

  System.Remoting.* (Communication with remote applications)

• Do not use classes, interfaces methods within the Ifs.Fnd namespace and sub-namespaces

  Ifs.Fnd.AccessProvider.*

  Ifs.Fnd.Core.*

  Ifs.Fnd.Data.*

  Ifs.Fnd.Explorer.*

  Ifs.Fnd.Windows.Forms.*

• Do not use any third party controls or components unless listed as an allowed control.
• Avoid mixing of PPJ types (like SalString) with native .NET types for local variables in the same method, or fields in the same class.
• Avoid static fields. If you have to use static fields, consider marking them ThreadStatic if you understand the initialization implications.
• Do catch messages PM_* and SAM_*
• Do not catch messages AM_*
• Avoid catching messages WM_*
• Do not use members starting with __ or _. These are considered private to the framework even though are marked as public in .NET

Implementation Style

Apart from the instructions above which are specific to Application Forms, there are some general guidelines for C# implementations that should be taken into account. See:

• Source Files
• Code Indentation
• Declarations
• Statements
• Programming Practices