Difference between revisions of "User talk:Void Singer"

From Second Life Wiki
Jump to navigation Jump to search
Line 16: Line 16:
<p>Ah, the style wars, long shall they rage.</p>
<p>Ah, the style wars, long shall they rage.</p>
<p> 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. --[[User:RJ Thibaud|RJ Thibaud]] 12:25, 23 December 2007 (PST)</p>
<p> 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. --[[User:RJ Thibaud|RJ Thibaud]] 12:25, 23 December 2007 (PST)</p>
== RE: style etc ==
{{messge}}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 reccomend, 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.

Revision as of 12:13, 25 December 2007

Comments:

Question2.JPG Comment Format

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

Question2.JPG 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]

Question2.JPGIt 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)

Question2.JPGAmazing. 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

Template:Messgeheh, 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 reccomend, 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.