Getting Started with P#
      Back to home
      1. Datagration Knowledge Base
      2. P#
      3. Getting Started with P#

      What are the Datagration Scripting Best Practices?

      Summarizes some ways to keep the workspace looking similar with multiple authors

       INTRODUCTION

      The guidelines and conventions stated in the following sections serve the following purposes:

      • They create a consistent look to the workspace, so that everyone working with it can focus on the content.
      • They facilitate copying, changing, sharing, and maintaining the content of the workspace.
      • They demonstrate best practices for working with Datagration NAMING CONVENTIONS.

      Formating

      To easily change a script to be formatted according to the best practices, use the Auto Format by right clicking on the P# script view.

      Signals

      • all lower case
      • don't use numbers to start the signal name (important when working in R)
      • use well known abbreviations only
      • no pascal or camel casing
      • don't use numbers to abbreviate (e.g. 2 instead of to)
      • use a single space between words
      Examples:
      bad: my BCO score -> good: my bco score
      bad: ImportantSignal -> good: important signal


      Hierarchies, Scripts, Workflows, Schedules, Entity Sets, Scopes, Contexts, Columns, Tag Groups, Tags, Labels, etc.

      • capitalized descriptive names
      • don't use pascal or camel casing
      • don't use underscores
      • use a single space between words
      • don't use numbers to abbreviate (e.g. 2 instead of to)

      Examples:
      bad: WellHierarchy -> good: Well Hierarchy
      bad: FromStart2End -> good: From Start To End
      bad: my first column -> good: My First Column


      Workspace Values

      • use pascal casing
      • don't use numbers to abbreviate (e.g. 2 instead of to)


      Examples:

      bad: My workspaceValue -> good: MyWorkspaceValue

      P# CODING RULES AND STYLE GUIDELINES


      Comments
      • comment tables and columns if the purpose is not obvious
      • insert a header describing the script

      Coding Rules

      • max line width 80 columns (unless screen readability is severely affected)

      • use tabs to indent code (1 tab per level)

      • use brackets () to structure column definitions

      • don't mix static and dynamic tables

      • use pascal casing when calling functions

      • use pascal casing when using operators (Or, And)

      • always place a single space around operators and assignments (+, -, !+, !-, *, /, =)

      • separate function arguments with a single space


      Examples 
      Column "Gapfilled Water" in "m3"
      GapFilling("produced water per time increment" in "m3", "linear")
      End Column

      Column "WOR" in " "
      Column "Gapfilled Water" in "m3" /
      "produced oil per time increment" in "m3"
      End Column

      Column "Well Head Pressure Upper Threshold" in "bar"
      If IsNotNull("well head pressure upper threshold" in "bar") Then
      "well head pressure upper threshold" in "bar"
      Else
      If IsNotNull(
      ValueFromParent("well head pressure upper threshold" in "bar",
      "Layer",
      "Reservoir Hierarchy"))
      Then
      ValueFromParent("well head pressure upper threshold" in "bar",
      "Layer",
      "Reservoir Hierarchy"
      )
      Else
      ValueFromParent("well head pressure upper threshold" in "bar",
      "Field",
      "Reservoir Hierarchy"
      )
      End If
      End If
      End Column


      • be consistent

      • only save data to signals if reused often or the calculation takes a long time (e.g. cumulative)

         

      Visualization

      Best Practice is to connect visualization to a Script.
       
      Use a table for the following:
      1. There are many entities and a large scope AND
      2. Some calculations are required but don't want to save the results of those calculations into a separate signal before pulling it into a dashboard.