glory_convention_lint 1.0.0

GloryConventionLint is code judgment for Convention Lint Flutter.

RollingGlory is Company or Creative Digital Media studio based in Bandung, Indonesia.

GloryConventionLint-Flutter

GloryConventionLint is code judgment for Convention Lint Flutter support IDE Android Studio/Visual Studio Code.

Setup

• add glory_convention_lint into package.yaml

$ flutter pub add --dev glory_convention_lint

dev_dependencies:
  glory_convention_lint: ^1.0.0
  custom_lint: ^0.2.5

• add plugin analyzer into analysis_options.yaml

analyzer:
  plugins:
    - custom_lint

Conventions

Model Convention

• Model class name convention
• Model file name convention
• Model annotation convention
• Prefer nullable for models convention

Service Convention

• Service class name convention
• Service file name convention
• Service annotation convention

Enum Convention

• Enum name convention
• Enum file name convention

Request Convention

• Request class name convention
• Request file name convention

Response Convention

• Response class name convention
• Response file name convention

Other Convention

• Naming Convention
• Prefer single class per file convention
• Prefer static const lang variable convention
• Base response import convention
• One variable for lang convention

Examples

Model Convention Example

• Model class name convention example
• Model file name convention example
• Model annotation convention example
• Prefer nullable for models convention example

Service Convention Example

• Service class name convention example
• Service file name convention example
• Service annotation convention example

Enum Convention Example

• Enum name convention example
• Enum file name convention example

 

Conventions

Model Convention

Model class name convention

Ensure to add Model word at the end of class name in models file

//DO
class ProductModel {}
//DON'T
class ProductModel {}

Model file name convention

The file name for models must end with _model.dart

//DO
product_model.dart
//DON'T
product.dart
productmodel.dart
```

Model annotation convention

Add @JsonSerializable() from Retrofit to above your class model name

//DO
@JsonSerializable()
class ProductModel {
  int? id;
}
//DON'T
class ProductModel {
  int? id;
}
@JsonSerializable()

Refer nullable for models convention

Fields of Model class is preferable to have nullable field. example : String? instead of String

//DO
  class Product {
  String? name;
  Product({this.name});
}
//DON'T
  class Product {
  String name;
  Product({this.name});
}

Service Convention

Service class name convention

Ensure to add Services word at the end of class name in models file

//DO
  class GiftServices{}
  class ProductServices{}
//DON'T
  class Gift{}
  class ProductService{} // singular instead of plural

Service file name convention

The file name for services must end with service.dart

//DO
  gift_services.dart
  product_services.dart
//DON'T
  product_service.dart //singular instead of plural
  ProductRequest.dart

Service annotation convention

Add @RestApi() from Retrofit to above your class service name

//DO
@RestApi() //RestApi Annotation is added
abstract class ProductServices {}
//DON'T
//Forget to add RestApi Annotation
abstract class ProductServices {}

Enum Convention

Enum class name convention

Ensure to add Enum word at the end of enum class name in the file.

//DO
enum AvatarEnum {}
//DON'T
enum EnumAvatar {}

Enum file name convention

Ensure to add _enum.dart prefix at the end of file name.

//DO
  gift_enum.dart
  product_enum.dart
//DON'T
  ProductEnum.dart

Request Convention

Request class name convention

Request class always end with "Request", and must use PascalCase.

//DO
class GiftRequest{}
class ProductRequest{}

//DON'T
class Gift{}
class product_request{}

Request file name convention

Request file must always end with "_request" and should always use snake_case for file naming.

//DO
product_request.dart

//DON'T
ProductRequest.dart

Request file must always be put inside of request directory.

|- data
  |- network
    |- request

Response Convention

Response class name convention

Response class always end with "Response", and must use PascalCase.

//DO
class GiftResponse{}
class ProductResponse{}

//DON'T
class Gift{}
class product_response{}

Response file name convention

Response file must always end with "_response" and should always use snake_case for file naming.

//DO
product_response.dart

//DON'T
ProductResponse.dart

Response file must always be put inside of response directory.

|- data
  |- network
    |- response

Other Convention

Naming Convention

	PascalCase	CamelCase	Plural	SnakeCase	Examples
Class	✅				class ModelResponse{}
Service Class	✅		✅		class ModelServices{}
Constant Class	✅		✅		class NetworkConstants{}
Extension	✅		✅		extension StringExtensions on String
Field		✅			int id;
Variable		✅			int variable;
Local variable		✅		✅	int _variable;
Parameter		✅			String param
Method		✅			void methodName(){}
Local Method		✅		✅	void _methodName(){}
Enum Type	✅				enum Status{}

Prefer single class per file convention

Avoid Declaring multiple classes in one file. It is best practice to declare one class in one file instead of multiple of class in one files, to reduce confusion.

//DO
-- test.dart --
class One = {};

//DON'T
-- test.dart --
class One = {};
class Two = {};

Prefer static const lang variable convention

Declare variable as static const.

//DO
class One {
  static const variableOne = "Value"
}

//DON'T
class One {
  String variableOne = "Value";
}

Base response import convention

Both BaseResponse and BaseListResponse must be implemented and imported from rollingglory_codebase When an application communicates to the backend via API calls, we usually receive two type of responses. single object and multi objects. both types need to be implemented in service file, the service file is actually an abstract class that contains a set of methods which is needed in order to get data from API.

//DO
class One {
  Future<BaseListResponse<Episode>> getEpisodes();
  Future<BaseResponse<Episode>> getEpisodeDetail();
}

//DON'T
class One {
  Future<Episode> myMethod();
}

Prefer one variable for language convention

Ensure to separate the variable that represents a language, one class is supposed to have one variable.

//DO
-- languages/id_lang.dart --
Map<String,String> id = {};

-- languages/en_lang.dart --
Map<String,String> en = {};


//DON'T
-- languages.dart --
Map<String,String> id = {};
Map<String,String> en = {};

Example

Incorrect services rules

Visual Studio Code problem reports

Other Information

You can follow us at https://rollingglory.com/