Skip to content

Commit 6f16333

Browse files
authored
Merge pull request #9 from Bigjango13/style-guide
Add style guide and fix typos
2 parents 44c4503 + ac999db commit 6f16333

File tree

2 files changed

+132
-11
lines changed

2 files changed

+132
-11
lines changed

readme.md

Lines changed: 10 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -1,29 +1,28 @@
11
# The Sack programming language
22
> Spec v1.0.0 SemVer
33
4-
Sack is a dynamically typed scripting language for beginner programmers that focusses on readability and ease of use over speed.
4+
Sack is a dynamically typed scripting language for beginner programmers that focuses on readability and ease of use over speed.
55

66
## Goals
77

88
- Sack is Simple. A program is executed from top to bottom. This means asynchronous code is impossible.
99
- Sack is small. The specification is minimal, and easy to learn as well as implement.
10-
- Sack is Extensible. While the specification is not indended to be open ended, It should allow for new features where required.
10+
- Sack is Extensible. While the specification is not intended to be open ended, It should allow for new features where required.
1111
- Sack is Easy. Language reserved words should have their basis in common english, and code written in it should prioritize readability.
1212

1313
## Basic notes
1414

1515
- Sack's default extension is `.sk` or `.sack`. All others are considered invalid by this spec version.
1616
- Variable types can be one of the following:
1717
- String
18-
- Number (int)
18+
- Number (signed 32 bit int)
1919
- Decimal (32 bit float)
2020
- Bool (`true` or `false`)
2121
- None (`none`)
22-
- Identifier
23-
- List (Itterable Scope)
24-
- file (File object)
25-
- byte (8 bit integer)
26-
- Sack enforces a style guide to improve readability. Compilers should by default warn for violations of the style guide.
22+
- List (Iterable Scope)
23+
- File (File object)
24+
- Byte (8 bit unsigned int)
25+
- Sack enforces a style guide to improve readability. Compilers should by default warn for violations of the [style guide](style-guide.md).
2726

2827
## Syntax
2928

@@ -93,7 +92,7 @@ The following are valid booleans:
9392
let a = true;
9493
let b = false;
9594
```
96-
Because booleans (along with all other variables) are case sensitive, the following is **invalid**:
95+
Because booleans (along with all other identifiers) are case sensitive, the following is **invalid**:
9796
```
9897
let a = True;
9998
let b = fAlSe;
@@ -109,7 +108,7 @@ func a () {
109108
}
110109
```
111110

112-
You can also return none from a failed conditional, however it is reccomended that failed conditionals return false. Here is an example of a conditional that returns `none`:
111+
You can also return none from a failed conditional, however it is recommended that failed conditionals return false. Here is an example of a conditional that returns `none`:
113112
```
114113
if a > b {
115114
@@ -126,7 +125,7 @@ let b = 0b11111111;
126125
```
127126

128127
### Lists
129-
Lists are self contained scope blocks which are itterable. See the scope section for rules on scope.
128+
Lists are self contained iterable scope blocks. See the scope section for rules on scope.
130129

131130
A list is defined using square brackets like so:
132131
```

style-guide.md

Lines changed: 122 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,122 @@
1+
# Sack Style Guide
2+
3+
## Naming convention
4+
5+
Functions and variables should use `snake_case`, unless they are supposed to be used as constants in which case they should use `SCREAMING_SNAKE_CASE`.
6+
7+
Never use `l` (lower case L), `I` (uppercase i), or `O` (uppercase o), for variable names as they look too much like numbers.
8+
9+
If you don't want people to use your function/variable unless they are sure they know exactly what they are doing, prefix it with a single underscore.
10+
Variables and functions specific to a certain implementation should have two underscores, the implementations name, an underscore, and then name of the variable/function.
11+
12+
## Comments
13+
14+
Comments should be directly before the line they describe, one space should be put after the `#`.
15+
16+
Comments should start with an uppercase letter but should not end with a period, however an exclamation or question mark is allowed. For example:
17+
18+
```
19+
# Calculates foo
20+
func calc_foo () {
21+
# Returns 4
22+
return 4;
23+
}
24+
25+
# Stores foo
26+
let foo = calc_foo();
27+
```
28+
29+
## Spacing
30+
31+
Every binary operator, parenthesis, and brace should have 1 space around it, with the exception of function calls, list indexes, and semicolons. Unary operators should not have space. For example:
32+
33+
```
34+
if a[0] == -b {
35+
print( "Hello!" );
36+
}
37+
```
38+
39+
### Indentation
40+
41+
After every left brace should be an indent of 4 spaces, which should end before the closing right brace. For example:
42+
```
43+
loop (while foo > 2) {
44+
print( "Foo is greater than 2" );
45+
foo -= 1;
46+
}
47+
```
48+
49+
Trailing expressions follow the same rules but with with `[]` and `()`. For example:
50+
```
51+
takes_long_args(
52+
this_is_a_really_really_long_argument_name,
53+
these_long_names_should_change
54+
);
55+
```
56+
57+
Trailing expressions may be on the same line as other trailing expressions. For example:
58+
```
59+
let my_list = [
60+
1, 2, 3,
61+
4, 5, 6
62+
7, 8, 9,
63+
0
64+
];
65+
```
66+
67+
Trailing binary operators should have the operator on the second line, unless the binop changes the a value. for example:
68+
```
69+
let sum =
70+
a_really_long_var_name
71+
+ some_other_long_var;
72+
```
73+
74+
## Brace style
75+
76+
All left braces should be inline with the rest of the line, all right braces should be on there own line (with the exception of `else` and `else if`), for example:
77+
78+
```
79+
func foo ( bar ) {
80+
if bar {
81+
# Some code here...
82+
} else {
83+
# More code here...
84+
}
85+
}
86+
```
87+
88+
## Code location
89+
90+
Imports should always be at the top of files, and sorted alphabetically, with an extra newline after the final import.
91+
92+
All globals variables should be after imports, with an extra newline after the final variable.
93+
94+
Following after global variables should be functions. All functions should have a newline after the final `}`.
95+
96+
All other code should be at the bottom of the file.
97+
98+
## Returning
99+
100+
When returning from all branches of an `if-(else-if)*-else`, it is better to remove the else. For example:
101+
```
102+
# Wrong
103+
func is_even ( a ) {
104+
if ( type(a) != "Number" ) {
105+
return false;
106+
} else {
107+
return a % 2;
108+
}
109+
}
110+
111+
# Correct
112+
func is_even ( a ) {
113+
if ( type(a) != "Number" ) {
114+
return false;
115+
}
116+
return a % 2;
117+
}
118+
```
119+
120+
## Unary vs binary increment/deincrement operators
121+
122+
Unary increment and deincrement operators (`++` and `--`) should only be used when the value is not needed, they should not be used when `+=` or `-=` would work.

0 commit comments

Comments
 (0)