User talk:Void Singer

Comments:

Comment Format

=== Topic === <-- this line is optional
{{message}} this is my comment
~~~~ <-- will be replaced by User Name + Time Stamp automatically

welcome all to my User Talk page. Feel Free to leave a message below, and thanks for stopping by! --Void Singer 05:54, 20 November 2007 (PST)

Re: Formatting [topic added by Void due to page reordering]

It looks well thought out. I'm pretty laid back about style as long as it's consistent. The only thing I put my foot down on is tabs being 4 spaces. All a matter of preference thou. I find prefixing variables with anything other then a letter to indicate type is overkill. I write my LSL as ESL (which is LSL passed through a C precompiler) and I reserve all uppercase lettered names for ESL macro's and defines. -- Strife Onizuka 03:09, 3 November 2007 (PDT)

Amazing. I've been programming for 25 years and have developed a style that chooses the opposite of most of Void's rules. Why is it that these questions lead to such equally satisfactory results in competent programming organizations that are so different. I suppose that it's similar to the reason that Spanish isn't the same as French.

I'll go Strife one further, though, and put my particular foot down about the insane (to me) verbosity of prefixing variables, function names, etc. with garbage characters that serve no useful purpose I can see, and is constantly bonking the reader who has to read through several largely irrelevant or self-evident characters to get to the important part - what the variable is. It's like getting tapped on the side of the head with a pencil every time I trip over one of the darn things. Is this another sad legacy of Microsoft? I'd never seen such a thing before I had to start writing Windows code. And I'll note, I work in RL in an environment where we have several hundred thousand lines of legacy code I have to refer to regularly, (and a couple of legacy programmers) that use "Hungarian" notation like this, and after 10 years of reading it I STILL get tapped every time I see one.

I do have one possibly pertinent point, though. I had been ambivalent about where the brace at the opening of a block goes for a couple years, having programmed in environments for most of my time where they were to be on a (wasteful) line of their own. After spending some time in Java, where the convention tends to be 'on the same line' I was still uncertain I had an opinion, except that I really don't like the effect that mixing the styles has. (That happens with templates, copy/paste, etc.) However, a few weeks ago when working on some poor code (mine) that was too long and nested too deeply I spent quite a while tracking down a missing opening brace. I realized that had it been on its own line I'd have seen it almost immediately. Given modern monitor resolutions and sizes, I don't think the vertical height saved is worth the obviousness that it exists.

So there, finally the definitive answer to the "same line or different line" question.

Ah, the style wars, long shall they rage.

In the end, as both you and Strife observe, it is all personal preference as modified by the need to be consistent with those you work with. Thanks, much, for taking the time to write it down. I should do it too if I care so much I guess. --RJ Thibaud 12:25, 23 December 2007 (PST)

RE: style etc

heh, thanks for reading it at least, I'm not fanatical about it, each person develops their own style, and to be honest I only adapted the style I normally use for lsl, from my other coding projects, so it's prone to updates (a few of which I've yet to add in). The particular style I use is geared towards maximum understanding of the code for those new to scripting/programming so they can more easily find their way through code. But as noted, for an experienced coder it can be a bit like 'duh I know that'. Coming from an enviroment with lots of new coders though, I tend to keep it up for their benefit more than my own. The opening brace debate is long running with me, and I do realize the pro's and cons, but have gotten myself in the habit of expecting open braces on the same line, and visually reading the statement (if, do, etc) and the indent as opening the statement and even briefly played with inlining the closing statement (but found it interfered with the visual nesting effect sometimes).

I mostly provided the example style as something to explain, rather than recommend, because I was bored enough to write it one day, and had been asked a few times about it. I have found that prefixing of some kind tends to avoid collisions with developing languages like lsl, as I noticed happened once or twice when people named constants or variables that later became LSL constants, and I've discouraged a few people from using llFunctionName for that and other reasons (like people that see the call and try to use it elsewhere). I'ts all good though, whatever gets the job done and works as expected. Void Singer 13:35, 25 December 2007 (PST)

0x80000000 X_X

Yep I forgot about 0x80000000. The limit however accepts 2038 and then overflows. So I wrote a version that detects overflows and accepts the entire integer range. It should be noted that if you get clever on it, and give it a year before 1970 but have the final date fall in or after 1970 it will have a fit. Likewise for years after 1969 but the final dates fall before 1970. Could turn off the overflow detection for centrally located years but that's more work. But it will parse [2100,12,13,23,59, -2147483648] and [1845, 1, 1, 0, 0, 2147483647] properly... i think. =^_^= -- Strife ^{(talk|contribs)} 06:28, 20 January 2010 (UTC)

I'll take a look in a bit, and I do like the integer division and bit shift solution in the unix2stamp, much cleaner... in the other, subtracting out 68 less to make the entire range positive... I like that part, shouldve done it from the start (it was converted from a quickie 1970+ version that I think argent did) although I had capped the dates to provide symmetry with the opposite function (since it's much easier to cap that one on a particular day, and 19 days on the edge seemed a small loss, vs detecting up to the last available second)... haven't checked the leap day / month detection in the loop replacement but I'll assume it's good until I double check. ps, I appreciate the fixes (always something to be learned) but can we separate out revisions that are more than corrections or order changes... it makes it harder to compare versions side by side (as the wiki only gives changed lines)... not complaining, I appreciate the feedback... PPS bad cabbit you didn't test to be sure? =)
-- Void ^{(talk|contribs)} 23:37, 20 January 2010 (UTC)