Scalastyle proposed rules (Headers)

This page contains proposed rules for Scalastyle. These rules are from Checkstyle, and do not necessarily apply to Scalastyle.

Headers

Header

Checks that a source file begins with a specified header. Property headerFile specifies a file that contains the required header. Alternatively, the header specification can be set directly in the header property without the need for an external file. Property ignoreLines specifies the line numbers to ignore when matching lines in a header file. This property is very useful for supporting headers that contain copyright dates. For example, consider the following header:

line 1: ////////////////////////////////////////////////////////////////////
line 2: // scalastyle:
line 3: // Checks Scala source code for adherence to a set of rules.
line 4: // Copyright (C) 2011 SEGL
line 5: ////////////////////////////////////////////////////////////////////

Since the year information will change over time, you can tell Scalastyle to ignore line 4 by setting property ignoreLines to 4.

RegexpHeader

Checks the header of a source file against a header that contains a regular expression for each line of the source header. Rationale: In some projects checking against a fixed header is not sufficient, e.g. the header might require a copyright line where the year information is not static. For example, consider the following header:

line 1: ^/{71}$
line 2: ^// scalastyle:$
line 3: ^// Checks Scala source code for adherence to a set of rules\.$
line 4: ^// Copyright \(C\) \d\d\d\d SEGL$
line 5: ^// Last modification by \$Author.*\$$
line 6: ^/{71}$
line 7:
line 8: ^package
line 9:
line 10: ^import
line 11:
line 12: ^/\*\*
line 13: ^ \*([^/]|$)
line 14: ^ \*/

Lines 1 and 6 demonstrate a more compact notation for 71 '/' characters. Line 4 enforces that the copyright notice includes a four digit year. Line 5 is an example how to enforce revision control keywords in a file header. Lines 12-14 is a template for scaladoc (line 13 is so complicated to remove conflict with and of javadoc comment).