Ceylon coding style

(Ceylon) failed its transition to Eclipse and the community gave up.

-- Eclipse Ceylon Termination Review

Avoid ... then ... else ...

I feel A then B else C confusing.

Readers may think A then B else C means A ? B : C in other languages, but they are not the same:

1. A then B else C is actually (A then B) else C:

   • A then B evaluates to B if A is not null, otherwise evaluates to null.
   • X else Y evaluates to X if X is not null, otherwise evaluates to Y.

2. Thus the type of B is T given T satisfies Object, i.e. requires to not be null.

Avoid foo { "bar"; }

In Ceylon, foo { "bar"; } and foo { "bar" } are semantically different, which may be confusing.

Either write foo("bar") or foo { parameter = "bar"; }, never write foo { "bar"; }.

Occasionally, foo {"bar"} may be used. But foo({"bar"}) is often preferred.

Prefer switch case over if else.

Cases in switch need to be both disjoint and exhausted. Using a strict form helps to reduce chances to miss corner cases.

For example, suppose we have the following code:

1Path path = current;
2if (is Directory path) { // typo, should be `path.resource`.
3    // ...
4} else { // dead code
5    // ...
6}

There is a typo in the above code, path should be path.resource. So the above code will never go into the else branch, since a Path is always not a Directory.

However, if we use switch with explicit cases:

1switch (path)
2case (is Directory) {
3    // ...
4}
5case (is File|Link|Nil) {
6    // ...
7}

The compiler will refuse to compile, saying cases are not exhausted.

switch can also be used as a workaround of Ceylon's assignment returnning assigned value:

 1variable Boolean b = false;
 2if (b = true) {
 3    print("typo in the above line: `=` should be `==`");
 4} else {
 5    print("Use switch to avoid this mistake.");
 6}
 7
 8switch (b)
 9case (true) {
10    print("Avoid typo of `==`.");
11}
12case (false) {
13    print("assignment should not return a value in Ceylon.");
14}

Pay attention to compiler warnings

If necessary, use annotation to suppress false positive warnings.

For example:

 1"The ultimate exception handler."
 2suppressWarnings("expressionTypeNothing")
 3shared void run() {
 4    try {
 5        main();
 6    } catch (UsageError e) {
 7        process.writeErrorLine(e.message);
 8        process.exit(e.exit_code);
 9    }
10}

Failures

Use exceptions for failures that are unrecoverable by immediate calling code, like bugs in program logic, network failure, and so on. So they can be handled by some centric infrastructure code.

Use return values (union types) for recoverable failures.

Be careful with side-effect functions. They are not type safe as side-effect functions with checked exceptions in Java. The ceylon compiler does not force you to check function's return value when invoking functions as side-effects. For example, when getting return value from result = f(); where f is Result?(), Ceylon does force you to check whether result is null or not. However, invoking f as side-effects f(); will silently ignore its return value, without checking for failures.