FIleMaker Coding Standards & Management Best Practices

FM Coding Standards
&
Management Best Practices
Presenter: Manjit Behera, Mindfire Solutions
Date: 18/06/2014

FM0-305/307 - FileMaker 11 and 12 certified developer
About Me
Skills: FileMaker 9-13, Oracle 10g, HTML 3, CSS,
Javascript, PHP.
Connect Me:
Facebook: https://www.facebook.com/manjitbehera
LinkedIn: http://www.linkedin.com/pub/manjit-kumar/22/1b4/310
Twitter: https://twitter.com/mastermind____
Google+: https://www.google.com/+mastermindmanjit
Contact Me:
Email: manjitb@mindfiresolutions.com / beheramanjit@gmail.com
Skype: mfsi_manjitb

AgendaAgenda
Filemaker Coding Standard
Mindfire Coding Standard
Application/Customize Coding Standard
Project Management
Backup and Updates

What is Coding Standard ?What is Coding Standard ?
Coding standards/conventions are a set of guidelines for a
specific programming language that recommend programming
style, practices and methods for each aspect of a piece
program written in this language.
These conventions usually cover file organization, indentation,
comments, declarations, statements, white space, naming
conventions, programming practices, programming principles,
programming rules of thumb, architectural best practices, etc.

Filemaker Coding StandardFilemaker Coding Standard
Camel Case ( e.g. contactFirstName )
Pascal Case ( e.g. ContactFirstName )
Underscore format ( e.g. contact_first_name )
Generally there are 3 types of naming conventions in Filemaker.

Filemaker Coding StandardFilemaker Coding Standard
Database Definitions (e.g. Tables, Fields, TOGs )
Layouts ( e.g. ContactFirstName )
Scripts ( e.g. Title, Comments, Variables )
Generally there are 3 areas to implement Naming Conventions in
Filemaker.

Naming Conversions : TablesNaming Conversions : Tables
Naming of tables are straight forward and must follow Camel Case
conversion. A table name should not be include space or any special
characters (e.g. #,$,=,@,%, etc).

Naming Conversions : FieldsNaming Conversions : Fields
Naming of Fields are straight forward and must follow either Camel Case
or Pascal Case conversion. A Field name shouldn't have any special
characters (e.g. #,$,=,@,%, etc). It is advisable not to include space to
the fields that are used in calculations.
Below are the abbreviations used for different Field Types:
n = Number
t = Text
d = Date
i = Time
m = TimeStamp
R = Container
s = Summary
p = Repetition
It is a good practice to use these abbreviations in the Field Names to denote
their data type.
e.g FirstName_xt, Salary_xn, DateOfBirth_xd

In the database the table definition i.e the fields should be by default
sorted by field name. Below are few standards to be followed while
naming the fields:
Key field naming:
- All the key fields should be prefixed with the letter “k”.
- Use triple underscores before a primary key field name. e.g ___kp<Field
Type>_<Field Name>
- Use double underscores before a foriegn key field name. e.g __kf<Field
Type>_<Field Name>
- Use single underscores before a alternate key field name. e.g _ka<Field
Type>_<Field Name>
Examples: ___kpn_ContactId, __kft_CompanyId, _kat_CompanyName
Global fields naming:
- Global fields name should start with the character “g”. e.g g<Field
Type>_<Field Name>
Examples: gn_CurrentContactId, gt_SelectedCompany, gr_NewButton,
gm_CurrentTimeStamp

Utility/Development fields naming:
- Utility field names should be prefixed with “z” and Developer Utility field
should be suffixed as “zz”. e.g z_<Field Name>, zz_<Field Name>
Examples: z_Constant1, zz_ActiveStatus
Calculation fields naming:
- Calculation field name should suffix or prefix the phrase “c<Calculation
Return Type>” to the field name. e.g ct_<Field Name> or <Field Name>_ct
Examples: FullName_ct, LinePrice_cn, AddNewRecordButton_cr,
cr_DeleteRecordButton
Summary fields naming:
- Summary fields should prefixed with the character “s_” e.g s_<Field Name>
Examples: s_TotalPrice, s_NumbersOfContacts

Naming Conversions : TOGsNaming Conversions : TOGs
Anchor Buoy's convention should be followed to name the Table
Occurrences in the Relationship Graph. Mostly 3 alphabet used for
abbreviation of the Table TOGs.

Naming Conversions : LayoutsNaming Conversions : Layouts
Layouts should be named as e.g. <Description of the layout>_<Table
Occurrence Name>
Examples: Company Details_CMT, Company List_CMT
In case to differentiate between Utility and User Interaction layouts layout
name can prefixed with some text like UI for User Interacting layout e.g.
UI_<Description of the layout>[<Table Occurrence Name> ]
If there are grouping/section maintain in a large project use the section
name before the Layout Descriptions. e.g. UI_<Module/Section Name>_
<Description of the layout>[<Table Occurrence Name>]
Examples: UI_CompanyDetails[CMT], UI_Admin_RoleDetails[ROL]

Naming Conversions : Custom FunctionsNaming Conversions : Custom Functions
- Public Custom Functions e.g
CustomFunctionName_CFpub(parameterOne, parameterTwo )
- Private Custom Functions e.g CustomFunctionName_CFpvt(parameterOne,
parameterTwo )
- Custom Function Parameters - camelCase
- Function Headers
1.Author Name
2.Created On
3.Function Name
4.Description
5.Function Parameters
6.Return Type
Examples: RoundUp_CFNpub (number ; decimals)

Naming Conversions : Custom FunctionsNaming Conversions : Custom Functions

Naming Conversions :Naming Conversions : ScriptsScripts
Script Grouping: Scripts should be grouped in folders and sub folders based on
the modules they are used in.
Script Naming: <Anchor TO Name / Type of script>_ScriptName. <Type of
script> can be [UTL], [BTN], [TRG], etc. based on the purpose or type of script. If
the script is attached to any button then prefix [BTN]_ before the script name.
Similarly for utility scripts prefix [UTL], for scripts used at triggers name it as
[TRG]_, [SUB]_ for sub scripts etc.
Script Header:
1.Script Name
2.Created On
3.Purpose
4.Declared Variables
5.Referenced Variables (Global Variables)
6.Parameters (i.e List any parameters required for the script
7.Subscripts Used
8.Calling Scripts
Variables Naming: (Local and Global): camelCase
Inline Comments: Purpose of a section (i.e multiple script steps)
Examples: [BTN]_New Company, [UTL]_Sort Records, [SUB]_Import Related Contacts

Naming Conversions :Naming Conversions : ScriptsScripts

Naming Conversions :Naming Conversions : Value ListValue List
To name value list use suffixes with the name of the list. The Suffixes are as
follows:
c = Custom Value
x = Value list from another file
d = Value list from field, including all values (for Dynamic)
r = Value list from field, including related values (for Related)
Examples: Status List_c, Company Id and Name List_d, Company Contact Persons_r

Mindfire Coding StandardMindfire Coding Standard
Like other standard organizations Mindfire is also having a language
specific naming conventions by following the Standard Coding of
Filemaker.

Application/Customize Coding StandardApplication/Customize Coding Standard
This is the naming conversions that follows for a particular project/company
which might not be a standard coding of respective language.

Benefits of Coding StandardBenefits of Coding Standard
Software maintenance
Software engineering
Driving down complexity
Quality
Re-factoring

Project ManagementProject Management
Folder Structure
Coding Standard
Code Management
Consistency
Performance
Security

Backup and UpdatesBackup and Updates
Periodical Backup
Record Updates
Cloud Storage
SVN Usages

Question and Answer

Thank you

www.mindfiresolutions.com
https://www.facebook.com/MindfireSolutions
http://www.linkedin.com/company/mindfire-solutions
http://twitter.com/mindfires

FIleMaker Coding Standards & Management Best Practices

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (18)

Más de Mindfire Solutions

Más de Mindfire Solutions (20)

Último

Último (20)

FIleMaker Coding Standards & Management Best Practices