Coding Conventions

HadesLang Doc
Search…
Overview
Getting Started
Coding Conventions
Source code organization
Source file names
Hades files can either be script files (non instantiable proto), resource files (with instantiable protos like classes or structs) or mixed files (both script and resource files).
Script files
Script files, in Hades, are named after their function. If a script calculates something, call it calculateSomething.hd, if a script starts up a web server, call it startWebServer.hd and so on and so forth.
Resource files
Since there are no namespaces in Hades, the closest thing to a namespace structure is nesting classes and naming the source file after the highest, unique sub-namespace name.
So for a project that is organized like so:
1
src/
2
 org/
3
  example/
4
   hades/
5
    main.hd
6
libs/
7
project.json
Copied!
With a class called connection and a subclass called client, in the namespace org.example.hades.weather (so the full class name of client would be org.example.hades.weather.connection.client), the correct filename would be weather.hd.
1
src/
2
 org/
3
  example/
4
   hades/
5
    main.hd
6
    weather.hd
7
libs/
8
project.json
Copied!
And the import statement would look like this:
1
with connection.client from weather.hd
Copied!
Mixed files
Mixed files can be both script and resource files, so they can be executed as a script, but you can also load classes or structs from it. Mixed files use the same naming convention as script files.
So the import statements would look like so:
1
with webStarter as starter from startWebServer.hd //Gets the webStarter class proto from startWebServer.hd
2
with startWebServer.hd as web sets address="localhost", port=8080 //This would just execute the script
Copied!
Project structure
For smaller projects, just put the source files in one folder.
For bigger projects, use the Hades project initializer, which creates a Hades project with the following structure (example for a project with the organization name example.org and the project name testing):
1
project.json - Contains the project configuration, initial data (config, connection keys, etc...) and meta-data of libraries installed via Hermes.
2
libs/ - Source files of libraries
3
src/ - Upper most directory for source files
4
 org/ - Organization tld
5
  example/ - Organization name
6
   testing/ - Project name
7
     main.hd - Entrypoint
Copied!
Naming rules
Most things in Hades follow Lower Camel Case, except for preprocessor variables which are uppercase and underscore separated, and native libraries which are named like so: native library name : library file. Classes, constructors and struct names follow PascalCase while proto names are in Lower Camel Case.
These are not "best practices". These are just recommendations. If you wish to change these conventions for your project, do so.
Preprocessor variables
1
%set VERSION 0.7.1%
2
%set APPLICATION_NAME My Application%
Copied!
Functions (Lower Camel Case)
1
func addTwoNumbers(a int,b int) -> int
2
    put a + b
3
end
4
​
5
class ClassWithFixedFunction
6
    fixed func addTwoNumbers(a b int) -> int
7
        put a + b
8
    end
9
end
Copied!
Classes (PascalCase)
1
class Person
2
    var id int
3
​
4
    @public
5
        var firstname string
6
        var lastname string
7
    end
8
end
Copied!
Structs (PascalCase)
1
struct Person
2
    var id int
3
    var firstname string
4
    var lastname string
5
end
Copied!
Protos (Lower Camel Case)
1
with list from std:collections
Copied!
Native library names
1
with list from std:collections
2
with car from nativeLib:domain
3
with button from gui:controls
Copied!
Formatting
Lambdas
Lambdas that have more than one expression (complex lambdas) are formatted like Java methods (the parameters on the first line) and need a manual put:
1
var pow = { x,y => 
2
    var result = 1
3
​
4
    while(y not 0)
5
        result *= x
6
        y--
7
    end
8
​
9
    put result
10
}
11
​
12
var add = {x,y => x + y} //Simple lambda, don't need a put statement
Copied!
Same for match:
1
var fruit = "Apple"
2
​
3
match(fruit)
4
    "Apple" => { _ =>
5
        console.out("Apples are really tasty!")
6
        console.out("I like apples!")
7
    }
8
    fruit.type() is :string => { _ => console.out("Variable is a string")} //Simple lambda
9
end
Copied!
Pipelines
Pipelines don't have indentation. A pipeline statement uses the indentation of the pipeline source.
1
with list fixed from std:collections
2
​
3
func filterAndPrint(fruits, filterBy="a")
4
    list.of(fruits)
5
    |> map(??, {x => x.toLower()})
6
    |> filter(??, {x => x.startsWith(filterBy)})
7
    |> forEach({x => console.out(x)})
8
end
9
​
10
{"Apple", "Banana", "Mango", "Kiwi", "Avocado"}
11
|> filterAndPrint //For methods with only one parameter, brackets can be omitted; results in filterAndPrint({"Apple", "Banana", "Mango", "Kiwi", "Avocado"})
Copied!
Tabs vs spaces
It is absolutely irrelevant whether you choose tabs or spaces for indentation. As long as you stay consistent and don't mix tabs and spaces, it doesn't matter.
Miscellaneous
Ignored catch block
If you choose not to handle a exception, mark the block as ignored with a comment.
1
with console from std:io
2
with file from std:io
3
​
4
try
5
    file.read("hello.txt")
6
catch(e)
7
    //ignored
8
end
Copied!