Styleguide

Style should be similar to the one used morphic.

If you have a question which is not covered by the style guide, extend the styleguide and inform the team members about your changes

Behavior when coding

git

• Write short and descriptive commit messages.

• Check what is being merged, don't just accept everything

• Run tests before pushing new changes

• Notify group when changing external files. When external files are changed, reset hard before pushing

Looks of code

general

• mind spelling

• check code after copy&paste

• avoid direct access when not needed, use self..

empty lines

no empty lines at beginning

SomeClass>>doSomething
  "comment"
  | temp1 temp2 |
  self abandon.

not even when there is no comment or variables

SomeClass>>doSomething
  self abandon.

indentation

only indent one tab per level, no adjustment to receiver of cascade, etc.

^ someObject
    message;
    veryLongKeywordMessageWith: aParameter1
        with: aParameter2
        with: aParameter2;
    yourself

return

no dot after return, space after ^

^ true

temporary variables

in general: only use them if you need them more than once, else it may be better to create a new method for it

method names

camelcase, they should start lowercase

blocks

• descriptive iterator names

• no dot at end of block

• return of last statement will be returned [nice to know]

examples for a good block:

submorphs do: [:aMorph | aMorph adaptToWorld: aWorld].

(cache == nil)
  ifFalse:
    [str := cache at: aSymbol ifAbsent: [#’’].
    (str == #’’) ifFalse: [^str]].

category names

We write categories all lower case and with a space between the words, eg:

• stepping and presenter

• initialization

don't put so much effort into these, i guess we have to do in the end anyways

class names

use camel case and prefix GmClassName

class comments

Classes in GM-Core start with: A GMClassName is a ....
Classes in GM-AcceptanceTest and GM-Test start with: This is a ...