4

I'm a beginner at Flutter/Dart and I keep seeing dollar signs appearing before calls to classes or methods, an example is the following (found in Floor package documentation):

 final database = await $FloorAppDatabase.databaseBuilder('app_database.db').build();

I've searched a lot and the only meaning of dollar signs in Dart that I could find is for string interpolation, but this doesn't seem the case.

Teodoro
  • 1,194
  • 8
  • 22
  • [There's no mention of `$` in Dart's official naming conventions](https://dart.dev/guides/language/effective-dart/style) - so my guess is to ask the person who wrote the code in the first place. – Dai Oct 04 '20 at 02:21

1 Answers1

2

It's not a Flutter or Dart convention - at least not an official one: the official Dart naming conventions document (as of October 2020) makes no mention of using $ in identifier names.

However, I do know that other programming languages' ecosystems do use a dollar-sign (Sigil) and I think that habit was inherited by the authors of the floor database that you linked to. More specifically, in Java it's commonplace to use a $ prefix for type-names generated by tooling rather than being hand-written (such as ORM entity types, for example), and people using RxJS observables in JavaScript will use a $ as a variable-name suffix.

As $FloorDatabase is a type-name, not a variable or member-name, I'm going to go with the assumption it's a habit picked-up from Java:

Java: The $ character should be used only in mechanically generated source code or, rarely, to access pre-existing names on legacy systems.

So in this case, a clue is in the documentation you linked to:

Use the generated code. For obtaining an instance of the database, use the generated $FloorAppDatabase class, which allows access to a database builder

So that's my conclusion: it's not an official naming convention in Dart/Flutter, but it is in Java, and it seems like the authors of floor carried it over from Java.

(I personally wish they didn't as it isn't a particularly useful indicator - what does it matter to a consuming application if a type was created a tool instead of hand-written?)

Dai
  • 141,631
  • 28
  • 261
  • 374
  • Using `$` indeed is a convention used by typical Dart code-generators (e.g. `package:built_value`). Personally I think it's useful because then I know that I can't directly use `grep` on the name to find its definition. – jamesdlin Oct 04 '20 at 02:33
  • 1
    If this is really the case, I totally agree that this symbol convention shouldn't be ported to dart. It's misleading and has probably confused some inadvertent beginners (like me). I'll wait a bit for more answers but yours seems the correct one. – Teodoro Oct 04 '20 at 02:33
  • @jamesdlin, your example tingled my brain, but I didn't quite understood it. Could you give a little more concrete example? (So maybe I change my mind around the use of the symbol). – Teodoro Oct 04 '20 at 02:36
  • Sorry, symbol*, not operator – Teodoro Oct 04 '20 at 02:36
  • 1
    For example, if you look at some code and see `$` in the symbol names, then you know that there's some code-generation magic going on. In your specific case, if you were looking for the implementation of `$FloorAppDatabase` to see how it worked, you could easily tell that you need to run the code-generator *first* and then search the generated output. – jamesdlin Oct 04 '20 at 02:42
  • Hmm ok, cleared. In this case, it seems useful. Thank you! – Teodoro Oct 04 '20 at 02:43
  • @jamesdlin Wouldn't the generated code already be present in your codebase (and so `grep`-able)? And in source-control too? (My personal opinion is that generated-code should be in source-control, but transpiled code should not, and an ORM generator is not a transpiler). – Dai Oct 04 '20 at 02:44
  • @Dai If the generated code isn't in source control, then it wouldn't necessarily be present to search. (I usually don't put generated code in source control if it's created as part of the build process.) In general, generated code also might live in a separate location, making it harder to find. And even if you could find it, it might not necessarily be *readable*, you might be better off trying to find the code it was generated from. – jamesdlin Oct 04 '20 at 03:02
  • Boilerplate that's generated once and will never need to be regenerated would be fine to check in, sure. That code should be expected to be modified. For that case, I agree that using different names for generated symbols isn't useful. – jamesdlin Oct 06 '20 at 22:47