I expect you wait "programer's tasks" or listings of code. These were things I had used before. My experience shows they are bad because two grounds.
Firstly a listing is written in a programming language. (Sometimes authors use simplified imitation of it, but this is not the matter.) There exist hundreds of different languages. The problem is that not all readers know the used for examples. They cannot understand the illustrations of thoughts from the text. As result they cannot understand the text completely.
The second problem exist because other readers know the programming language very well. In the worst case they work with it. If they show the source code, they automatically switch their brain into the "working" mode. As result they are completely involved in the process of search of the solution. The paper becoming only a context of this task. As result they cannot understand the text completely.
I'll use in this article many real examples I had collected. They are written in different programming languages and by different people. To make the examples understandable I'll throw the languages off. Only the idea is important and should be clear. In all cases I'll try to make it as clear as possible. This means I'll choose the best form to represent the ideas. You can translate them into programming languages you know and into the examples you had seen.
To show this process I'll sometimes use C++. You needn't know this language. It will be used only to show you something like you see on your screen when you're writing software.