A matter of taste

[Dora Gustafson]

The If construct has the form:

if (condition) <statement>;

 where <statement> can be a simple statement or a block statement
In other words: a statement or a compound statement where the compound is one or more statements inside curly brackets

So this writing

if ( llGetPermissions() & 16) llStartAnimation( animation);

 and this

if (perm & 16)
{
    llStartAnimation(animation);
}

 Are both valid and they both compile to the same

If some one says one is better, I ask: what is better, define better please
If they answer that one is right and the other is wrong I say that both are right, both compile.
If they say that one is more readable I would answer: it is a matter of taste

Both abide to the compiling rules
If someone thinks there are some rules broken in either way, please tell me about it

 

Why this and why now?

I published a script on the wiki in my resident's space and someone 'broke in' and modified it for 'better readability'
I must admit I am a bit upset by it
I know the Wiki is for anybody to modify
I'd do it all the time but never in another resident's page

 

 

[arton Rotaru]

I certainly prefer the one with curly brackets. I used to write my code without them, but I ran too often into trouble when adding more code, while developing a script. So I trained myself to always write curly brackets, no matter how many statements there will be. I find it  easier also, to read scripts, that somebody else wrote, with the brackets and everything on it's own line.

Although, I prefer it this way:

if (perm & 16) {    llStartAnimation(animation);}

 

The thing about editing in a residents wiki page is a nogo for me, though.

 

[Madelaine McMasters]

---

Dora Gustafson wrote:

The

If construct

has the form:

if (condition) <statement>;

 where <statement> can be a

simple statement

or a

block statement

In other words:

a statement

or

a compound statement

where the compound is one or more statements inside curly brackets

So this writing

if ( llGetPermissions() & 16) llStartAnimation( animation);

 and this

if (perm & 16){    llStartAnimation(animation);}

 Are both valid and they both compile to the same

If some one says one is better, I ask: what is better, define better please

If they answer that one is right and the other is wrong I say that both are right, both compile.

If they say that one is more readable I would answer:

it is a matter of taste

Both abide to the compiling rules

If someone thinks there are some rules broken in either way, please tell me about it

 

Why this and why now?

I published a script on the wiki in my resident's space and someone 'broke in' and modified it for 'better readability'

I must admit I am a bit upset by it

I know the Wiki is for anybody to modify

I'd do it all the time but never in another resident's page 

---

 

Dora, there are many coding conventions which are a matter of taste, but this particular one is more than that.

I worked at a medical instrumentation company who's internal "C" coding standard required that all control flow expressions be followed by compound statements. The reasoning was that it improved readability and reduced errors. My experience there, both before and after adoption of the coding standards, showed that the reasoning was correct. I was the one who contributed the compound statement requirement to the coding standard.

Since then, the Motor Industry Software Reliability Association created "MISRA C", a coding standard for the C programming language. That standard goes well beyond the one to which I contributed, and it does require that all control flow expressions be followed by compound statements.

Abiding by the compiling rules is necessary, but not sufficient, to be considered "right". I can (and often do) craft code that compiles beautifully and doesn't work. By any sensible definition, my code would be wrong. I can also craft code that works (and so compiles correctly) but induces those who follow me years later (including myself) to misread it, misunderstand it or be lured into editing it in ways that break it.

For me, to be considered truly right, a piece of code must compile correctly, do the intended job without error, be easily and correctly understandable by others, and reduce the potential for future editing errors.

ETA: as there is no coding standard for the wiki, I wouldn't edit another's entry to make it conform to my own, even if I had empirical evidence to show that mine is better ;-)

[Madelaine McMasters]

---

arton Rotaru wrote:

I certainly prefer the one with curly brackets. I used to write my code without them, but I ran too often into trouble when adding more code, while developing a script. So I trained myself to always write curly brackets, no matter how many statements there will be. I find it  easier also, to read scripts, that somebody else wrote, with the brackets and everything on it's own line.

Although, I prefer it this way:

if (perm & 16) {    llStartAnimation(animation);}

 

The thing about editing in a residents wiki page is a nogo for me, though.

 

---

Arton, I prefer your way of bracketing as well, even though the coding standard I helped develop (mentioned in my other post) forbid it. Brackets were required to be on lines by themselves (comments were allowed). The reasoning behind this was that blocks of code could be more easily selected for editing. I sure don't like the way it looks, but during discussions with other engineers, the collective recollection was that the way you and I like it made it more difficult to grab the block.

While I find our bracketing style to be pleasing to the eye, I kick myself every time I try to select a block of code after a control flow expression because I must drag my mouse to exactly the right location in the line rather than just hit the line the bracket is on. We can sometimes be our own worst enemies!

[Rolig Loon]

Like arton and Maddy, I too prefer the conding convention with the {curly} brackets.  LSL forgives you if you omit them in the simple case you give as an example, but I have found that I am much too likely to make mistakes if I don't use the brackets consistently -- every single time.  When a client asks me to modify a script that uses the more relaxed convention, my first step is always to reformat the entire thing so that I don't get confused.  It's a matter of taste indeed, and that's my taste.

I also strongly agree with arton and Maddy that editing someone else's user page is a major intrusion.  I would be very upset if someone did that to my page, and would never do that to someone else's.

[arton Rotaru]

---

Madelaine McMasters wrote

---

While I find our bracketing style to be pleasing to the eye, I kick myself every time I try to select a block of code after a control flow expression because I must drag my mouse to exactly the right location in the line rather than just hit the line the bracket is on. We can sometimes be our own worst enemies!

---

Yeah true, that's really a drawback of that style. Probably best to train myself to write brackets on their own line. :matte-motes-not-entertained:

[Qie Niangao]

Dora, unlike everybody else posting here, I prefer to keep single-statement expressions standalone, without the curly brackets -- and when using curly brackets, keep them all alone on a line by themselves. 

I used to prefer the other approach, using curly brackets for every conditional or loop, but somehow I changed how I read code and now I find it a faster scan without them.

Pretty much always, though, I put a line-break after the condition or loop-control construct, indenting the single statement on its own line.

[Erik Verity]

Programming classes in universities and colleges always warn that specific companies, corporations, etc. (business interests and groups) will almost always have their own rules and guidelines which do not have to agree with any one particular style or international standard. They are free to do this and to an extent should; they have code that has to be read and contributed by multiple sources. It is wrong to take any organization's or company's standards or rules and define it as a right or wrong way for everybody unless it is an international standards organization, which MISRA is not.

It is also realized that the use of brackets for a single line code block in these cases is a good habit, simply for reducing errors when editing. That alone is the only real benefit - readability in this case really is a matter of taste. I often leave out the brackets for a single line in cases where I simply need more of a script I'm working on to fit in the page view without a lot of scrolling. In that sense, leaving them OFF is more readable to me - they double the verticle space needed to read the script and a simple indented line is easy to recognize.

Most of the time, I will edit a script in the end to include the brackets. I don't like to have them included in some cases of single lines and leave them out in others - inconsistency in a script's style is what would be wrong.

ETA: The same textbooks that warn against editing errors when the brackets are left off continue to print multiple code examples throughout with the brackets left off.

ETA again: While being a standards organization for software for the auto industry, not for a programming language by itself, it is more correct to identify MISRA as a business interest organization than a standards committee.

[Madelaine McMasters]

---

Erik Verity wrote:

Programming classes in universities and colleges always warn that specific companies, corporations, etc. (business interests and groups) will almost always have their own rules and guidelines which do not have to agree with any one particular style or international standard. They are free to do this and to an extent should; they have code that has to be read and contributed by multiple sources. It is wrong to take any organization's or company's standards or rules and define it as a right or wrong way for everybody unless it is an international standards organization, which MISRA is not.

It is also realized that the use of brackets for a single line code block in these cases is a good habit, simply for reducing errors when editing. That alone is the only real benefit - readability in this case really is a matter of taste. I often leave out the brackets for a single line in cases where I simply need more of a script I'm working on to fit in the page view without a lot of scrolling. In that sense, leaving them OFF is more readable to me - they double the verticle space needed to read the script and a simple indented line is easy to recognize.

Most of the time, I will edit a script in the end to include the brackets. I don't like to have them included in some cases of single lines and leave them out in others - inconsistency in a script's style is what would be wrong.

ETA: The same textbooks that warn against editing errors when the brackets are left off continue to print multiple code examples throughout with the brackets left off.

ETA again: While being a standards organization for software for the auto industry, not for a programming language by itself, it is more correct to identify MISRA as a business interest organization than a standards committee.

---

People are free to adopt standards like MISRA C, or not. The advantage of adopting standards, even if you don't like them, is that all kinds of support sprouts up about them. While we had to invent our own style checker/pretty printer for my company's ad-hoc C coding standard, such things (and far more sophisticated analyzers) are readily available for MISRA C. When I went out on my own as a consultant, I reverted to writing code "my way".

I recall being taught "top down" and "specification driven" software design in college. Both of those methods, which were completely counter-intuitive to me, proved disastrous in application when I started working at that medical instrumentation company. We designed real time systems (and by real time, I mean down to the microsecond) and the low level stuff had to be written first. It often wasn't until that was done that we really got an understanding what we'd really be able to do with the system. So we'd spend a lot of time optimizing foundational things before building atop them.

Similarly, starting with a specification and then coding to it was the dumbest idea my company had ever heard of. I agreed with this assessment, as I'd grown up with an engineer Father who claimed never to have seen a specification that was useful, much less right. He was exaggerating, but not by much.

I noodle my way to success. I try stuff, if it works, I keep it. If it doesn't, I toss it. During the decade I was on my own as a consultant, I'd rapidly turn over prototypes to clients (sometimes starting with cardboard and duct tape) and get their feedback. Twenty iterations and two years later, they'd get what they wanted and be happy campers.

I am, of course, an anecdote in the history of design. I don't recommend my way to anyone, even though it has served me frightfully well.

I do think that software is still something of an art. Even those who don't believe that often agree that software folks at least behave like artists ;-)

[steph Arnott]

I prefer this as i can read it better. But i only learned from the SL scripting book, here and making alot of stressfull mistakes.

The LSL Editor also made a ;ot of difference in my learning. I am just a amature so i can not realy say what right or wrong.

if (perm & 16){    llStartAnimation(animation);}

[Rolig Loon]

I'm right there with you, Steph.  I love reading these conversations among real scripters/programmers.  I always come away having learned something.  I also usually find that the professionals reaffirm my most important rules: (1) make it work and (2) be consistent.  It's very reassuring.  I have never had a class in computer science but those rules have helped me to write workable routines in languages from Fortran II to C++.  Compilers know really bad code when they see it, but they seem to forgive old chemists and other amateur scripters who can write logical, consistent scripts --- even if they don't match anyone's standard.

[LepreKhaun]

Users modifying other peoples userpages is a huge no-no and IMNSHO should be explicitly made a rule that, if broken, would result in that user losing their editing privileges. It leads to a lot of ill-feeling and drama on the wiki. For instance, http://wiki.secondlife.com/wiki/User_talk:Daemonika_Nightfire and a case of a teacher who had posted code examples that were being used in her classes that someone decided to "fix" which that lead to a discussion that spans across a number of places.

 

In programming style, white space (indentation of logic blocks, a space after a comma or on either side of binary operators etc) is "good" in the sense it improves readability. I personally don't feel that the opening brace requires its own line because it adds vertical white space to the code and leads to code "wrapping" across page boundaries. But that is just my own preference, I like to be able to see as much of a subroutine or event as possible whenever I'm writing it and especially when I'm debugging. In fact, when it comes to "if .. else" constructs, my preference is for:

if (test) {	// do this} else if (othertest) {	// do that} else {	//do what}

 And that goes double the more "else if" tests there are chained together. It leads to less scrolling up and down to examine everything.

 

And, because I know how code can change as it matures, I write my simple "if" statement with that in mind:

if (test) {	// do this}

 

Now, that's just how I write code. I wouldn't recommend it to anyone else and, because I respect the right of others to code in their own style, would certainly not presume to change anothers userpage to enforce it.

 

But, then again, I wouldn't try to enforce my "standards" on anyone else in a public forum either.

[PeterCanessa Oh]

 

Erik Verity:- inconsistency in a script's style is what would be wrong.

 

Madelaine McMasters:I try stuff, if it works, I keep it. If it doesn't, I toss it. During the decade I was on my own as a consultant, I'd rapidly turn over prototypes to clients (sometimes starting with cardboard and duct tape) and get their feedback.

 

Rolig Loon:(1) make it work and (2) be consistent

 

Yep to all of that.   There is nothing more useless than a script (programme) that doesn't work.  It is extremely unlikely you'll ever write more than the most trivial script that works first time and never needs editing.  The best way to ensure your logic and (re)editing - for debugging, expansion or showing-off to others - make things better is to be consistent so it is as easy to read as techno-babble can be.

As I think I've mentioned before I always told my programmers that taking the time to tidy their code showed they hadn't just "thrown it together".  Conversely untidy code made me suspect untidy logic, as well as making the consequences of that bad logic harder to debug.  We all make mistakes in programming, being tidy and consistent helps find and fix them.

Slightly different topic:

 

Madelaine McMasters:I do think that software is still something of an art. Even those who don't believe that often agree that software folks at least behave like artists ;-)

 

A member of our helpdesk team once commented that a fellow programmer was stroppy (US: grouchy, I think).  I demanded to know why I was not considered the most stroppy because I usually insisted on higher standards.  The whole helpdesk team looked at each other and commented, "He's stroppy.  You're just precious about your art.  The difference is you deliver".  I was so proud.

The reason I think software development isn't Software Engineering, as so many universities, mathematicians and, of course, engineers, think it should be is simply that every time we write something we're writing something new, at least to us.  Outside very narrow limits we can't just cut-and-paste 'boilerplate' code together to make something which is consistent in logic, variable names, etc. as well as style.  In engineering you can produce and refine a blueprint before actual manufacture.  In software defining and refining the blueprint IS writing it.  Once we've got a fully-specified plan of exactly how it's going to be done we don't hand it over to manufacturing, we run the thing!  A program IS a fully-specified plan of exactly how the computer's going to do it :-)

And back to Dora's OP:

 

Dora Gustafson:I published a script on the wiki in my resident's space and someone 'broke in' and modified it for 'better readability'I must admit I am a bit upset by itI know the Wiki is for anybody to modifyI'd do it all the time but never in another resident's page

 

Netiquette people - someone's personal page is THEIR statement.  If you disagree with something either discuss it with them or link to and 'correct' it elsewhere.  Without that it would be possible to adulterate anyone's work and claim they did/said it.

 

[Madelaine McMasters]

---

LepreKhaun wrote:

Users modifying other peoples userpages is a huge no-no and IMNSHO should be explicitly made a rule that, if broken, would result in that user losing their editing privileges. It leads to a lot of ill-feeling and drama on the wiki. For instance, 

http://wiki.secondlife.com/wiki/User_talk:Daemonika_Nightfire

 and a case of a teacher who had posted code examples that were being used in her classes that someone decided to "fix" which that lead to a discussion that spans across a number of places.

 

In programming style, white space (indentation of logic blocks, a space after a comma or on either side of binary operators etc) is "good" in the sense it improves readability. I personally don't feel that the opening brace requires its own line because it adds vertical white space to the code and leads to code "wrapping" across page boundaries. But that is just my own preference, I like to be able to see as much of a subroutine or event as possible whenever I'm writing it and especially when I'm debugging. In fact, when it comes to "if .. else" constructs, my preference is for:

if (test) {	// do this} else if (othertest) {	// do that} else {	//do what}

 And that goes double the more "else if" tests there are chained together. It leads to less scrolling up and down to examine everything.

 

And, because I know how code can change as it matures, I write my simple "if" statement with that in mind:

if (test) {	// do this}

 

Now, that's just how I write code. I wouldn't recommend it to anyone else and, because I respect the right of others to code in their own style, would certainly not presume to change anothers userpage to enforce it.

 

But, then again, I wouldn't try to enforce my "standards" on anyone else in a public forum either.

---

As I grew through the ranks professionally, I was sometimes kidded for owning (I always bought my own) "weenie" computers connected to "ginormous" monitors. I did this because, like you, I wanted to see as much context as possible, whether in a code file or a schematic diagram. Having a zippy computer that can quickly pan and zoom around a large document is no replacement for a computer which doesn't have to do that (which means my RSI afflicted body doesn't have to do it either) because it's driving a capacious (in pixels) display.

So, even though I kick myself every time I want to cut/copy a block of code from something I've written, I prefer the method you use because it squishes more onto the screen.

[Qie Niangao]

C-x-2

Come to think of it, I wonder how much "programming style" is really a side-effect of editor choice, or mere habit of which editor features we use most.

For example, I'm sure if I didn't most often have multiple Emacs panes showing different parts of the same file, I'd be a lot more jealous of vertical whitespace.

[steph Arnott]

The way I view it is that people are more willing to help with a problem if they see one has made the effort to be neat and clean in their code. If it is an unstructured mess most will just say I can not be bothered to read that. Also I really do not bother reading anything that some feel OK to type in bright blue, it just makes my eyes hurt.

[Dora Gustafson]

Let me say to everyone who commented on the subject: I have enjoyed all views
My conclusion in short is
What compile is valid and everybody is entitled to have private habits

About the other subject

---

LepreKhaun wrote:

Users modifying other peoples userpages is a huge no-no and IMNSHO should be explicitly made a rule that, if broken, would result in that user losing their editing privileges. It leads to a lot of ill-feeling and drama on the wiki. For instance, 

http://wiki.secondlife.com/wiki/User_talk:Daemonika_Nightfire

 and a case of a teacher who had posted code examples that were being used in her classes that someone decided to "fix" which that lead to a discussion that spans across a number of places.

---

This is what happened to me
My resident's 'private' wiki site was modified by the same guy
It looks like this guy roams the wiki to impose his ideas about what is right and wrong

So far I just commented the incident in the page's discussion and I also started this thread

I can undo the changes made by the intruder but can't decide if it is wise
Do anyone have an opinion about what is smart to do?

:smileysurprised::smileyvery-happy:

[PeterCanessa Oh]

IF you accept his changes then I'd just annotate them as "edited by ..." as a permanent (or, not, as we've seen) record of the fact that it isn't what you originally wrote.  If you don't accept his changes then revert them.  It's what you want to put there, after all.  As I said, it's up to him to put his 'improved' version somewhere else/public if he wants to to.

 

[steph Arnott]

I would put it back as you intended. How to stop it being changed I do not know. Others here probably help.

[Rolig Loon]

It's wise.  After all, that's your page.  Anything that is on it is your creation and should represent your style.  I wouldn't hesitate to revert the content to its original version.  Leave your note in discussion too.

[PeterCanessa Oh]

Ohhh yeah - screen real-estate ^^

People have asked me why I don't have a laptop instead of a desktop.  I've told them I don't need portability but do want reliability (less likely to go wrong), maintainability (easier/cheaper to upgrade or fix when it does go wrong) and a BIG screen (21" at the moment).

So then they ask why I want a big screen.  I tell them I want to see a lot of things at once.  They say they can look at all their photos on their 10" tablet.  I show them coding with:

 

• Eclipse editor for LSL
• Another Eclipse editor for PHP
• Browser for web-host file-transfer and organisation
• Another Browser window for checking web output from the PHP 
• Another Browser tab (usually not seen at the same time) for looking at the page source generated by the PHP
• Second Life running the LSL
• (Probably one or two diagnostics windows for whatever is required)

They say that's crazyily complicated.  I say it's what you need if you are doing cross-platform, multi-language programming.

True, you don't need all that at the same time all the time, but it certainly helps if you have it.  Considering that most languages are still easier to read if printed out on big fanfold paper I'm not sure whether that dictates our style too much though.  More than anything else it's got to be, sadly, "what I'm used to".  Some things catch my eye better because my eye has been trained to spot some things better because ... etc.

[so I want a big screen, reliable computer and not, sorry, a fashionable gadget for tweeting my favourite colour.  *Sigh* - another old colleague was a dedicated mainframe expert.  "You know I'm not interested in this space-invaders stuff" was his only comment when I showed him some Windows front-ends I was working on once.  Now I'm saying the same about sub-laptops.  I must be getting old.]

 

[Adromaw Lupindo]

When I was looking more deeply into LSL on a flight of fancy a couple of years ago, I ran into Void Singer's user page. I read some of her coding examples and read why she codes the way she codes (and it inspired me). Then I read the discussion page, http://wiki.secondlife.com/wiki/User_talk:Void_Singer#Re:_Formatting_.5Btopic_added_by_Void_due_to_page_reordering.5D .

When it comes to readibility I can not understand why someone "puts their foot down" about verbose instructions that are easy to read and understand. Where the opening brace stands has a practical function depending on how a given text editor handles opening braces; that's fine. Arguing Complaining that something is easy to read, is counter productive.

"I'm sorry the sweat of your brow isn't flowing enough for this code to be of value, this is Suduku in hard mode, friend."

I'm sure communication has to be important when not writing for oneself. Shared code isn't just for compiling, it's for communicating an authored idea and solution to a described problem. We're selling that an idea and solution is fitting and able to be produced and maintained well.

[LepreKhaun]

---

Dora Gustafson wrote:

Let me say to everyone who commented on the subject: I have enjoyed all views

My conclusion in short is

What compile is valid and everybody is entitled to have private habits

About the other subject

---

LepreKhaun wrote:

Users modifying other peoples userpages is a huge no-no and IMNSHO should be explicitly made a rule that, if broken, would result in that user losing their editing privileges. It leads to a lot of ill-feeling and drama on the wiki. For instance, 

http://wiki.secondlife.com/wiki/User_talk:Daemonika_Nightfire

 and a case of a teacher who had posted code examples that were being used in her classes that someone decided to "fix" which that lead to a discussion that spans across a number of places.

---

This is what happened to me

My resident's 'private' wiki site

was modified

by the

same guy

It looks like this guy roams the wiki to impose his ideas about what is right and wrong

So far I just commented the incident in the page's discussion and I also started this thread

I can undo the changes made by the intruder but can't decide if it is wise

Do anyone have an opinion about what is smart to do?

:smileysurprised:

:smileyvery-happy:

---

Me? I'd start a petition; with rallies, strikes, blog & forum posts and whatever else it took.

 

Userpages should be just that, as they are defined in http://wiki.secondlife.com/wiki/Project:Editing_Guidelines#.22User.22_namespace " :... Their own, personal namespace. " ... which should be considered as "... as an extended profile compared to the one inworld" And no one but themselves is allowed to alter an avatar's  profile. Right?

 

However, without a rule (which could be easily added, as well as enforced) against such misbehavior, there is little recourse other than "rolling back" ones personal pages to how they were to begin with.

 

But in the meantime, I'd speak with Strife and see  how he feels about this. But that's just my style.

[Edited for minor spelling corrections.]

[Helium Loon]

Unlike all the others, I will actually speak to the efficiency/compiler consequences of using a 'block' or compound statement instead of a simple one (when it will suffice.)

 

Do a little research on compiler theory.  One will find that whenever a 'block' opener is found, the compiler introduces a new 'thunk' or stack frame.  This is why variables defined within such a block have scope limited to that block.  It introduces a new stack, and new address references (you can add a label to a 'block', for unconditional branches, etc.)

 

However, a simple statement does not require the creation of a new 'thunk'.  Therefore, from an efficiency/speed viewpoint, using blocks in an IF or ELSE clause when not needed actually degrades the performance/efficiency of the code.  Creating a new 'thunk' requires additional memory, and has setup time.

 

Now, most modern language compilers optimize this anyway.....if only one statement is found within the braces, it will automatically simplify it to the non-enclosed version for compilation.  I'm not certain whether or not Mono does this or not.

 

So, for myself, I will continue to use BOTH formats, as appropriate.  When doing initial coding, I will use the braces everywhere.....then once the function/event/etc is debugged and working, any single-statement blocks will be pulled out of those enclosing braces.

 

[LepreKhaun]

---

Helium Loon wrote:

...

Do a little research on compiler theory.  One will find that whenever a 'block' opener is found, the compiler introduces a new 'thunk' or stack frame.  This is why variables defined within such a block have scope limited to that block.  It introduces a new stack, and new address references (you can add a label to a 'block', for unconditional branches, etc.)

 ...

---

For clarification, jump labels are scoped to the function and event levels, but not to code blocks as local variable declarations are

 

See .https://jira.secondlife.com/browse/SVC-6712? and https://jira.secondlife.com/browse/VWR-12252 .