User:Cow Taurog

From Second Life Wiki
Revision as of 09:56, 24 April 2014 by Cow Taurog (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

If you want to ask me something, leave me a message on my talk page, or IM me.

A few (all) people seem to find my style of writing scripts to be rather unorthodox, but I find through my own experience that it makes it easier to look at things and be able to tell what they are at a glance, and edit just one line of code without having to spend more time selecting than typing. I am the sole creator of any LSL script I have listed in my userspace unless otherwise noted, not including PHP or any other text, or any functions that have come from a script library or other source (proper attribution will be given, if the license info is available). Any script that I have created is free to copy, modify, and yes, even sell. Everything under my userpage is licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported license. I might even help you out with any questions you have. I don't mind teaching, so ask me, online or not. If you're using my scripts, or editing them in this wiki (feel free, I can always revert or edit if I don't like it), they must be under the same license, and keep these points in mind...

  • I don't use spaces, unless they are part of a string.
  • I hardly ever use comments. I find them redundant, as the code already tells me what it does.
  • I use the one true brace style, all that whitespace is annoying and unnecessary.
  • I name variables as you would name an object in VB. I think using all caps should only be reserved for constants. (glList for a global list, gsString for a global string, lList for a local list, sString for a local string, gfFloat, grRotation, and so on). Exceptions are counters such as integer i, and handlers such as integer listen0.
  • I always use curly brackets to enclose any flow control statement (if, else, while, etc). Using tabs alone isn't enough, it might still not compile, makes syntax troubleshooting hard, and you have to add brackets if you add too much code inside them later anyways.
  • Be bold.