[rules] Coding Standards

Squeak

General Codestyle Rules

Do not put a period at the end of blocks or methods.
Example:

foo

    ^ [self break.
       self]

Put an empty line after a method's declaration.
Example:

foo

    | bar |
    ...

If you need to comment a method, place that comment right below the declaration.
Example:

foo
"This method is super crucial, don't change!"

    | bar |
    ...

Declaration of temporary Variables comes after the empty line underneath the method declaration.
Example:

foo

    | bar |
    ...

When commenting a specific line of code, do so in the line above the one you are commenting.
Example:

    ...
    "This line is a workaround, if you know a better solution, feel free to fix it"
    <line in question>
    ...

When writing a block or placing parentheses, do not put spaces behind the opening or in front of the closing bracket.
Example:

    ...
    [[outStream nextPutAll: (inStream upTo: $_).
      inStream atEnd ifFalse: [outStream nextPut: inStream next asUppercase]]
    ...

When writing a block for e.g. a doWhileTrue message, please indent the content of the blocks so they align with the first letter of the first character that is not a bracket in the first line. Or in mathematical terms, one Space per opening bracket.
Example:

    ...
    | color |
    [color := Color random.
     color blue = 1] doWhileTrue
    ...

Binary message sends always need to be surrounded by a space.
Example:

    ...
    point := x @ y
    ...

Pipes, for example in variable declarations, need to be surrounded by spaces.
Example:

foo

    | bar |
    ...

Generally, when naming instance or temporary variables, as well as parameters, do not use abbreviations like req for request or res for response. Instead, use the actual words, and try to be as descriptive as possible. Long names are okay, we have autocompletion for that. :)

Try keeping your methods short. A length of 7 lines is appropriate, everything else probably could be refactored.

There are exceptions to these rules, especially to the line-length one. If you feel like you found one, note it down in this document, or, even better, find out how the formatting could be improved and post the solution here.

Method Classification

• examples - Auf Klassenseite, example Methoden
• initialize-release
• testing - Zustandsabfrage, z.B. isModel oder canGoForward
• constants
• accessing
• colors - spezielle getter und setter, die mit den colorSchemes zu tun haben
• callbacks

Refactoring

As a general rule, any small refactorings such as renaming variables into a better fitting name, or moving pieces of code into a new function should be done as you go about the code.

If you find bigger issues, like a mistake in the current architechture, and do not have time to fix them right now, please create an issue here on GitHub, mentioning the method(s) that need to be reworked, as well as place a self flag: #REF "short explanation of issue + GitHub issue number" in the corresponding piece of code.

Python

Refer to PEP 8 Standard.