Coding - Best Practice

[Citadel]

Hi all

Continuing to play with Xbasic. I don't want to learn bad habits, and I know that some ways of coding work but aren't necessarily the best way to code.

An extremely simple example. This code works...

Line1 = "Hello World"
NewText = Line1 + crlf() + file.to_string("MoreText.txt")

But this code looks/feels tidier to me, and is probably easier to understand when I revisit it in 5 years time, yet has 50% more lines of code (imagine this 50% applied to every script in a large app)...

Line1 = "Hello World"
Line2 = file.to_string("MoreText.txt")
NewText = Line1 + crlf() + Line2

Is either one better code? And why?

[CALocklin]

Re: Coding - Best Practice

My two cents:

Line1 = "Hello World"
NewText = Line1 + crlf() + file.to_string("MoreText.txt")

The above is better because it has fewer assignments (equal signs) and, therefore, runs a few milliseconds faster. It would even be faster as simply:
NewText = "Hello World" + crlf() + file.to_string("MoreText.txt")

Line1 = "Hello World"
Line2 = file.to_string("MoreText.txt")
NewText = Line1 + crlf() + Line2

The above is better for exactly the reason you mentioned - it will be easier to understand later. And, forget 5 years. Five DAYS, or even just 5 hours, may be enough if, like me, you will be working on other jobs in the interim. (Today was a good day, I only had to work on 2 different apps and answer questions about 2-3 others. But it's only 7:30 pm and there's another customer expecting to have his update finished this week, too.)

My overall preference - go with "easier to understand" whenever the time difference isn't an issue. That usually means any time you are not running a lot of loops.

AND - speaking about saving time later - don't forget to use lots of comments. Yes, it takes a bit longer to add the comments initially but they can save a LOT of time later when debugging or updating. I even find that adding comments before writing the code even helps to focus my thinking about what I'm trying to do.

Speaking of avoiding bad habits, if you haven't already, you might want to check out my A5 Naming Recommendations. Even if you don't follow them to the letter, at least it will give some "thoughts to ponder".

And, here's another hint that may come in handy someday when you are concatenating something in a long loop: (don't bother with it if just adding two strings together as a one-time deal)

Use the *concat() function when concatenating multiple lines in a loop. NOTE: This is NOT the *concat_lines() function!! According to the Help file the *concat_lines() function is much faster than simply using the "+" sign. However, that is not true according to my tests - they were almost identical in speed. However, the *concat() function is at least 15 times faster on my machine.

The *concat() function is in the Help file but you have to know how to spell it first. It doesn't show up under the "Character Addition Functions" listing. Note that it is also used differently than most functions - it does NOT return a value. It simply updates the value of the first argument. ALSO IMPORTANT, unlike *concat_lines(), it is a simple concatenation of two strings. The *concat_lines() starts each argument on a new line - just like the name implies. However, if you want to start the second variable on a new line when using *concat(), you must include a crlf().

Here's a comparison for resetting "var1" where var1="Hello" and var2="World":

var1 = *concat_lines( var1, var2 )
vs.
*concat( var1, crlf() + var2 )

In either case, the result in var1 will be:
Hello
World

Without the crlf() in the *Concat() function the result would be:
HelloWorld

Disclaimer: I haven't tested the speed of something like *concat_lines( var1, var2, var3, var4, var5, var6, ....). That may be much faster than using the "+" sign to concatenate all those lines. However, if you are concatenating just two strings - which is the way it usually works in a loop, I know the *concat() function is much faster than either *concat_lines() or the "+" sign. (The *concat() function only takes two arguments.)

[csda1]

Re: Coding - Best Practice

Hi all

Continuing to play with Xbasic. I don't want to learn bad habits, and I know that some ways of coding work but aren't necessarily the best way to code.

An extremely simple example. This code works...

Line1 = "Hello World"
NewText = Line1 + crlf() + file.to_string("MoreText.txt")

But this code looks/feels tidier to me, and is probably easier to understand when I revisit it in 5 years time, yet has 50% more lines of code (imagine this 50% applied to every script in a large app)...

Line1 = "Hello World"
Line2 = file.to_string("MoreText.txt")
NewText = Line1 + crlf() + Line2

Is either one better code? And why?

Except for User Interface (UI), I generally go for speed, as it always is needed as tables get larger. Alpha takes a long time to do assignments (equals), but is very fast at expression evaluation. So if you want to pre-compute common expressions, it often is slower that repeating it (within reason) as in

a=var1+3
b=(a^2)+a+6
c=a+25

is slower than

b=((var1+3)^2)+(var1+3)+6
c=(var1+3)+25

Your mileage may vary depending on the number of substitutions and the complexity of the extracted sub-expression.

The reason the 2nd is better is because if you have to change strings (for multiple languages or to fix it), you can put it all up at the top of the code, making it easier to change.

For coding practices, visit my tips pages here.

[GaryRockley]

Re: Coding - Best Practice

It's a good question and one that you should strive for as you develop and learn more - especially since what may be true with a simple example may not be true as you learn to create ever more complicated code.

All too often, those of who claim to be programmers will align ourselves to a method without re-evaluating simplicity and speed as things become more complex.

For example, it is true, as a general rule of thumb, that the fewer the lines of code, the quicker the execution because the compiler has less to evaluate but, sometimes, you have to sacrifice an apparently elegant solution if, again for example, a returned response leads to multiple branches of code. In this instance, a more complex and time consuming evaluation could be more efficient if it leads to less branching.

This aside, most of what I see as lacking, in a developer sense, is not so much efficiency of code, but error handling.

For me, and I'm sure my users (if they never see a problem) then error handling becomes an unsung hero. It is easy to lose sight of error handling when trying to be just a tad more efficient.

Strive to be an error handling expert, and the logic/efficiency of code will probably follow all by itself.

Regards,

Gary