brl.stream

BlitzMax Forums/BlitzMax Module Tweaks/brl.stream

ProfJake(Posted 2010) [#1]
I cleaned up the stream module a little bit.
The functionality is exactly the same, but now it is SuperStrict and a lot easier to read - cleaner code - in my opinion.



Do you know if Mark takes these changes and put them into the official modules if they're good enough?


plash(Posted 2010) [#2]
Well he's not going to use code that renames members (even if it's just the case of names). You should have stuck to the naming scheme already in-place, and the tabulation on the docs is horrible.


ProfJake(Posted 2010) [#3]
The question was more general anyway.

But why do you think the tabulation is horrible? Tabulation in general or just in this case?
(I used the default MaxIDE in Mac OS X)

What do you suggest?


markcw(Posted 2010) [#4]
Mark uses Strict all the time as obviously, he prefers it. Same for the tabs.

As a general rule if you're co-editing some source you shouldn't change the 'house style' ie. the formatting rules prefered by the original author. You should only fix mistakes and leave everything else alone, the "if it's not broke don't fix it" rule.

So as far as I can see, nothing you did there was an improvement. Not trying to be harsh but the only thing brl.stream actually needs is some good example code.


ProfJake(Posted 2010) [#5]
But isn't SuperStrict supposed to be a little bit faster, as well as a lot cleaner?


markcw(Posted 2010) [#6]
Nope, SuperStrict is definitely not "faster" than Strict.

Strict enforces variable scope declarations and SuperStrict enforces data type declarations. They are only compiler directives, so it's just down to personal preference.


plash(Posted 2010) [#7]
Nope, SuperStrict is definitely not "faster" than Strict.
I'm not entirely sure on that part. I can see SuperStrict code being parsed faster, though.

If given the permission and means to effectively overhaul all the docs and cleanup code, I would switch the code to SuperStrict in a heartbeat.
Sometimes it isn't even clear (until you poke around at the code) whether a function or method returns a value or not due to Strict's implicit Int-typing (and especially so for type members, as they tend to get the short-end of documentation).