glory_convention_lint

Description:

glory convention lint

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
copied to clipboard
dev_dependencies:
glory_convention_lint: ^1.0.0
custom_lint: ^0.2.5
copied to clipboard

add plugin analyzer into analysis_options.yaml

analyzer:
plugins:
- custom_lint
copied to clipboard
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 {}
copied to clipboard
Model file name convention #
The file name for models must end with _model.dart
//DO
product_model.dart
//DON'T
product.dart
productmodel.dart
```
copied to clipboard
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()
copied to clipboard
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});
}
copied to clipboard
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
copied to clipboard
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
copied to clipboard
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 {}
copied to clipboard
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 {}
copied to clipboard
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
copied to clipboard
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{}
copied to clipboard
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
copied to clipboard
Request file must always be put inside of request directory.
|- data
|- network
|- request
copied to clipboard

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{}
copied to clipboard
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
copied to clipboard
Response file must always be put inside of response directory.
|- data
|- network
|- response
copied to clipboard

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 = {};
copied to clipboard
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";
}
copied to clipboard
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();
}
copied to clipboard
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 = {};
copied to clipboard
Example #
Incorrect services rules #

Visual Studio Code problem reports #


Other Information #
You can follow us at https://rollingglory.com/