Coding conventions

Formatting

• Always put a space before and after a binary selector, as well as inside blocks.
• Name method arguments like aFoo and not foo.
• Name temporary variables and instance variables like foo and not aFoo.
• Properly indent your code using tabs, not spaces.
• No unnecessary parenthesis.
• No unnecessary blank lines, except after the method comment, temps declaration, long methods (>= 5 lines) or 'guard' statements, such as shouldReturn ifTrue: [ ^ self ]..
• Always use yourself in cascades.
• Use each as an argument name of iteration blocks.
• Add a space at the beginning and end of a temporary variable declarations and blocks.
• Avoid unnecessary statement separators.
• Close multiple blocks on one line, exception can be made for #ensure: and #on:do: blocks
• Keep methods as short as possible (up to ~5 lines is ok).

Method protocols

• Private methods go to the 'private' protocol
• Initialization methods go to the 'initialization' protocol
• Accessing methods go to the 'accessing' protocol
• Error methods go to the 'error handling' protocol
• Unit test methods go to the 'tests' protocol

Comments

• The first comment of a method should state the use of the method. Keep it short, but ensure that these are valid sentences starting with an uppercase letter and end with a full stop.
• Avoid comments within the method body when not needed or intention revealing.
• Class comments are mandatory
• Referring to Github issues is OK in method comments, but not in class comments.

Patterns

• Do not create classes with methods on the class-side only, instead think of another approach or use the singleton pattern instead.

Initialization

• #initialize should always send super initialize
• When using initialization methods other than #initialize, do not send self initialize.
• Constructors must send #new and not #basicNew to ensure object initialization

Unit tests

• Use self assert: actual equals: expected instead of self assert: actual = expected where possible

Cross-platform dependencies

Amber core developers use a variety of operating systems. Therefore, we do not want to introduce dependencies that are not cross platform compatible. The amberc command line compiler and the build system have been rewritten based on Node.js instead of Bash scripts to support this.

(This page is freely adapted from Seaside coding conventions