search

ModdingFox / OpenFuraffinityClient

A toy project of mine to build an unofficial furaffinity client for android
11 stars 1 forks source link

refactor #130

Closed dizyaa closed 2 years ago

dizyaa commented 2 years ago

There is too much to refactor. This is only the first part

ModdingFox commented 2 years ago

Doing an initial look through. Now ^.^

ModdingFox commented 2 years ago

refactor: build files - Looks fine though would like to keep the versioning as a date type format for releases.

refactor: rename - Id like to get some understating to the why on the renames. Also to my understanding Java naming convention is to always start with a lowercase letter and camel case it. Granted I probably broke plenty of standard conventions along the way already that is one that is fairly consistent.

refactor: auto reformat code - Nice yeah I coulda probably been a bit more consistent on a few things formatting wise.

docs: add todo - Probably not needed

Update README.md - Only thing the todo at the bottom its much nicer

Note - I still have to run this thru and build/test. I know a few thing it warned should be final cant be or things break.

ModdingFox commented 2 years ago

Also could you create some issues in the project for this stuff and tagg their #'s to this pr

dizyaa commented 2 years ago

PR is not completed.

dizyaa commented 2 years ago

refactor: build files - Looks fine though would like to keep the versioning as a date type format for releases.

refactor: rename - Id like to get some understating to the why on the renames. Also to my understanding Java naming convention is to always start with a lowercase letter and camel case it. Granted I probably broke plenty of standard conventions along the way already that is one that is fairly consistent.

refactor: auto reformat code - Nice yeah I coulda probably been a bit more consistent on a few things formatting wise.

docs: add todo - Probably not needed

Update README.md - Only thing the todo at the bottom its much nicer

Note - I still have to run this thru and build/test. I know a few thing it warned should be final cant be or things break.

1) Symantic Versioning 2) The class name and field name are the same. Have to import along with the package name.

private imageView imageView // not working
private com.example.app.imageView imageView //shit import

3) You can add specific config for your Android studio 4) Ok, its will move to README.md

ModdingFox commented 2 years ago

refactor: build files - Looks fine though would like to keep the versioning as a date type format for releases. refactor: rename - Id like to get some understating to the why on the renames. Also to my understanding Java naming convention is to always start with a lowercase letter and camel case it. Granted I probably broke plenty of standard conventions along the way already that is one that is fairly consistent. refactor: auto reformat code - Nice yeah I coulda probably been a bit more consistent on a few things formatting wise. docs: add todo - Probably not needed Update README.md - Only thing the todo at the bottom its much nicer Note - I still have to run this thru and build/test. I know a few thing it warned should be final cant be or things break.

1. [Symantic Versioning](https://semver.org/)

2. The class name and field name are the same. Have to import along with the package name.
private imageView imageView // not working
private com.example.app.imageView imageView //shit import 
1. You can add specific config for your Android studio

2. Ok, its will move to README.md

  1. Semantic versioning is great when used for and api or an application to which other apps will use and sit on top of. Mainly as it provides context to changes and the likely hood of that breaking down stream applications and how significant changes to it are. Though this app doesn't serve downstream applications. I would think more seriously about semantic versioning if the parts that scrape pages and build the page objects that are used by the rest of the app where a separate project/dependency as there would be that type of affect on changes. For this app the significance of change are not really relevant so semantic versioning would add little value. CalVer(https://calver.org/) provides context around the date of build and optionally release on that date while requiring minimal thought to the significance of changes.

  2. Ow, but very fair point on the import can it at least be starts with lower than remainder camelCase.

  3. Yeah I'm aware on that one I have been rolling with the default auto format and forgetting to run it before checking in at times. I have been meaning to configure Checkstyle for a bit but have not had time to futz with it. I might just add an issue in to at least act as a reminder for me to eventually do that ^.^