Recommendations from the Flutter team to improve the Smoothie code base

[stephanegigandet]

Darren Austin from the Flutter team at Google has written a document to share his first impression of the Smoothie code base:

https://docs.google.com/document/d/1K9AnSoe67Rt70zeU7EA04wJSsfn5glYX6MvI-qK6NIs/edit#heading=h.c0uts5ftkk58

Overall Darren says that our code base is reasonably well structured and layed out (so kudos to @PrimaelQuemerais, @monsieurtanuki, @M123-dev, @teolemon and the others who are contributing to it!).

Darren also has recommendations on how we can improve:

• Tighten up the top-level application folder structure (and decide if having two packages makes sense).
• Develop a code style guide (or point to an existing one) and require everyone to conform to it.
• Develop tests for the existing components and require them for all new components going forward.
• Setup automated pre-commit checks to run tests, enforce code style and lints, etc.
• Add more documentation for onboarding new developers (environment setup guide, code structure documentation, how to contribute, etc).

I think it would be really useful for us to discuss those recommendations, to see which ones are the most useful and we should work on first. If we decide to implement some or all of them, some of the Google Fellows may also be able to help.

What do you think?

[stephanegigandet]

We could discuss Darren's recommendation regarding the coding style: "Agreeing on a specific style guide and enforcing it would help make the code consistent and easier for people to pick up. If you don’t want to come up with one of your own, you could use the Dart or Flutter repo guides or just modify them to your needs."

https://dart.dev/guides/language/effective-dart/style

https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo

[stephanegigandet]

I personally found the "Style guide for Flutter repo" a very interesting read. It goes much farther than what I expected from a style guide.

In fact I refered to it this morning (to advocate for not using an abbreviation in a field name) in a PR of the openfoodfacts-dart package.

It's also a discussion we should have with the openfoodfacts-dart package contributors. Hopefully we can pick the same style guide.

[stephanegigandet]

Also shared on the openfoodfacts-dart repo: openfoodfacts/openfoodfacts-dart#196

[monsieurtanuki]

@stephanegigandet Those are indeed interesting things to read. Most of the code I read in smoothie looks ok to me, in first approach, but we're not very active with test implementation...

Additional food for thought: Widgets vs helper methods | Decoding Flutter, where they explain why we should create new widget classes instead of helper method (e.g. Widget _build(...)), in order to improve performance, testability, accuracy and maintainability.