"Matthew backend" to "main" pull request for Jon Perry

[Punchwood2003]

Thank you again for agreeing to review my code. Most of my commits can be found in the following folders:

• "lib\Backend\Authentication*"
• "lib\Backend\Collaboration*"
• "lib\Backend\Event_Manager*"
• "lib\Backend\Finance*"
• "lib\Backend\User_Creation*"

Various other integration snippets can be found in the following files:

• "lib\Frontend\Authentication\login.dart"
• "lib\Frontend\Authentication\register.dart"
• "lib\Frontend\Calendar\calendar.dart"
• "lib\Frontend\Collaboration\collaboration.dart"
• "lib\Frontend\Event_Manager\events_home.dart"
• "lib\Frontend\Home_Page\eventHome.dart" - Integration responsibilities fell on me for this one as a result of some team issues. Integration for this page was rushed.
• "lib\Frontend\Settings\settings.dart" - Similar issue to the one above. Documentation is sparse for this one as a result.

Feel free to go as hard as you would in a professional setting. Only room to improve 👍 Thanks again 🙏

[dcjmp90]

Overall, this was really well done code!

There are a lot of things I'm leaving out about singletons, supers, named constructors, caching, and memory consumption, but I am evaluating this at an entry level bar.

The biggest thing I see missing, and I know this was done in the nick of time, but I would suggest unit testing and functional testing for every piece of code. Coverage of tests matters greatly. The main point of this is ensuring as an application grows and evolves, we will always catch issues if someone modifies another related piece of work that happens to break functionality of your code. Also helps reviewers have peace of mind that is does function as intended. The last thing you want is to deploy or merge code that breaks the system you're working on. I will do a 1:1 to show a little more into testing. Here is the dart code base for testing booleans.

I slapped together this tutorial on class initialization with some getters and their idea of how to init classes via constructor. Again, the most proper way would to have a base/abstract, utilizing getters and setters, error checking and assertions within construction.

I didn't follow documentation/commenting standards, just a class object standard:

class Tutorial {
  late String name;
  late int id;
  late bool isReady;
  late DateTime timeStamp;
  late DateTime expiration;
  // Creating Constructor
  Tutorial(this.name, this.id, this.isReady, this.timeStamp);
 
  // get the name of this class object
  String get getName => name;
 
  // get the age of account as of today's time stamp
  Duration get ageOfAccount => DateTime.now().difference(timeStamp);
  
  // get this class' expiration as of now
  Duration get getExpiration => expiration.difference(DateTime.now());
}

void main() {
  final now = DateTime.now();
  final startOfAccount = DateTime.utc(2000, 1, 1);
  String name = "Dart fun";
  int randomId = 5;
  bool isReady = true;

  // Creating Instance of class
  Tutorial dart = Tutorial(name, randomId, isReady, startOfAccount);

  print(dart.getName);
  
  String newName = "Dart is a little strange";
  
  dart.name = newName;
  
  print(dart.name);
  
  int days = dart.ageOfAccount.inDays.toInt();
  double years = days / 365;
  print("accout is ${years.toInt().toString()} + years old");
  
  DateTime newAgeOfAccount = DateTime.utc(2010, 1, 1);
  dart.timeStamp = newAgeOfAccount;
  days = dart.ageOfAccount.inDays.toInt();
  years = days / 365;
  print("accout is now ${years.toInt().toString()} + years old");
  
  int subscriptionLength = 14;
  DateTime subscription = now.add(Duration(days: subscriptionLength));
  dart.expiration = subscription;
  
  print("Expires in ${dart.getExpiration.inDays.toString()} days!!");
}

[dcjmp90]

This is a solid start to a class comment block!
There is a clear and concise meaning to this class.

After clearly explaining what it is, there should always be a section for initialization, if you have an initialization of said object ( what it takes to build an instance of), and you should always have a usage/code block example. You can find a detailed example in the docs here. This code explanation will make your class objects or any large/key function effective for fresh eyes. These are called backtick fences.

[dcjmp90]

Author information and high level file docs should be written at the top of file. Typically there is another file for contributors to input information. Here is an example of it in the dart code repository.

[dcjmp90]

I love the usage of getters and setters along with the "pseudo" private variables. Typically you can collapse those getters and setters to being represented like getting the name of a class with this code stub:
String get getName => name;

From darts docs:

class Rectangle {
  double left, top, width, height;

  Rectangle(this.left, this.top, this.width, this.height);

  // Define two calculated properties: right and bottom.
  double get right => left + width;
  set right(double value) => left = value - width;
  double get bottom => top + height;
  set bottom(double value) => top = value - height;
}