fn under_threshold (self ) -> bool {
if let Some (reset_threshold) = self .config .reset_threshold () {
self .terminal .portion_covered () < reset_threshold
} else {
true
}
}
To read code in the first place, you make sense of the syntax as you go.
Just by looking you can tell that if
is a keyword, that
do_thing()
is a function call and that 100
is a
number – no highlighting required.
We can only stand so many different bright colours in our code before it becomes an overwhelming rainbow. Let’s give colour to those elements of code that are particularly confusing and lead to bugs easily.
This is a debatable topic, but I would argue that there are a few clear contenders:
Here’s some code that has all four – try to spot them.
fn do_thing () {
var api = JsonApi .connect ();
loop {
if api.read_value () == 294 {
print ("Success!" );
"127.0.0.1:8080" .make_current_socket (api);
}
print (api.connected_socket );
}
}
fn do_thing () {
var api = JsonApi .connect ();
loop {
if api.read_value () == 294 {
print ("Success!" );
"127.0.0.1:8080" .make_current_socket (api);
}
print (api.connected_socket );
}
}
How did the make_current_socket
method appear on the string
literal? It came from an interface, which is now obvious due to the bright
colour. The magic numbers and strings stand out more, as does control
flow.
make_current_socket
modifies its arguments, which would’ve
surprised us with the old theme when we printed the API’s connected socket
and found it had changed. With this theme, the underline lets us know
beforehand. api
’s underline shows that it can be mutated, an
additional reminder.