Practices you may see in use but you’ll regret using

Some code looks enticing – but in the long run may cause you as many headaches as it solves.

Some is really innocuous looking like :

var position as integer = otherString.IndexOf(EndOfLine)
var leftChars as string = otherString.left(position)
var rest as string = otherString.Middle(position + 1)

There’s an assumption in this little bit of code and it may not be entirely obvious what it is.

Try it on a mac and its probably fine. And on Windows it makes a mess. The reason is the EndOfLine marker on Windows is of course two characters not 1 and so the assignment of rest is wrong and off by 1.

The fix is to simply use the Length of EndOfLine instead of 1. Note that autocomplete dislikes EndOfLine.Length and it wont compile forcing you to use a temporary variable for this. see this bug report and you appear to not be able to extend it since there’s a global method and class with the same name in the framework.

The following works but you end up declaring a variable to hold the EOL char(s).

var position as integer = otherString.IndexOf(EndOfLine)
var leftChars as string = otherString.left(position)
var eol as String = EndOfLine
var rest as string = otherString.Middle(position + eol.length)

Another that I’ve run into is TextInputStream.ReadLine. The issue here is that if you assume ReadLine reads “one line” then you can be in for a surprise since “one line” depends on what line endings are in use in the file.

If you’re on macOS reading lines from a file from Windows then the lines will include half of the Windows end of line marker (which is 2 bytes – &h0D + &h0A)

And TextinputStream has no mechanism built in to say “please translate line endings as you read” which would be really handy. So you either read all the text in (hoping its not GB of data) and use ReplaceLineEndings, or read “line by line” and clean them up. Or write a new Class that wraps a binary stream that does allow you to specify both an encoding and whether line endings should be converted to the platform specific ones. I chose the latter route. I’ll see about publishing my class on my Github

Any others you’ve run into that look simple and clear but are actually problematic ?

5 Replies to “Practices you may see in use but you’ll regret using”

  1. AAAAARGH! So THAT’S where things went wrong! Thanks – at last some clarity! 👍

    1. Yeah EndOfLine is a wonder.
      There a function, EndOfLine that returns a class, EndOfLine.
      You can see this with a line of code like

      Dim eol As EndOfLine = EndOfLine
      break

      That class then has several methods on it including operator_converts, Mac, Unix, Windows, etc

      That class could implement Length since doing

      Dim eol As EndOfLine = EndOfLine
      Dim i As Integer = eol.length
      Break

      won’t compile. eol’s operator_convert to string wont be used in this case

      That said EndOfLine was, in this case, the lesser of the two issues I was working to solve

  2. Ah but this spurs an idea since EndOfLine IS a class 😛

    Public Function Length(extends e as EndOfLine) as integer

    Dim s As String = e

    Return s.length

    End Function

    Done !

Comments are closed.