Developer Standards for No-Code Application Development at Flywheel Studio

Developer Standards for No-Code Application Development at Flywheel Studio

By:
Roberto Requena
Published on:
June 19, 2024

At Flywheel Studio, we prioritize high standards in all our development processes, including no-code applications built with FlutterFlow. This platform, known for its ease of use and robust features, enables users to create applications without writing traditional code. However, adhering to developer standards is crucial for ensuring the quality and maintainability of these applications.

Adherence to standards leads to better-quality applications. Standardization ensures that the code is maintainable, scalable, and extensible, while also ensuring that the application is secure and meets regulatory requirements.

Our applications typically consist of three layers: 

  1. Visual
  2. Backend
  3. Data. 

This guide will focus on the Visual Layer built with FlutterFlow. However, we highly recommend defining rules and standards for all your application layers for a cohesive and maintainable project.

The Visual Layer includes all screens and components that users directly interact with in mobile or web applications.

Project Names

When creating a new project, a clear and consistent naming convention is essential. Project names should be written in Capital Case without spaces. For example, use "MyAPP" instead of "my app" or "My app".

Screens or Pages

All components representing a screen or page must follow these guidelines:

  1. The name should clearly indicate its function and avoid abbreviations.
  2. The name should be in CamelCase, singular, followed by the word “Page.” For example, use “UserPage” instead of “user.”
  3. For pages displaying lists, use plural names. For example, use “UsersPage” instead of “userList.”
  4. If a page is part of a group or flow, include it in a module (folder) related to that group. Module names should be in lowercase, with words separated by dashes. For example, use “payments-flow” instead of “paymentFlow.”
  5. Consider dividing visually complex pages into components to improve readability.

Components

Components representing parts of a screen or reusable visual elements must follow these guidelines:

  1. Create all components in the “components” folder.
  2. Components used extensively across different pages can be placed in the “commons” folder.
  3. Group components related to a specific module or page into a folder named after the parent page’s folder.
  4. Component names should clearly indicate their function without abbreviations.
  5. Use CamelCase and singular names, followed by a word denoting their type. For example, use “PayButton” instead of “pay-b,” or “ConfirmPopUp” and “HelpModal.”
  6. Assign unique responsibilities to components to avoid multi-purpose components. For instance, create separate cards for user information and job information.
  7. Limit components to five parameters to enhance readability and maintainability. Consider passing a single object encapsulating all relevant data.

Internal Page or Component Structure

Establish clear guidelines for building well-structured and maintainable pages and components:

  1. Use only essential widgets in your widget tree. Avoid unnecessary nesting and remove extraneous elements.
  2. Break down complex page sections into reusable components to maintain a clean and manageable widget tree.
  3. Widget names should clearly indicate their function without abbreviations.
  4. Use CamelCase for widget names, ending with their type. For example, use “EmailTextField” instead of “email_tf” or “TextField.”
  5. Name Form Widgets as “MainForm” to avoid generic names like “Form_1.” For multiple forms, use specific names such as “AddressForm” and “PaymentForm.”
  6. Apply padding to the parent widget instead of individual child widgets for consistent spacing and simplified code management.

Custom Code

Apply the following standards to custom code:

  1. Use clear and descriptive function and action names.
  2. Names should be in camelCase with the first letter in lowercase. Examples: “calculateTotalPriceIncludingTax,” “getUserByIdFromActiveList,” “updateOrderQuantity.”
  3. Apply the same naming conventions to parameter names in custom code.
  4. Avoid passing multiple parameters. Instead, group related parameters into a single object.
  5. Keep FlutterFlow code files concise and manageable. Break down complex logic into smaller, well-defined functions, actions, or components.

Actions Call Result

When an action call returns a value to be used elsewhere, store that value in a variable:

  1. Use clear and descriptive result names.
  2. Names should be in camelCase with the first letter in lowercase.
  3. Specify the nature of the result at the end of the name. Examples: “addressCreated” or “userUpdated.”

In conclusion, while building no-code applications using FlutterFlow may not involve traditional coding practices, adhering to developer standards is essential for delivering high-quality, secure, and maintainable applications. By following best practices for project organization, UI/UX design, performance optimization, security, and documentation, developers can create robust applications using FlutterFlow's no-code platform.

The primary goals of having standards and rules in place during application development include:

  1. Ensuring consistency: Standards ensure the application is developed consistently, meeting user and stakeholder expectations and providing a better user experience.
  2. Streamlining the development process: Standards reduce development time and effort by avoiding rework, errors, and inefficiencies.
  3. Improving collaboration: Standardization ensures that everyone works towards the same goals, improving team collaboration and reducing conflicts and miscommunication.
  4. Enhancing application quality: Standards ensure maintainable, scalable, and extensible code, improving application quality and security.
  5. Reducing risks and costs: Adhering to standards helps identify and mitigate potential issues early, reducing risks and costs associated with errors, security vulnerabilities, and project failures.

This guide serves as a starting point for defining your own development standards tailored to your specific needs or those of your company.

Roberto Requena

Senior Developer

Flywheel Studio.

Interested in a free app review?

Schedule a call

Starting a new project or want to chat with us?

Subscribe