bobjackman

class SomeClass {
  String foobar;
  
  void someMethod(String newValue) {
    if (foobar == null) {
      foobar = newValue;
    }
  }
  
  // OR //

bobjackman

class SomeClass {
  String id;
  String foo;
  String bar; // required
  String zap; // required
  
  SomeClass.fromMap(Map<String, dynamic> inputMap) {
    this.id  = inputMap['ID'];
    this.foo = inputMap['Foo'];
    this.bar = inputMap['Bar'];

bobjackman

class SomeClass {
  String _foobar;
  String get foobar => _foobar;
  // note: no setter defined = can't write new values
  
  SomeClass(this._foobar);
}

bobjackman

# Dart Coding Standards - LiveNinja Development

## Conventions
The key words `MUST`, `MUST NOT`, `REQUIRED`, `SHALL`, `SHALL NOT`, `SHOULD`, `SHOULD NOT`, `RECOMMENDED`, `MAY`, and `OPTIONAL` in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) and summarized as follows:

1. `MUST`   This word, or the terms `REQUIRED` or `SHALL`, mean that the definition is an absolute requirement of the specification.

1. `MUST NOT`   This phrase, or the phrase `SHALL NOT`, mean that the definition is an absolute prohibition of the specification.

1. `SHOULD`   This word, or the adjective `RECOMMENDED`, mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

bobjackman

// DON'T DO THIS
if ((user != null && user.id.isNotEmpty && targetId == user.id) || (user.name.isNotEmpty ? user.name : '') == targetName || (phoneNumber.isNotEmpty && phoneNumber == user.phoneNumber)) {
  //...;
}

// DON'T DO THIS
if (
  (user != null && user.id.isNotEmpty && targetId == user.id)
 || (user.name.isNotEmpty ? user.name : '') == targetName

bobjackman

Handlebars.registerHelper( 'select-options', function( items, selectedValue, options ) {
	// ======== Ensure `items` is Object/Hash
	if( items instanceof Array ) {
		var temp = {};
		for( var i in items ) {
			var value   = items[i];
			temp[value] = value;
		}
		items = temp;
	}

bobjackman

• Show number of commits that exist in develop, but NOT in the current branch (is my branch sync’d with develop? Should return 0)
  git rev-list HEAD..origin/develop --no-merges | wc –l
• Show number of commits that exist in develop, but NOT in master or vice-versa (have master and develop diverged?)
  • (have master and develop diverged in some way? Irrespective of current branch – should return 0)
    git rev-list origin/develop...origin/master --no-merges | wc -l
  • (does develop have anything not in master? Irrespective of current branch – should return 0)
    git rev-list origin/develop..origin/master --no-merges | wc –l
  • (does master have anything not in develop? Irrespective of current branch)
    • (just a total number of commits – should return 0)
      git rev-list origin/master..origin/develop--no-merges | wc –l

bobjackman

#!/usr/bin/env bash

# usage:
#		git-stats #gives stats for the whole branch
#		git-stats --author="yourname here" #gives stats for specific author
#
# though not all tested, this should be compatible with all limiting options supported by git-log (https://www.kernel.org/pub/software/scm/git/docs/git-log.html#_commit_limiting)

git log --pretty=tformat: --numstat $@ "`git merge-base HEAD develop`..HEAD" | gawk '{ adds += $1 ; subs += $2 ; net += $1 - $2 ; gross += $1 + $2 ; commits += 1 } END { print "total commits\tadded loc\tremoved loc\tgross loc\tnet loc\n"; printf "%d\t%d\t%d\t%d\t%d\n", commits, adds, subs, gross, net }' | column -s $'\t' -t

bobjackman

#!/usr/bin/env bash

# usage:
#     local branches only:  `myUnmerged`
#     remote branches only: `myUnmerged -r`
#     all branches:         `myUnmerged -a`
#
# example output:
#
# BRANCH            TOTAL    COMMITS KOGI    KOGI UNMERGED

bobjackman

Normally, if you register views and controllers (with the same name), when they're instantiated, Ember automatically wires them up to each other. view.controller points to the controller you'd expect and both view.content and controller.model are bound to each other. If one changes, so does the other.

However, registering everything with the App means your App namespace gets very polluted, and you have to be very careful choosing your names so you don't collide with views/controllers being defined/used elsewhere in the App. Also, sometimes you have a view/controller that you're only using in one very specific place and it's just kinda silly to have it registered and accessible at a "global" level. In these cases, it's logical to NOT register your views/controllers, but that means things don't get magically wired up by Ember and things don't work the way you'd normally expect.

If you don't register your view/controller, then when you try {{view MyUnregisteredView contentBinding="myModel"}}, you get a