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:
src/
 org/
  example/
   hades/
    main.hd
libs/
project.json
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.
src/
 org/
  example/
   hades/
    main.hd
    weather.hd
libs/
project.json
And the import statement would look like this:
with connection.client from weather.hd
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:
with webStarter as starter from startWebServer.hd //Gets the webStarter class proto from startWebServer.hd
with startWebServer.hd as web sets address="localhost", port=8080 //This would just execute the script
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):
project.json - Contains the project configuration, initial data (config, connection keys, etc...) and meta-data of libraries installed via Hermes.
libs/ - Source files of libraries
src/ - Upper most directory for source files
 org/ - Organization tld
  example/ - Organization name
   testing/ - Project name
     main.hd - Entrypoint
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
%set VERSION 0.7.1%
%set APPLICATION_NAME My Application%
Functions (Lower Camel Case)
func addTwoNumbers(a int,b int) -> int
    put a + b
end
​
class ClassWithFixedFunction
    fixed func addTwoNumbers(a b int) -> int
        put a + b
    end
end
Classes (PascalCase)
class Person
    var id int
​
    @public
        var firstname string
        var lastname string
    end
end
Structs (PascalCase)
struct Person
    var id int
    var firstname string
    var lastname string
end
Protos (Lower Camel Case)
with list from std:collections
Native library names
with list from std:collections
with car from nativeLib:domain
with button from gui:controls
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:
var pow = { x,y => 
    var result = 1
​
    while(y not 0)
        result *= x
        y--
    end
​
    put result
}
​
var add = {x,y => x + y} //Simple lambda, don't need a put statement
Same for match:
var fruit = "Apple"
​
match(fruit)
    "Apple" => { _ =>
        console.out("Apples are really tasty!")
        console.out("I like apples!")
    }
    fruit.type() is :string => { _ => console.out("Variable is a string")} //Simple lambda
end
Pipelines
Pipelines don't have indentation. A pipeline statement uses the indentation of the pipeline source.
with list fixed from std:collections
​
func filterAndPrint(fruits, filterBy="a")
    list.of(fruits)
    |> map(??, {x => x.toLower()})
    |> filter(??, {x => x.startsWith(filterBy)})
    |> forEach({x => console.out(x)})
end
​
{"Apple", "Banana", "Mango", "Kiwi", "Avocado"}
|> filterAndPrint //For methods with only one parameter, brackets can be omitted; results in filterAndPrint({"Apple", "Banana", "Mango", "Kiwi", "Avocado"})
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.
with console from std:io
with file from std:io
​
try
    file.read("hello.txt")
catch(e)
    //ignored
end