Monday, May 18, 2015

White Space

Posted by Jason Lillywhite

The way you use white space in your GoldSim expressions can make a significant difference in readability. In this post, I walk through a series of examples that illustrate my personal preferences and pet peeves, which I hope might be useful for you as you establish guidelines within your modeling team.

Consistent and careful use of white space in GoldSim can significantly increase readability by making operators more visible, improving text wrapping, and creating emphasis on important parts of the equation. I see a lot GoldSim expressions that have no spaces and find it quite difficult to read. I have to say that this is probably my biggest pet peeve when it comes to GoldSim modeling style. A software developer once said it pretty well on a forum where someone asked if spaces should be used in expressions:
Spaces rock. I like to imagine that people who prefer no spaces live in very cramped, very crowded cubicles. source
Below, I have listed some various use cases that compare different ways of using white space with my personal preference indicated next to the "just right" label. These are contrasted with "too little" and "too much" white space examples, which annoy me.

Math Expressions

Too little space:     b+y*(1+x_left^2)^0.5+y*(1+x_right^2)^0.5

Just right:               + y * (1 + x_left^2)^0.5 + y * (1 + x_right^2)^0.5

Too much space:    + y * ( 1 + x_left ^ 2) ^ 0.5 + y * (1 + x_right ^ 2 ) ^ 0.5


IF Statements

Too little space:      if(Inflow_Capacity-Fraction_of_Treated*Inflow>Inflow,Pump1,0l/s)

Just right:                if(Inflow_Capacity - Fraction_of_Treated * Inflow > Inflow, Pump1, 0 l/s)

Too much space:    if ( Inflow_Capacity  -  Fraction_of_Treated  *  Inflow  >  Inflow , Pump1 , 0 l/s )

Alternatively, IF statements in GoldSim can use "then" and "else" statements instead of punctuation as seen in the example below. Obviously, this expression wouldn't work at all unless you added white space around the "then" and "else" statements.

Just right:             if(Inflow_Capacity - Fraction_of_Treated * Inflow > Inflow then Pump1 else 0 l/s)

It is also important to note the structure of complex units in GoldSim: white space is not allowed within the definition of the units themselves so "l/s" cannot be written as "l / s". It is debatable whether a space should be added between a number and its unit dimension. In the case above, the "L" for liter might be confused with the number 1 so I felt a space is needed. But there are many who would argue that a space before a "%" sign is not needed (e.g. 25%), so I would treat this on a case by case basis, leaning towards no space before the units.

Conditional Statements

Once again, my general preference is to add space after commas and also around conditional operators but not around the parenthesis or before commas.

Too little space:      if(x=4&&y>=1,b,c)

Just right:                if(x == 4 && y >= 1, b, c)

Too much space:     if ( x == 4 && y >= 1 , b , c )

There are a couple of items to note from the above examples: I prefer to use the double "==" for conditional statements as opposed to the single "=" even though both are acceptable and interchangeable in GoldSim's syntax. The reason for my preference is that the double equal sign differentiates it from a variable assignment, which must always use a single "=". The other note is that you cannot add white space inside the "<=" or ">=" operators.

Again, conditional statements in GoldSim can use "then" and "else" statements instead of punctuation as seen in the example below.

Just right:         if(x == 4 and y >= 1 then b else c)

Vector and Matrix Expressions

My preference is that white space should be used after commas but not before or after parentheses or brackets and definitely not before a comma.

Too little space:        vector(ore[1],waste[3,2])

Just right:                  vector(ore[1], waste[3, 2])

Too much space:      vector( ore [ 1 ] , waste [ 3, 2 ] )

Line Breaks

GoldSim automatically places line breaks in your expressions with priority on white spaces. If you leave out white spaces, you might find a line break added to your expression in unexpected ways, as shown in the following examples.


Here is an example where the line break was added at a multiply operator. Notice that the subtraction operator is difficult to see without spaces.


This same expression is much more readable, IMO, with spaces added as shown. Also note that the line break was added after the comma, which I feel is more appropriate and allows me to read the math expression and variable names more readily.

The example below illustrates how GoldSim chooses a bracket for the line break.
If white space is added to the math operators, then the line break is instead added after the math operator, which allows the name along with the array item "Calcium" to be shown on a single line.

As seen in the example below, the text wrapping moved part of a variable name "Percent_ANFO_as_N" to the next line. With spacing added, the entire name was shifted to the next line because text wrapping prefers white space over underscores.



In general, you should always use a format that works best for you and your team. Many of my preferences mentioned above are a matter of personal opinion and perhaps you disagree with some. If so, please feel free to let me know how your opinion differs. I'd love to know your views and I'm also willing to change mine if I see a good reason behind it.


No comments:

Post a Comment