Is using this-> and typing code extra work?

It’s all over in my code and was annoying to type.

1 Like

100% agree. It saves the people reading the code a lot of effort and avoids unnecessary ambiguity.

The compiler might have no trouble remembering all the symbols and looking them up in a fraction of a second, but we humans don’t necessarily have that luxury. :P

Two excercises for the people playing along at home:

  • If you removed the this->, which x does the left hand side of x = x; refer to?
  • How would you get it to refer to the global x?

(Naturally one could argue “don’t reuse identifiers in the first place”, but that’s easier said than done.)

If you don’t like typing, don’t do programming. :P

Or write in APL instead. Here’s an implementation of Conway’s game of life:

life←{↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵}

Very little typing involved.

There are two other alternatives that weren’t mentioned…

One option is to make getX() return a reference (i.e. int &) instead.
This is how types like std::vector provide an operator[] so you can do things like vector[index] = value;

Another option is to create an addX function, which would then make your code particles[i].addX(2);.

Each answer makes sense depending on the context of the code.

If you’re the only one working on the code and the value of x doesn’t need any kind of validation (i.e every single value that x could possibly be is a legal value) then any of the discussed options are fine.

In an environment where x had to be kept stringently within a certain range lest the world collapse, you’d most likely use the addX option and it would have logic to prevent x going out of the valid range.

In an environment where x could be any value but you want to be free to move where it’s stored, getX and setX are probably the preferred options, and a reference would be used if copying x was potentially expensive or possibly not even allowed.


The using this-> as a rule or as an exception is a religious argument, just like brace formatting. I’ll leave it at that.

1 Like

Generally, I don’t.

A lot of the time making this I wondered how much faster it would go if I was using something like UE4 blueprints or scratch.

I love UE4 blueprints, I have a fantasy about having an IDE where you can develop Arduboy like that.

Although, there is nothing really stoping you from just making a game like that in UE4 then…

Thanks for the info!

Actually, not that much faster really.

The majority of time/effort involved in programming is actually spent figuring out the programming logic, reading the code and reasoning about the meaning of the code (the long pauses of “hrm, what do I need to do next?”).

Doing the typing is typically only a fraction of the time spent,
especially if you’ve got a good IDE that auto-generates common snippets like loops, getters and setters and so forth.


Even basic autocomplete and multiple cursors make a huge difference.

It’s completely doable, but unlikely to generate small/fast code.

Or at least, most out-of-the-box solutions aren’t likely to.
If you’re happy to spend the time and effort to make a bespoke solution then it’s completely possible to generate decent code.

For the sake of giving a comparison, here’s some Blockly code:


And the equivalent standard C++:

#include <iostream>

int main()
  auto count = 1;
  while(count <= 3)
    std::cout << "Hello World!";

And just for fun, here’s the equivalent Lua that Blockly might generate:

local count = 1
while count <= 3 do
  print "Hello World!"
  count = count + 1

(Call me crazy but I think the Lua is easier to create than the Blocky.)


Maybe I’m just different but I disagree. Generally I know exactly how to solve the problem but spend my time trying to figure out exactly the right syntax or casting that I need. Being able to select from drag and drop options makes it fool proof.

Honestly, most of my time spent coding is trying to figure out why some variable wont cast to some other one, or some typo, like the comma issue I was talking about. I’m sure you might argue that I just need to “earn” more about the code I am creating, but my argument is the exact opposite is that you learn intuitively by using code blocks.

I also get lost in curly brackets and some times get extremely frustrated when something doesn’t work.

I’ll have to show you the game I made in UE4 using blueprints. For me anyways, there is absolutely NO chance I would have ever been able to code something of that scale with actual C++ code. Other people probably could, and their code would run faster and more efficient. But I would not be able to handle looking at a wall of text scrolling through it.

When the GUI helps me visualize the code, I actually think it speeds me up a lot.

Also, I can type at over 100wpm so that’s not the issue. I do like when you can get creative with your code, like you mentioned especially in languages that are designed to minfi like that and brainf#ck.

I think its personal preference, and might be a right-brain left-brain kind of thing. I very much prefer visual things.

To be honest, I’d be even faster at coding if the modules were actual physical objects I could manipulate on a giant board.

Or the more common way in C++:

#include <iostream>

int main()
  for (auto count = 1; count <= 3; ++count)
    std::cout << "Hello World!";

That is indeed more common, but it’s not syntactically equivalent to what’s written in the Blockly example.
(Semantically yes (modulo an extra scope), but not syntactically.)

1 Like

Here is my spaghetti code for firing a bullet in my UE4 game, I can’t possibly imagine trying to have done this with actual typed code, and the ability to come back to it months later and understand what is happening is extremely faster too. At least for me, some people maybe just love staring at a text editor.

I can think of a lot of comparisons and counter arguments to those points (e.g. a block version of C++ would still involve casting, so that problem wouldn’t be fixed), but rather than go into all that, I’m going to try to do something more constructive.

I’m going to try to demonstrate what I see when I look at some code.

When I look at curly-braced Allman style code I see this:

I see the code blocks and the extents of the scopes they encompass.
Even without an editor to highlight them or some GUI programming tool I see those blocks.

(K&R style code greatly upsets this because I can’t see the brace pairs automatically.)

On top of that, I ‘see’ (or more accurately ‘infer’) a large amount of metadata:

(Note - I don’t have synesthesia (or at least not as far as I’m aware), the colours are just to represent ‘knowing’ that information/relation.)

I see the types, the statements, the expressions, the objects, the values, the functions, the operators…

These things are like verbs, nouns and adjectives, I use them to make sense of what’s going on in the code - I check the types all match up, I check the arguments are valid.
I don’t believe this is unique to me either, I’m reasonably convinced this is on the same lines as most programmers (or at least the ones who know enough about a language to see these things) see their code.

I know for a fact that this is how the compiler sees the code. The compiler looks at sequences of characters, categorises them as different kinds of ‘tokens’, follows a sequence of rules to build a tree from those tokens and ascribes meanings to the nodes of the tree before analysing it in depth and determining whether it is ‘correct’.
(This is a great book by the way.)

Humans purportedly do a similar thing when reading text in their natural language(s).

The three big problems I have with this are:

  • I’d probably go mad chasing the lines trying to figure out the ordering of everything
    • With functions in source code I can just right click > go to defintion with a modern editor
  • Not really having any type information to work with
  • The whole program being there at once is rather overwhelming

Thos aside, I can imagine what equivalent ‘ordinary’ code would look like.
Every box is a function, every line is a value.

I can barely see enough to read the smaller text, but Get Muzzle Variables might look like this in Lua:

function GetMuzzleVariables(muzzle)
  local location = muzzle.Location
  muzzle.WorldLocation = GetWorldLocation(location)
  muzzle.ForwardVector = GetForwardVector(location)

This is what I see:

And watch any computer hacking scene in any movie, and you know I’m not the only one.

UPDATE: The game I’m talking about is here: Abandoned 3rd Person Shooter Project [UE4]

For you, maybe. I see the blocks equally with K&R or Allman due to the indenting. So for me, proper indentation is more important than brace style. (And it’s really important for python code :wink: )

I fixed your code.

Ahh … I hate Python!


I’m not to particular about code format style. I follow what’s prescribed or the existing format. Given the choice, I’ll generally use K&R with 1TBS brace style and Stroustrup style else and else if).

I never leave off the braces for a single statement block, even if the statement is on the same line as the condition test. I’ve had to fix too many bugs due to someone adding one or more new statements with the same indent but then forgetting to add the braces.

// This:
if (condition) {
// Not this:
if (condition)

// This:
if (condition) { doThis(); }
// Not this:
if (condition) doThis();

I must admit I would do the fourth example but definitely not the 2nd.

I’m not so picky about that one and have done it myself, depending on my mood at the time but I tend to not do one liners at all, preferring the first example.

This is literally the default implementation of arduboy.nextFrame()

Not in the Arduboy2 library documentation.

Might be a good idea to revise the examples with the library to match then.


all use:

  if (!(arduboy.nextFrame()))

Those were all inherited from the original Arduboy library. I didn’t write them (though I modified and tweaked some).

My talk about the use of braces is just a personal choice. I’m not trying to force anything on anyone. And like I said above, when I modify existing code: