Skip to end of metadata
Go to start of metadata
  • Always use a single space between the ampersand and the concatenated parts to improve readability.

    "foo" & $bar

    good

    myFunction &$$globalVariable

    bad

  • Exception Note: When simply adding a single carriage return using the pilcrow, you can combine the elements together. This simply reduces the number of spaces. This does not apply to how many lines are used for concatenation. It's simply a guideline to reduce the amount of spaces and indicate, on the next line, what is being concatenated.
    Get ( AccountName ) &¶
    & Get ( CurrentTimeStamp )
    

    good

    Get ( AccountName )
    & ¶ &
    Get ( CurrentTimeStamp )
    

    good

    Get ( AccountName ) &¶& Get ( CurrentTimeStamp )
    

    good

    Get ( AccountName ) & ¶

    bad

    & "¶¶" &

    good

    &"¶¶"&

    bad

    Historically, FileMaker always required the use of quotes around a single ¶. As soon as more than one ¶ is used, then quotes are required.
  • No labels

5 Comments

  1. Isn't "&" another operator? Could this be merged with the Operators page?

  2. Anonymous

    Why the exception for the pilcrow?

    I often concatenate with pilcrows and "less significant" stuff on a separate line so I can read the "real stuff":

    Get ( AccountName )

    & "¶" &

    "foo"

    1. The reasoning for not using quotes around a single pilcrow was just for readability. Removing spaces, when you're only using one pilcrow just makes it read easier - since our eyes are trained to see spaces as separations.

      Of course, the argument for spaces around the ampersand would counter the above statement - because you need to see the ampersand to know you are concatenating.

      When it comes to adding in returns to concatenated lines of code (let's say anything more than 2 lines) I would HIGHLY suggest using List() function.

      List (
        Get ( AccountName );
        "foo";
      )
      

      vs.

      Get ( AccountName )
      &¶&
      "foo"
      

      vs.

      Get ( AccountName ) &¶&
      "foo"
      

      vs.

      Get ( AccountName ) &¶
      & "foo"
      

      The List() seems much easier to read to me, and it works somewhat similar to heredoc - although you have extra sets of quotes on each line.

      If you're not using List() then the later two are more readable because you don't have to stop to "interpret" the &¶& on the second line. You start to recognize the &¶ as a pattern and the starting & on any subsequent line instantly says "attach me to the previous line".

      List() removes blank lines

      Icon

      Note, when use the List() function, it will remove empty values. If one of your lines within the List() is a field, and that field has nothing in it, it will not include the line. In the case where you need to ensure all lines are represented, even if they are blank, then don't use List()

      1. Anonymous

        Matt, I think you are arguing with contradictory statements.  If "You start to recognize the &¶ as a pattern..." then you will also start to recognize the "& ¶ &" between lines as a pattern that instantly says 'concatenate these lines' just as easily.  I have used both and found it easy to read the latter as a concatenate lines - my brain automatically ignored the intervening line.  These days, I actually prefer your method, but this argument in favor of it seems entirely specious.

        I think the reason I prefer the trailing "&¶" and next line leading with "& " is that it creates something like a visual block, with the leading "& " serving something like an indent, or like the old-fashioned "> " blockquote indicator in email messages.  

        Or (just thought of this interpretation) is it your assertion that having fewer lines makes it more readable?  

  3. Anonymous

    I agree with comment 2