Programming Tips - some general programming tips RRS feed

  • General discussion

  • I've just been doing some reading and thought it might be helpful to share some thoughts I got from it.

    1. Read as much as you can. Perhaps (60 coding: 40 reading/talking/listening) for beginners. Some say this pans out to be 20:80 for pro's.
    2. Are there bad programmers?  Yes and no. No. Most programmers are likely to write bad programs from time to time but then comes improvement. And yes. Unethical, mischievous and or morally bankrupt "programmers". On that, anyone who runs you program places a huge amount of trust in you. Stewardship.
    3. Keep an open mind. Ditch your ego and realise that your code is not the best and other peoples code is not garbage. That said still develop your own style but by considering the talent of others.
    4. Code refactoring. Do it but be careful not to over do it. I just refactored some code and went overboard with naming variables so now I have to refactor my refactored code.
    5. The client is always right. (this is my opinion). Whilst the client doesn't know all of the details involved in the development of good code, they're the ones who ultimately decide whether the program (it's outer performance) is really any good or not. The outer workings of the code is their domain, the internal details are ours. Of course there's a grey line of give and take because some things aren't practical.
    6. Practice and read up on naming variables. This could be influenced by the size of the program, the context and where and how close the variable is to where it's being used. http://www.makinggoodsoftware.com/2009/05/04/71-tips-for-naming-variables/
    7. Skill up on your program building skills.

     The build has become a bit of a "holy grail" of Small Basic programming for me. It's the beginning of how I can put all the various Objects, methods, properties, key words, variable naming, techniques, tips etc together to make more featured, readable, extensible and enjoyable programs.

    Build Basics would include things like:

    1. top down planning, i.e. looking for the forest and not just staring at the trees (details). Some say it's good to write stuff down on paper first as a guideline, maybe a design plan and some psuedocode. Easier said than done, especially for beginners. Also I find my planning at this stage is done by getting my hands dirty and coding up the highest levels of the code. E.g. making sure events and other important processes work before i add all the details. Also at the top of my planning is setting the array names that i will use to add some of the detail. I do all this bit by bit and in separate files and so begins my build and build-ins. I now find myself needing to get out a pen and paper but not too much at this stage.
    2. Builds will be individual, temporarily independent bits of code that perform a specific function. Use writeline statements to "unit test" them and get to the bottom of how they work.
    3. Build-ins are when a thoroughly tested build component is worked in to the rest of the code. Use lots of writelines to "End to End test" them. i.e. make sure all the program works from all the inputs to all the outputs when each build is built-in.
    4. When finishing your builds and build-ins don't settle for saying "this should work". The word should will most likely end up creating bugs and causing the program to break. Try to finalise each build and build-in with: "that is doing exactly what it's supposed to do and I know exactly how and what it's doing." 

    Ok, that's enough. Because it's important to talk with other programmers please share any comments on the accuracy of this. I've used some new terms that i may not completely understand.

    Oh btw, somethings I've been trying not to do are use excessively long statements that run off the edge of the editor (i use text.append) to glue them together. Also i'm trying not to use too many abbreviations.

    Monday, October 21, 2013 10:17 PM

All replies

  • Oh, also find out what "camel casing" is.

    And find out, and think about what adjective before verb is in naming variables and subs. But it's not always applicable.

    • Edited by Jibba j Tuesday, October 22, 2013 7:14 AM changed noun with verb
    Monday, October 21, 2013 10:28 PM
  • Some very nice tips, Jibba Jabba. Sure to help a lot of people, I'm sure. :3

    Tuesday, October 22, 2013 12:56 AM
  • Thanks 8bit. Hope so.

    It's interesting. I learn mainly from this network then try and plug it back in as relevant as possible to the Small Basic paradigm. It sort of helps me consolidate a bit and by way of communicating with other programmers it helps validate any good stuff or re-learn any misguided stuff.

    btw your posts always impress me. Your communication skills are superb and I always learn something from your posts.

    Tuesday, October 22, 2013 2:12 AM
  • Oh, why thank you! it means a lot. c:>

    Tuesday, October 22, 2013 2:18 AM
  • These are great tips!

    Here's a tip that I would like to share - checking out coding tips that are targeted toward other languages. These days, programming languages have so much in common that some tips are applicable to many languages.

    One example that I've run into is optimizing nested For loops. It's natural to do something like this:

    For a = 1 to 10
    for b = 1 to 10
    Shapes.Move(MyShape, x+a, y+b

    However, x+a runs 100 times but should only run 10 times. A Java tutorial I was reading at my local library suggested speeding up nested loops by moving the x+a construct to the outer loop:

    For a = 1 to 10
    z = x+a
    for b = 1 to 10
    Shapes.Move(MyShape, z, y+b
    I've gotten good results from doing something like this and I read about it in a Java book!

    Wednesday, October 23, 2013 9:10 PM
  • I do that and lotsa more as much as possible. I'm very hard-core about pre-calculations! Especially before entering a loop, I cache everything I can!  :D

    I also love backwards loops! Of course, when the order isn't important:  @_@

    arr = "1=Pineapple;2=Mangosteen;3=Açaí"
    For i = Array.GetItemCount(arr) To 0 Step -1

    This way, multiple callings to Array.GetItemCount() are avoided, after keyword To!

    And if the order is important, I cache the condition in a variable:

    arr = "1=Pineapple;2=Mangosteen;3=Açaí"
    len = Array.GetItemCount(arr)
    For i = 0 To len

    And I also program in Java. Although not directly, but using Processing! ^_^

    Click on "Propose As Answer" if some post solves your problem or "Vote As Helpful" if some post has been useful to you! (^_^)

    Wednesday, October 23, 2013 10:13 PM
  • Thanks heaps for that goto. This shows that when learning a high level language we can still learn some efficient methods. And thanks heaps Anthony.
    Thursday, October 24, 2013 1:45 AM
  • I don't think Array.GetItemCount() is calculated every run through the loop, but only once before the loop starts.

    Actualy the use of   To Array.GetItemCount  is even quicker then the use of  len=Array.GetItemCount !!

    I tested 1000 runs of a loop through an array of 100 variables. (calculation of len outside the loop)

    With  1 To Array...  it took 8.4 seconds (tested 3 times)

    With  1 To len         it took 8.7 seconds (also tested 3 times)

    Jan [ WhTurner ] The Netherlands

    Thursday, October 24, 2013 9:17 AM
  • I appreciate the logic of these posts.

    1. Pre-calculations before loop (caching) and the reverse loop; and
    2. Testing it as a hypothesis

    A lot must go on internally.

    e.g. I've been playing with a program that involved removing shapes, did some tests and found that the shapes are removed from the GW but are internally indexed.  SMD323

    I'm going to try and test using clock but in the test i'll include results with the IDE running and the IDE closed. I'll do it this way to test for any optimisation, following that experience I had with Timer optimisation.

    Thanks for the posts 8bit, Anthony, Goto and WhTurner. This is very helpful content.

    • Edited by Jibba j Thursday, October 24, 2013 5:56 PM
    Thursday, October 24, 2013 5:28 PM
  • Here's some interesting results for the above test. It's a rush job and I've gotta go to work.

    It takes a while to start as loop is 10,000 and I've only run it with ide running.

    XDM902   , will explore a bit more later and try and reach a conclusion.

    Thursday, October 24, 2013 8:44 PM
  • I just finished a test on the cache/pre-calculation and reverse loop. (as best I know how).  PPL460

    Some good practice for me.

    Assuming my test is adequate I'm confident that the Reverse Loop is nearly 3 times faster and that the caching/pre-calculation is a touch faster again. That's a lot.

    Thanks again Anthony and goto for this excellent tip. Coolest tip I've got yet. Will definitely be using this.

    I'll post a pic of the same program with the ide closed next post.

    • Edited by Jibba j Friday, October 25, 2013 11:27 AM
    Friday, October 25, 2013 11:19 AM
  • Here's the results with the ide closed:

    Same conclusion. It looks like most programs run a bit faster with the editor closed.

    Friday, October 25, 2013 11:26 AM
  • As my computer (triple-core 2.3 GHz, running XP SP3) has a 16 ms resolution on the Clock.ElapsedMiliSeconds, I couldn't run your PPl460. I got results of 0.00 or 15.5.

    I decided to do a greater number of runs to get longer measurement times.

    I inserted  a  Niter=1000 at the start, and enclosed each of the empty loops in For it=1 To Niter / ....../  Enfor. The calculated times I divided by Niter to get results in ms.

    The results for Niter=100 and 1000 are the same, but they do not compare to your conclusions! Therefore I added also a empty run for 1 To 10000, and the reverse. The results are:

    As you can see the reverse loops are twice as slow as the forward loops, and the hardcoded 10000 is even slower.

    These results are obtained in the IDE.

    Jan [ WhTurner ] The Netherlands

    Saturday, October 26, 2013 11:45 AM
  • Thanks for the post WhTurner.  Could you post the ID and i'll run it as is on my PC.

    My Laptop is early gen i7 in desperate need of a complete service. .NET 4 I think.

    Interesting, your results are the complete opposite to mine.

    Would be nice if someone else could run PPL460 and post a pic of the results, and perhaps  validate the test.

    Also if anyone could post more optimisation tips for Small Basic would be great. Would make a very helpful wiki.

    There could be cases where a While loop is faster than a For loop in sb. Also getting rid of unnecessary stuff in the code e.g. values stored in variables that are only used once, could be valid if there are a lot of them.


    Saturday, October 26, 2013 7:14 PM
  • Here are my results when I ran PPL460, but I had to remove the Textwindow.Hide() command because it kept crashing the program:

    Here are my results with the editor closed:

    Saturday, October 26, 2013 11:58 PM
  • line 4, 5, 8 & 9 seem show the improvement.

    Caching and avoiding multi function calls optimises for 2 out of 3 computers :)

    btw: I turned my laptop up to "high performance" and got 391 for line 4 and same results. My slow pc :(

    Sunday, October 27, 2013 4:21 AM
  • Array.GetItemCount is a function that's dependent on the array variable. It must be called each loop and can be changed in the loop.

    var = "1=5;2=5;3=5;4=5"
    For i = 1 To Array.GetItemCount(var)
      var[4] = ""
      var[3] = ""

    • Edited by Jibba j Sunday, October 27, 2013 4:40 AM
    Sunday, October 27, 2013 4:39 AM
  • Jibba Jabba,

    I published my version of your PPL460 as VWB076

    Jan [ WhTurner ] The Netherlands

    Sunday, October 27, 2013 6:28 PM
  • Thanks Jan.
    Sunday, October 27, 2013 7:20 PM
  • Here's a link to heaps more optimisation techniques. It contains stuff on the above tips: inner loops and pre-calculations. I reckon the reverse loop is a neat pre-calc. Could be used as a guide for further reading.


    ATM i'm going back over some of the curriculum exercises and trying out these tips. Learning lots. I've been able to apply all 3 of the above tips so far to curriculum 4.1 - Show what you know.

    I'm doing an exact clone of it but with optimised code. Using the fairly simple (predefined) exercise and simplified small basic editor it has given me an easy chance to practice this stuff:

    • naming variables and deciding which ones to declare. Helps reduce commenting, improves readability, makes the code more extensible and helps program more varied tasks.
    • software build
    • debugging. Instead of saying "that should work" this is the tool to help say "this will work and know exactly how it does work"; and
    • structuring

    Works for me. I reckon it will help me code the useful desktop app I've got in mind.

    Friday, November 1, 2013 12:53 AM