2 Replies Latest reply on Jun 9, 2017 3:37 AM by wimdecorte

    Recommendations for Code review for filemaker teams ?

    binu.alexander

      I am new to working in a team in filemaker .. have 2 developers working with me .. While some of the things they can do in filemaker  are clever ..  and I happy to have more hands working on some of my larger projects , I am struggling with developing a systematic code review workflow ..

       

      Some General Code review guidelines are available on the internet .. such as

      Code review guidelines - CodeProject

       

      I know there are coding standards for filemaker available at Overview - Coding Standards - FileMaker Coding Standards  .

       

      Was wondering if there are some guidelines / practical tips for code review specific to filemaker ? e.g. what are the common mistakes developers in filemaker make and could  those in the community with experience in handling multi-developer teams share some insight for people who are starting out leading / working with filemaker teams ?

        • 1. Re: Recommendations for Code review for filemaker teams ?
          greatgrey

          One of the main things is to have everything will committed so you know what are data fields and what is data processing variables. i.e. loop control. What IF/Case Test are for.

          Use the simplest Function that does what you need if it gives the value you need without extra processing. Fewer chances to make errors with fewer parameters.

          Ceiling

          • 2. Re: Recommendations for Code review for filemaker teams ?
            wimdecorte

            You may want to establish coding standards first (how to name fields, scripts, layouts, what to use not use in scripting techniques like passing parameters, making field/table names safe in ExecuteSQL(),...)

            That way you have something to focus on during code review.

             

            Typically when we do code review we pick a particular use case from a solution, let the developer explain the goal and then go through the code/layouts/schema line by line and check assumptions etc.

             

            Code review is different than QA. In QA, every bit of functionality is tested to see if it works, and the code inspected to see how robust it is and whether it handles all possible error scenarios.

            2 of 2 people found this helpful