Chapter 14. Style Guide

Many programming languages have a style guide (document describing the recommended syntax for whitespace, naming, and other conventions). This chapter will cover the official recommendations for spacing and braces, naming conventions, and best practices.

14.1 - Spacing and Braces

14.1.1 Style - Spacing

As you may have noticed in all of the code examples in this book, there is almost always a space separating an operators from expressions. For example, the proper way to represent four plus seven is 4 + 7. This is true with function calls and declarations as well. The best practice for declaring a function in Hassium is func name () and the best practice for calling a function is name ().

One exception to the spacing rule is with some unary operators. i ++ can look very confusing when in a large expression, so it is best practice to write i++.

14.1.2 Style - Braces

The { } braces in Hassium have a proper style for placement. In the Microsoft style, braces have their own line, starting under a statement and ending on that same position. A Microsoft if statement would look like this.

if (4 > 5)
{
    println ("Good!");
}

In Hassium however, it is proper to place the first brace on the same line as the statement. This same code would be written in Hassium as the following.

if (4 > 5) {
    println ("Good!");
}

This format looks much more clean and saves lines in a source code file.

14.2 - Naming Conventions

14.2.1 Convention - Locals and Functions

Local variables and functions are to be named using lowercase. This means that the first word in the name shall be lowercase, while the following words will be capitalized. The following are valid Hassium declarations.

a = 0;
apples = 0;
thapples = 0;
numberofapples = 0;

func apples ()
func getapples ()
func getnumberofapples ()

14.2.2 Convention - Classes, Modules, Enums, Traits

Classes, modules, enums, and traits are to be named using PascalCase. This means that each word in the name shall be capitalized. The following are valid Hassium declarations.

class A
class Apples
class AppleCounter
class TheAppleCounter

IO
Net
Drawing

14.3 - Best Practices

14.3.1 Practice - Chaining if Statements

When chaining if statements, it's best to have else if statements on the same line as the closing brace of the previous. Here is a proper way to chain an if statement in Hassium.

if (4 > 5) {

} else if (9 == 2) {

} else if (2 < 4) {

} else {

}

14.3.2 Practice - Counter Variable Names

It it best practice to begin by using the variable i as a counter variable. If you are using a nested loop, then progress to using j, then k, then all the way to z. For example loop at the following nested loop code example.

for (int i = 0; i < 100; i++) {
    for (int j = 0; j < 100; j++) {
        for (int k = 0; k < 100; k++) {
            printf ("i:{0} j:{1} k:{2}\n", i, j, k);
        }
    }
}

14.3.3 Practice - Using Private Class Members

When designing a class in Hassium, not all of the functions or other data members need to be accessed from outside the class. For instance, you could have a function that formats data for your other functions to use. This function does not need to be accessed from outside the class, and presenting it as a normal function could be confusing to people that want to use your class.

To prevent an outside class from accessing a data member, the priv keyword is used. Let's first create a class that has no private data members, then add priv where necessary.

class NumberTransformer {
    func new (num : int) {
        this.num = num;
    }

    func doublevalueashex () : string {
        return getHexValue (this.num * 2);
    }

    func getvalueashex () : string {
        return gethexvalue (this.num);
    }

    func gethexvalue (n : int) : string {
        return "{0:x2}".format (n);
    }
}

While this class is acceptable, the function gethexvalue does not need to be publicly accessible. To fix this, prefix the gethexvalue function declaration with the priv keyword.

priv func gethexbalue (n : int) : string

14.3.4 Practice - Ordering

When writing the data members of a class, it is best practice to start by declaring subclasses, followed by subenums, subtraits, properties, then functions. When declaring each of these components, it is best practice to alphabetize the data members.

The following demonstrates the proper way to order members inside a class.

class SampleClass {
    class FirstClass {

    }

    class SecondClass {

    }

    class TheClass {

    }

    enum FirstEnum {

    }

    enum SecondEnum {

    }

    enum TheEnum {

    }

    trait FirstTrait {

    }

    trait SecondTrait {

    }

    trait ThirdTrait {

    }

    datamember { get { return null; } set { } }

    nextdata { get { return null; } set { } }

    thedata { get { return null; } set { } }

    func new () {

    }

    func first () {

    }

    func second () {

    }
    func second (x) {

    }

    func third () {

    }
}

Note how the two functions named second did not have an extra line break between them. This is because overloaded functions are grouped together without this extra new line.

results matching ""

    No results matching ""