Closed fgardt closed 1 year ago
In GitLab by @Slartibartfass2 on Nov 11, 2022, 24:22
moved from smart-sensing-library#25
In GitLab by @Slartibartfass2 on Nov 12, 2022, 13:12
mentioned in merge request smart-sensing-library!3
In GitLab by @Slartibartfass2 on Nov 12, 2022, 13:36
The name of a branch consists of: <Prefix>/<Issue ID>-<Issue Name>
The prefix is one of the commit types from Conventional Commits, so e.g. a bug fix branch would be named fix/....
Additionaly there's the prefix investigate
for investigating e.g. plugins, architectures.
Just the ID of the issue.
Name of the issue in lowercase with whitespaces replaced by hyphens e.g. add-new-feature
fix/1-fix-big-bug
feat/2-add-new-feature
docs/3-add-description-in-readme
investigate/4-investigate-server-connection-plugin
Create merge request
.<Issue ID>-<Issue Name>
and you just have to add the <prefix>/
part.Create merge request
or Create branch
according to your previous choice.In GitLab by @Slartibartfass2 on Nov 12, 2022, 14:33
We follow the rules of Effective Dart and use the flutter_lints package as recommended set of linter rules. They are enforced by the Dart Formatter and the Dart Analyzer.
Formatting can be automatically done on save when the following is included in the workspace settings (./.vscode/settings.json
):
"editor.formatOnSave": true,
In GitLab by @Slartibartfass2 on Nov 15, 2022, 22:42
marked the checklist item code style as completed
In GitLab by @Slartibartfass2 on Nov 15, 2022, 22:42
marked the checklist item flutter: Style guide for Flutter repo, Flutter formatter as completed
In GitLab by @Slartibartfass2 on Nov 15, 2022, 22:42
marked the checklist item code style as incomplete
In GitLab by @Slartibartfass2 on Nov 16, 2022, 12:38
added 1h 15m of time spent
In GitLab by @Slartibartfass2 on Nov 16, 2022, 12:38
added 4h 30m of time spent
In GitLab by @Slartibartfass2 on Nov 16, 2022, 12:39
added 1h 30m of time spent
In GitLab by @Slartibartfass2 on Nov 16, 2022, 16:04
added 2h 45m of time spent
In GitLab by @Slartibartfass2 on Nov 16, 2022, 17:45
We follow the rules of the Kotlin coding conventions and the Android Kotlin style guide.
Both are enforced by ktlint which is in some aspects more strict*.
The linter respects the .editorconfig
file and can be customized if needed.
In GitLab by @Slartibartfass2 on Nov 16, 2022, 17:57
marked the checklist item kotlin: Kotlin coding conventions as completed
In GitLab by @Slartibartfass2 on Nov 16, 2022, 18:27
We follow the rules of the Official raywenderlich.com Swift style guide which is enforced by SwiftLint. The linter can be added to XCode as Build Tool Plugin and there are plugins for AppCode and VSCode.
In GitLab by @Slartibartfass2 on Nov 16, 2022, 18:28
marked the checklist item swift: ... as completed
In GitLab by @Slartibartfass2 on Nov 16, 2022, 18:28
marked the checklist item code style as completed
In GitLab by @Slartibartfass2 on Nov 16, 2022, 19:31
marked the checklist item Common Changelog as completed
In GitLab by @Slartibartfass2 on Nov 16, 2022, 19:31
marked the checklist item Versioning and CHANGELOG as completed
In GitLab by @Slartibartfass2 on Nov 16, 2022, 19:38
Our projects Smart Sensing Library
and Sensing Plugin
adhere to Semantic Versioning (SemVer). The style guide we use for our changelog is Common Changelog.
Example CHANGELOG.md:
# Changelog
## [0.2.1] - 2022-12-24
### Fixed
- Fixed big bug ([#16](https://gitlab.uni-ulm.de/se-anwendungsprojekt-22-23/smart-sensing-library/-/issues/42)) (Angela Merkel)
## [0.2.0] - 2022-12-12
### Changed
- Changed functionality ([#69](https://gitlab.uni-ulm.de/se-anwendungsprojekt-22-23/smart-sensing-library/-/issues/69)) (Johnny Sins)
### Added
- Added new feature ([#42](https://gitlab.uni-ulm.de/se-anwendungsprojekt-22-23/smart-sensing-library/-/issues/42)) (Zaphod Beeblebrox)
## [0.1.0] - 2022-11-16
_Initial release._
[0.2.1]: <https://gitlab.uni-ulm.de/se-anwendungsprojekt-22-23/smart-sensing-library/-/releases/0_2_1>
[0.2.0]: <https://gitlab.uni-ulm.de/se-anwendungsprojekt-22-23/smart-sensing-library/-/releases/0_2_0>
[0.1.0]: <https://gitlab.uni-ulm.de/se-anwendungsprojekt-22-23/smart-sensing-library/-/releases/0_1_0>
CHANGELOG.md
pubspec.yaml
In GitLab by @Slartibartfass2 on Nov 16, 2022, 20:02
marked the checklist item Markdown formatting as completed
In GitLab by @Slartibartfass2 on Nov 16, 2022, 20:02
marked the checklist item GitLab Lints as completed
In GitLab by @Slartibartfass2 on Nov 16, 2022, 20:13
GitLab provides some informations how they test there documentation: GitLab documentation testing.
Linters which we can use are markdownlint and Vale.
markdownlint has an extension for Visual Studio Code. Vale has one as well.
This could be an example for documentation linting to improve our documentation.
In GitLab by @Slartibartfass2 on Nov 16, 2022, 20:16
We can add pre-commit and pre-push hooks to reduce the feedback loop using lefthook.
Once configured it can e.g. check in pre-commit that the formatting and linting is correct and in pre-push run unit tests.
In GitLab by @Slartibartfass2 on Nov 16, 2022, 20:16
marked the checklist item enforcement: pre-commit hook e.g. https://github.com/conventional-changelog/commitlint/tree/master/'Reference to deleted milestone 40'commitlint/config-conventional as completed
In GitLab by @Slartibartfass2 on Nov 16, 2022, 20:19
added 2h of time spent
we'll need some good instructions on how to set that up on your own system but looks good
In GitLab by @Slartibartfass2 on Nov 22, 2022, 13:29
In GitLab by @Slartibartfass2 on Nov 22, 2022, 15:07
mentioned in merge request sensing-plugin!1
In GitLab by @Slartibartfass2 on Nov 22, 2022, 17:28
We can add a bash file which executes the setup of each project. This could look something like this:
Smart Sensing Library:
# Initialize submodule
git submodule update --init
# Run object box runner
...
# Get dependencies
flutter pub get
...
Sensing Plugin:
# Run pigeon code generator
run_pigeon.sh
# Get dependencies
flutter pub get
...
This is dependent on the target OS tho. Windows can't run bash scripts (atleast outside of WSL and flutter inside WSL is not too great).
In GitLab by @Slartibartfass2 on Nov 22, 2022, 18:12
I used the Git Bash for running the pigeon command as bash file. Otherwise we can find another script language which can be executed without much effort.
In GitLab by @Slartibartfass2 on Nov 23, 2022, 24:20
I tested this on the branch tmp/script-test. I added the file setup.ps1
.
On windows run:
.\setup.ps1
On linux run:
bash setup.ps1
If there are only platform-independent commands we can simply put every command in there, otherwise we would have to handle it like in https://gitlab.uni-ulm.de/se-anwendungsprojekt-22-23/sensing-plugin/-/commit/88c2b801d1e1b38836ec57feda1e5a0ca512bc84.
In GitLab by @Slartibartfass2 on Nov 23, 2022, 12:03
We use different editors/IDEs for each platform/language:
Android Studio and XCode are only required when working on the Sensing Plugin.
Install recommended plugins listed in .\.vscode\extensions.json
:
@recommended
into the search barWorkspace Recommendations
DON'T open .\android\
or .\example\
as workspace directory.
.\example\android\
so that dependencies are recognized.Android
selected) three modules are shown: app
, sensing_plugin
and Gradle Scripts
.app
contains the code for the example and sensing_plugin
the code for the plugin.Settings
-> Editor
-> Code Style
and check Enable EditorConfig support
DON'T open Xcode via right-clicking on the .\example\ios\
folder and click "Open in Xcode".
.\example\ios\Runner.xcworkspace
.We use scripts to execute shell commands for the project setup or to generate code:
bash <file name>
.\<file name>
Note: They are powershell scripts but work as bash script as well.For the setup on the Sensing Plugin and Smart Sensing Library run the setup.ps1
script.
We use the Pigeon package to generate API code for each platform.
If you edit [Insert pigeon file here e.g. .\pigeons\messages.dart
] run the pigeon.ps1
script.
We use the ObjectBox package as database system.
If you edit [Inset object box file here] run the objectbox.ps1
script.
In GitLab by @Slartibartfass2 on Nov 25, 2022, 15:53
marked this issue as related to #15
In GitLab by @Merseleo on Nov 25, 2022, 16:00
Do the Dart plugin show me a warning, if I "violate" one of these rules?
In GitLab by @Slartibartfass2 on Nov 25, 2022, 16:08
mentioned in merge request sensing-plugin!2
In GitLab by @Merseleo on Nov 25, 2022, 16:11
Please link the Tutorial how to install SwiftLint in Xcode somewhere.
In GitLab by @Slartibartfass2 on Nov 25, 2022, 16:13
Yes, in VSCode the violation will be underlinded and shown under "Problems".
In GitLab by @Merseleo on Nov 25, 2022, 16:17
But it is not very complicated to prove the style guides every time manually? Isn't this the job of the linter?
In GitLab by @Slartibartfass2 on Nov 25, 2022, 16:29
Mainly yes, I rather meant style guides which aren't enforced by the linter e.g. design patters or basic "good" design ideas.
In GitLab by @Slartibartfass2 on Nov 25, 2022, 16:31
This will be added when adding the linter which will be probably at some point in se-anwendungsprojekt-22-23&7.
In GitLab by @Slartibartfass2 on Nov 28, 2022, 18:29
mentioned in issue smart-sensing-library#31
In GitLab by @Merseleo on Nov 28, 2022, 21:49
Ok, perfect
In GitLab by @Merseleo on Nov 28, 2022, 21:49
Make sense and seems a very good idea.
In GitLab by @Slartibartfass2 on Nov 29, 2022, 24:15
Dart provides a guide on how to design a good project structure which we should follow. The following graph should be a basic design of how this would apply on our projects.
graph TD
A[Root] --> B[lib]
B --> C[src]
B --> BA(sensing_plugin.dart)
C --> CA(sensor_manager.dart)
C --> CB[generated]
CB --> CBA(api.dart)
A --> D[test]
D --> DA(sensor_manager_test.dart)
A --> E[tool]
E --> EA(setup.ps1)
E --> EB(run_pigeon.ps1)
A --> F[pigeons]
F --> FA(api.dart)
Note there's also example
as subdirectory of root
which I didn't include.
@Shiroen95 Do we need to take the ObjectBox plugin into account when designing the project structure? Which files are generated where and how are they organized?
In GitLab by @Shiroen95 on Nov 29, 2022, 14:29
The following is from the ObjectBox wiki:
Run
flutter pub run build_runner build
to generate the binding code required to use ObjectBox.ObjectBox generator will look for all
@Entity
annotations in yourlib
folder and create a single database definitionlib/objectbox-model.json
and supporting code inlib/objectbox.g.dart
Add
objectbox.g.dart
to your version control ignore list (e.g..gitignore
), otherwise build_runner will complain about it being changed each time you pull a change.
So the files kept are all in the /lib
folder. So the only thing we need to make sure is that we keep our entities somewhere in the /lib/*
folder.
In GitLab by @Slartibartfass2 on Jan 22, 2023, 20:54
mentioned in issue sensing-plugin#24
In GitLab by @Merseleo on Mar 24, 2023, 13:51
mentioned in commit c372c46e267dce840c2c78282c81f0a12123ea04
In GitLab by @Slartibartfass2 on Nov 10, 2022, 21:54
Voting
To approve a convention add :heavy_check_mark: as reaction or if you don't approve, comment what you want to be changed.
Conventions to investigate: