How to code logically?

Understanding programming logic with a logical approach.

The Question

Hi Paul

I have been struggling to process the info from lecture 33 until now (lecture 39). I am battling with the logical way to write and position the code. As an instance with lecture 38 and building the counter, I understand what it is doing, but I am battling to put that into the logic of how to write that. It was also the same for lecture 33 when I tried to do some of my own indicators, or just trying to add 2 SMA’s and have a crossover / under alert

Do you have any advice on how to get a better logical understanding?

Bruce

The Answer.

Bruce!

Writing code is a bit of an art. Just like there are a lot of ways to paint a tree, there are also a lot of ways to code logic. On top of the multiple ways to paint a tree, you also have the choice to put that tree anywhere on your canvas! Similar logic follows with code!

Now I can’t draw a 1:1 analogy with art and code because code does require certain fundamental structures/syntax in order to compile correctly.  (Sorry you can’t become the Jackson Pollock of Pine Script lol.)

That being said, I’m fully aware of the agony resulting from a perfectly compiled script that just doesn’t work the way you intend. Whatever the cause of this logical blunder, it stands to reason that you need to FIND the error and CORRECT it. And on top of fixing errors quickly, it can also be a very painful process improving or adapting code or in the very least just trying to understand what the code is doing.

So here are some steps to help you improve.

Be patient and practice.

This is the most obvious thing you can do and I know it’s cliche. But I won’t leave it out because it’s important to understand that the struggle is real and will continue to be real for a while. So it’s important to have realistic expectations. 

There’s no finish line and there is no formal measurement of how long it should take you to get from point A to point B. I say this, because it’s really disappointing to find yourself still struggling after x amount time all the while your peers seem to be excelling and you just read another article titled something like “How I Went From Homeless To Senior Software Engineer At Google In X Months” — While most of these articles are just clickbait, some of them are true; but they are the outliers not the mean. 

Follow a Process

Thinking logically requires focus.

Focus requires concentration.

Concentration requires coffee…. Making coffee requires a process. 

• 

• 

• 

• 

Now the process of making coffee is pretty simple right? Well, I guess that depends on who you ask… because there are a few different methods. Considering we skip ahead past the farming, drying, and roasting processes. We typically find ourselves brewing our coffee the same way every day. That way could be a Kuerig, French press, drip, cowboy, takeout and so on.

The point here is that we don’t even THINK about the process, we just follow it and voila our coffee is ready. This autonomic way of brewing our coffee everyday enables us to focus on other things, like looking for our keys, finding a fresh pair of underwear… or writing good code.

Whatever it may be, our minds are not burdened with the process, because we have a process (Granted you’ve done it more than once).

Whatever it may be, our minds are not burdened with the process, because we have a process…

A paragraph ago.

Break Complex things down into simple steps

The sooner you start thinking in terms of processes, the sooner you will start thinking in terms of steps. And your ability to break complex things down into simple steps will translate into your ability to be a great programmer.

Cool. But how do I follow a process if I don’t even know a process? 

Good question.

Like brewing coffee, there is more than one process for developing code you can understand. It just depends on what stage of development you are in.

For simplicity, I will break up development into two stages. Each stage contains its own methods and processes.  

Stage 0: Blank Slate Stage.

If you’re just starting a new script here’s some steps you should take to ensure that your code remains readable and logical.

0. Make some coffee… Or some tea. I’m actually making tea right now.
   • Refer to beginning of this section for tips.
1. Write your logic down or visualize it if you’ve got a brain like Nikola Tesla.
   • You can make flowcharts.
   • You can use pen and paper.
   • The idea is to not waste time writing code until you’ve gone through this process at least once. Some things are not very clear, especially if you don’t fully understand the system or if you don’t fully understand how you should approach a certain challenge. There might be a bunch of ways to program your logic and if you’re like me, you’re going to warp your brain trying to mentally visualize each different way you could program this all while weighing trade offs. Because there will always be trade offs.
   • Planning ahead is good, but too much planning can paralyze you. So get something written down and build that. You can always come back later and modify it…
2. Follow a convention.
   • Conventions create stability in your code and mind. They guide you, but don’t get fixated on adhering to them perfectly. They’re more like blueprints for programmers.
   • Pine Script has it’s own coding conventions found here.
   • Here’s a long list of all type of programming conventions.
3. Follow the FAQ.
   • Chances are, you’re not the first person with this question. The pine coders website has a plethora of frequently asked questions and tips on their website. I use this a lot. You should too.
   • https://www.pinecoders.com/faq_and_code/
4. Plot your results and spot check to make sure they are meeting your expectations. If not, you have a logical error and need to debug.
   • Debugging in Pine is kind of funny at first since the Pine editor does not have a built in Pine Debugger nor does it have an intuitive print()/console.log() function found in Python and JavaScript.
   • Don’t be dismayed, just look here and here and you will find lots of techniques for debugging. I also cover this process below.
5. Refactor, tidy things up and add comments where needed.
   • If you reach this stage, now you are welcome to go back and make things better.

Stage 1: Debug Stage.

0. Make another cup of whatever you’re drinking. 
1. Read the error log. PAY ATTENTION!
   • Assuming there is a syntax/runtime error… If it’s a logical error then you can skip this step because a logical error cannot be detected by the compiler and interpreter.
   • Click the first error that is printed. Every error after that one has been caused by the first one. This should bring you to the line that contains that error.
   • Pay attention to what the error log is saying. It may not make sense at first, but after a while you will know specific errors before you even see your error. 
     • In most cases it is a type error so check to make sure the type matches the expected type. (Helpful diagram found here)
     • It could be a syntax error so pay attention to all commas and parentheses and spaces etc.
     • It could be a server error, maybe your internet is disconnected? Is your computer plugged in? 😛
     • Scrutinize every character in your buggy statement. It pays to be detail oriented here. 
2. Plot everything.
   • You need to check your assumptions as there are many different logical error types. 
   • Split any multi condition statement into separate statements.
   • Use the data window. The data window is your friend.
3. Start from the top. Talk out loud, and walk through the logic.
   • Also known as Rubber duck debugging.
4. Ask for help.
   • Wisdom of the Ancients
   • Stackoverflow
   • Pine Coders Chat Room
   • Sign up for a course of mine and get access to our Discord and message me directly.

Bottom line

Be patient, follow a process and break your code down into bite size steps.