FIleMaker Coding Standards & Management Best Practices

FM Coding Standards&

Management Best Practices

Presenter: Manjit Behera, Mindfire SolutionsDate: 18/06/2014

Presenter: Manjit Behera, Mindfire Solutions

FM0-305/307 - FileMaker 11 and 12 certified developerAbout Me

Skills: FileMaker 9-13, Oracle 10g, HTML 3, CSS, Javascript, PHP.

Connect Me:Facebook: https://www.facebook.com/manjitbeheraLinkedIn: http://www.linkedin.com/pub/manjit-kumar/22/1b4/310Twitter: https://twitter.com/mastermind____Google+: https://www.google.com/+mastermindmanjit

Contact Me:Email: [email protected] / [email protected]: 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 : Tables Naming 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 : Fields Naming 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 : TOGs Naming 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 : Layouts Naming 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 Functions Naming 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 Headers1.Author Name2.Created On3.Function Name4.Description5.Function Parameters6.Return Type

Examples: RoundUp_CFNpub (number ; decimals)

Naming Conversions : Custom Functions Naming 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 Name2.Created On3.Purpose4.Declared Variables5.Referenced Variables (Global Variables)6.Parameters (i.e List any parameters required for the script7.Subscripts Used8.Calling Scripts Variables Naming: (Local and Global): camelCaseInline 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 Valuex = Value list from another filed = 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

http://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

Software

Transcript of FIleMaker Coding Standards & Management Best Practices