There isn’t yet an actual style guide for Reykjavík. This file is basically a reference to Rogue Wave’s The Elements of Java Style. For the most part, their recommendations hit the nail on the head, conceptually at least, even if the literal syntax is different. However, some rules have to be changed or removed because of the differences in the language. This file documents those changes.

The following terms are used to describe the differences:

implied
The rule is unnecessary because it is implied or required by Reykjavík’s syntax.
irrelevant
The rule is unnecessary because Reykjavík handles the feature in some way that obviates the rule.

There have been 13 rules eliminated, 6 simplified, and 1 modified from the 108 contained in The Elements of Java Style. These are the changes:

5. Indent nested code.
Recommend three space indentation, not two. Placement of the braces is irrelevant, as Reykjavík has a pure block syntax.
6. Break up long lines
If a method call creates a long line, it should be broken as follows: 
object.methodName \
   label: parameter \
   anotherLabel: parameter \
   yaLabel: parameter
and method declarations should be maintained on a single line, even if it creates a long line.
28. Establish and use a set of standard names for trivial “throwaway” variables.
Don’t recommend as many trivial variable names. The ones for Coordinate, Exception, and Stream are acceptible, the others should be avoided.
29. Qualify field variables with this to distinguish them from local variables.
Implied. Reykjavík requires the instance prefix on all members.
64. Label closing braces in highly nested control structures.
Largely implied by the pure block syntax. However, it is sometimes useful to list the opening parameter at the end of ifs, switches, etc. E.G., end if // foo == ERROR
65. Add a “fall-through” comment between two case labels, if no break statement separates those labels.
Irrelevant. cases are blocks, and there is no concept of fall-through.
67. Consider declaring classes representing fundamental data types as final.
Irrelevant. There is no concept of final classes.
70. Define subclasses so they may be used anywhere their superclasses may be used.
Largely implied by design-by-contract. However, while good contracts in the superclasses help, this does not prevent all cases of bad subclassing.
71. Make all fields private.
Irrelevant. As access to attributes directly and through accessors work identically in the public interface, accessors only need to be used when some functionality not satisfied by invariants must be handled.
73. Wrap general-purpose classes that operate on java.lang.Object to provide static type checking.
Irrelevant. General-purpose classes are replaced by generic classes, which provide this specialized interface automatically.
74. Encapsulate enumerations as classes.
Largely irrelevant because of enumeration shorthand. This is only needed by more complex enumerations where higher order functionality such as strict ordering is required.
76. Use block statements instead of expression statements in control flow constructs.
Irrelevant. For the same reason as rule 5.
78. Always code a break statement in the last case of a switch statement.
Irrelevant. For the same reason as rule 65.
79. Use equals() not == to test for equality of objects.
Irrelevant. Operator overloading allows == to work the intuitive way.
81. Do not call nonfinal methods from within a constructor.
I would like to call this irrelevant. It seems to me that methods called from a constructor should invoke the method on the constructor’s class, not the derived class. But I have not put sufficient thought into this to determine if it’s actually correct or feasible.
89. Program by contract.
Largely implied. This is handled in and encouraged by the syntax of Reykjavík. However, the programmer still has to remember to do it.
90. Use dead code elimination to implement assertions.
Irrelevant. require and ensure blocks wrap pre and post conditions, and their inclusion in the binary is determined by the compiler, so dead code classes are unnecessary.
91. Use assertions to catch logic errors in your code.
Irrelevant. An invariant block can be used to ensure certain conditions are always true. This eliminates the need for assertions scattered throughout the code.
92. Use assertions to test pre- and postconditions of a method.
Irrelevant. require and ensure blocks contain pre- and postconditions without relying on assertion calls.
95. Use synchronized wrappers to provide synchronized interfaces.
Irrelevant. An object can be constructed non-exclusive if the programmer is sure it will be used in only a single thread. This means that separate exclusive and non-exclusive classes are unnecessary.